Hacker News new | past | comments | ask | show | jobs | submit login

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.


Oh sure. I've written software that does exactly that. I also tend to write my stuff to use TOFU when it's TLS outside of the mess that's the web.

But you have to admit the general default for SSL is the PKI implemented in web browsers. Even too often in non-web applications, unfortunately.


Then that is a fundamental problem with SSL.

I am very partial to the Perspectives[1] solution. I wish it would gain more wide-spread support...

[1]: http://perspectives-project.org/


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)


That would be in a perfect world. Unfortunately, the world is pretty messy.


That looks neat, but I have no reason at this time to trust this project over some random CA.


Consensus is the biggest reason...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: