Colin, I'd like it if you're stop muddying the waters about my take on SSL/TLS.
I am not a fan of the HTTPS/TLS CA system. You know I'm not.
I am a "fan" of TLS, as much as anyone can be a fan of a protocol. Most if not all of the smartest crypto protocol people in the world have taken shots at TLS. Roughly once every 3-5 years, one of them finds a new vulnerability in TLS, which, when fixed, makes the protocol stronger. That's gone on for roughly 15 years now, making TLS the soundest cryptosystem available to developers on the whole Internet.
You don't like TLS. I get it. You think TLS is too complicated, that it has too much negotiation and too much statekeeping to reason about its security. I think that's a reasonable position to take.
You used to advocate that people write their own encrypted transports to avoid using TLS. You don't do that so much anymore. When you used to advocate that, I yelled about it, because you were wrong. Predictably, when people† write their own encrypted transports, they make grave errors that cause their cryptosystems to blow up.
Now you advocate that people use things like spiped, your new encrypted transport. That's fine too. I'm not recommending it, but wouldn't flag it if I found it on an engagement.
There you have the entirety of our engagement on the issue of SSL and TLS. Note how the Internet trust model doesn't factor into it? That's because we agree on that issue and there is no reason for us to argue about it.
I am not a fan of the HTTPS/TLS CA system. You know I'm not.
Yeah, but to 99.99% of people out there, the existing CA system is an integral part of TLS. Every time you tell people to use TLS, you're (inadvertently) encouraging them to trust the certificate authority structure.
Correct me if I'm wrong, but haven't you also attacked TOFU POP as being worse than the CA system? If I understand correctly, it was a limited form of TOFU POP that caught this attack. (And it seems like TOFU POP MONK would fix the remaining weaknesses of TOFU POP.)
It seems to have worked better in this case. It also would have worked better in the Comodo case, but it wasn't deployed yet. It certainly works better for the intranet case. I can't identify the case where it doesn't work better. Can you help?
As far as I can see this isn't a fundamental problem with SSL, but the fact that most environments come pre-installed with certificates for CAs that aren't really worthy of trust.
[Edit: Certainly looking through the list of Trusted Root CA certs on this machine I have no idea who 95% of these organisations are - I also have a certificate installed by a proxy so it can intercept any SSL traffic and inspect the contents].
Unfortunately SSL's PKI is a fundamental part of how people use it. That said, I would agree with you if you were to say that there's nothing fundamentally wrong with the TLS protocol spec itself, aside from it being probably a bit more complex than we really really need.
The browser PKI is not a fundamental part of how SSL/TLS is used in non-browser applications. For instance, enterprise software that uses TLS routinely rely on static access lists (for instance, of digests of self-signed certificates) to authenticate connections.
The reason browsers have the crazy PKI model is that browser SSL/TLS has to scale to the entire Internet and allow new sites to come online with only days or hours or minutes of advanced warning.
It is perfectly possible to use TLS without relying on Verisign. Nothing in the protocol depends on Verisign. The protocol was built in such a way that you can run your own CA, or run no CA at all and have your system manually manage self-signed certificates.
Browsers won't run without the Verisign/Thawte CA system. That's not an SSL/TLS problem; that's a browser problem. Browsers exist in a complicated ecosystem involving banking and credit cards, cooperation between hostile software vendors, and the most massive installed base of users in the history of the world.
Don't conflate the problems that browsers have with the attributes of the SSL/TLS protocol. If you need to create an new kind of encrypted transport between two endpoints on the Internet and choose almost anything other than SSL/TLS, you might as well write your own block cipher while you're at it.
Hell, for DOD systems on secure networks, you're required to remove all of the non-DOD root CAs. No DigiNotar or GoDaddy or the hundreds of others allowed.
DoD systems on secure networks shouldn't have IP connectivity outside DoD, though. The only issue is code signing keys for activex/java. (which really shouldn't exist on DoD secure networks either, but they've fully drunk the MS kool-aid)
