Slashdot Mirror
SSL Still Mostly Misunderstood, Even By the Pros
An anonymous reader writes "People still don't understand SSL. This isn't much of a surprise... no one expects that grandma and grandpa know what SSL is and what it does. What is surprising and downright scary is that most IT professionals don't understand SSL, and many consider it to be the be-all, end-all of security in their organization. With all the tools out there to manipulate SSL connections, and the browser vendors unable to settle on a single method of showing if a site is secured by SSL or not, is it any wonder that no one gets it?"
If you want to write a pretentious article about how people don't understand security of the interwebs, at least get the name right. That's right, SSL hasn't been considered "secure" for at least a decade.
How we know is more important than what we know.
"browser vendors unable to settle on a single method of showing if a site is secured by SSL or not"
They put a thin but obvious blue border around the entire browsing window. Why does Firefox not let you select among a few different methods? I know not.
Performance overhead of encrypted connections, we can't even get UTF8 due to performance concerns, what makes you think we're going to get HTTPS?
caching.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
The correct term is "HTTPS". HTTPS, which can use various versions of SSL or TLS, is still mostly understood. Even by the pros.
How would HTTPS help? You'll still probably do an unencrypted DNS lookup for idle.slashdot.org.
Not to mention the fact that the GETs will have to have their endpoint identifiers unencrypted, and so the IP addresses will be available, which means they'll know how MANY requests you've made to /.
By the way I use cacert to generate my certificates; it should be inlcuded in the default Firefox certification authorities list. I suspect there is money involved in getting into that list though.
CAcert failed a DRC audit. Bug 215243 comment 158 has the details.
In general Java devs know ZIP about anything out side of a JAR file.
They may not even know that JAR files are ZIP format.
All browsers would have each registrar's root CA certificates in their CA store. When a person registers a domain name, the registrar also gives them either an issuer certificate for that domain or a wild card certificate for that domain. The person could then either use the issuer certifcate to make more (www.example.com, store.example.com, etc.) or just use that wild card certificate (*.example.com).
Congratulations, you have just invented DNSSEC.
Next task: Get root registrars to actually publish and issue root certificates to the registrars.
After that, get browsers to support them.
If corporations are people, aren't stockholders guilty of slavery?
You haven't yet been modded overrated for not understanding DNS, but maybe someone with mod points will stop by...
Before you exchange certificates you need the IP address of the other end. If Anonymous Coward doesn't want anyone to know that he reads the "idle" section then he needs to get the IP address of idle.slashdot.org without doing an unencrypted DNS lookup for it. How common is encrypted DNS?
PS You forgot to mention
c) get a MITM-attacked connection which your browser thinks is fine because it appears to be signed with MD5 by Thawte.
I know MD5 collisions wasn't my point - that's why I made that a PS - but you still haven't got what my point is. Ignoring insecurities in the PKI and TLS implementations, TLS can prevent eavesdroppers from knowing what data you're sending and receiving, but it can't prevent them from knowing with what server you're communicating. The eavesdropper can still sniff the IP address in the IP packets, and the DNS request which is necessary before you even send your SYN packet, which itself precedes certificate exchange. TLS is cryptography, not steganography.