Re: Debian mirrors and MITM
On 07/03/2014 12:38 PM, Reid Sutherland wrote:
> On Jul 3, 2014, at 12:25 PM, Hans-Christoph Steiner <email@example.com> wrote:
>> As for how to manage making HTTPS by default, this does not require every mirror buying HTTPS certificates every year from Certificate Authorities. There are workable solutions based on self-signed certificates.
>> In Android apps, there are two approaches that are gaining traction: including certificate pins based on the Subject Public Key Info (SPKI) in an apt in advance (https://www.imperialviolet.org/2011/05/04/pinning.html). And using "Trust On First Use/Persistence of Pseudonym" aka "Memorizing Trust Manager" (https://github.com/ge0rg/MemorizingTrustManager) to do ssh-style trust with a yes/no prompt the first time. These can also be optionally combined with the classic Certificate Authority, to provide a redundant check.
>> We've been thinking about to make this workable, here are some notes:
>> Or there could be a password-based CA-replacement like http://tack.io
> Self-signed? Really?
> This is full of issues. Just because someone spends time on an idea, doesn’t mean it’s a good one.
SSH uses entirely unsigned keys, and it has proven a lot more reliable than
HTTPS/TLS. You use HTTPS/TLS keys the same way as SSH, but TLS requires
signed keys, self-signed works. The signatures are only worth the trust path
behind them, and CAs have not proven to be reliable trust paths. So if you
can't rely on the signatures, why bother using them? This is not just my
opinion, but of many others. Google uses SPKI pinning heavily, for example,
but they still use CA-signed certificates so their HTTPS works with Firefox,
IE, Opera, etc.
> But this does trigger another idea; Debian could create their own CA for managing the project’s SSL infrastructure. Then we would just need to trust the Debian CA.
That is also an option. That could also be done in parallel with what I proposed.