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?"
Who proofreads these article submissions, anyway? Does anyone?
The article isn't even just pretentious, it's just pointless fluff. The entire thing could have been summarized as "many customers ignore security warnings in browsers and many web developers deploy SSL/TSL in vaguely unacceptable ways which we won't even begin to explain here".
Really, that article couldn't have been more pointless. WHAT are people doing that they shouldn't be? WHAT are people expecting SSL to do that it doesn't? If you're going to write an article about people's misconceptions of a technology, you could at least spend a single sentence explaining what some of those misconceptions are.
Pointless and uninformative article is pointless and uninformative.
Forcing people to implement both privacy and authentication in one package is half the problem with SSL. For most sites, it's more important to know that the site you're visiting is the same site you visited last time, than knowing that foo.example.com has a signed certificate approved by someone you never heard of. If these two functionalities were separated, so the browser just checked that a "non-certified" site's encryption key hadn't changed and let you through without comment if that was the case, then most sites using old or self-signed certificates would just use the encryption layer, and browsers COULD block access to sites with invalid certificates without causing people so much inconvenience they'd want to switch to a different browser that was less picky.
(yes, I know that this would probably be implemented using self-signed certificates, but it could be presented to the user as a "low security" site with an appropriate icon and at most a comment that "you haven't visited XXXX.example.com before, it is a low security site..." the first time you see it)
Have you ever tried teaching yourself the basics behind SSL, such as PKI and X.509 certificates? In an industry full of jargon and technalese, the security people are some of the worst for explaining things. The documentation out there is poor and cryptic. Ever wonder why encrypted or signed email never took off? Look no further than GnuPG or the Enigmail plug-in for Mozilla. Try finding out what DER encoding is, or ASC.1, or what PKCS#7 means. None of it's straight-forward, even for technical people.
as the guy said in the article, it should kick you from a session at expired certs, not allow click through options
if the cert is expired/ unverifiable, the browser should simply kick the session, end of story
that should really be the only option available to anyone. its psychological: take this seriously, sorry for the inconvenience. otherwise, lazy admins will let their expired/ malformed certs hang out there for a lot longer (which i've seen even on a credit card site: capital one), because users just easily circumvent the roadblock. they'll definitely notice if no users can get through, and the angry emails pile in their inbox
i only allow https admin connections to my router, which of course means my browser screams about being unable to verify any certs... since i'm on a subnet. and i bet there are many other valid situations where expired/ unverified certs still represent a valid connection
however, add up all the valid situations where you want to continue an uncertified https connection, and you are left with nothing but a hill of beans in comparison to the mch more massive problem of psychologically just not taking https seriously enough
now you just have to convince the 3/4/5 major browser flavors to implement this new status quo
maybe the certificate authority should simply kick insecure browsers regardless (is that passed to the certificate authority during verification of cert?). that would get browser coders and vendors to notice. of course, what the browser report themselves can be hacked/ finessed, but if that's done maliciously, you're box is already owned, and its already game over regardless through a lot more powerful avenues
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
No, I'm afraid it's not. It's still vulnerable to "Do you accept this made-up key" attacks where people have become far too accustomed to accepting unsigned keys, and to the purchase of centrally signed keys. Because the key signatures belong to a central signing authorities that rely on valid credit cards, not personal authentication, there is still only a pretense at genuine security.
There have been other tools proposed to address these issues, such as the PGP web-of-trust, and the Palladium project's hardware encryption, but they've broken down in practice on the problem of US encryption export regulations, poor closed source implementation that turns out to be easily virtualized, and many essentially social rather than technological issues. Even SSL was handicapped for years by the USA's insane 80-bit limit for SSL in exported software.
>No, I'm afraid it's not. It's still vulnerable to "Do you accept this made-up key" attacks where people have become far too accustomed to accepting unsigned keys, and to the purchase of centrally signed keys
Um, that's a social engineering attack, not a fault of the protocol itself. The protocol is secure, users aren't. To be fair, the browser manufacturers could do a better job of writing the warnings so that anyone could understand them. Again, this is not a fault of the protocol, rather how people use it.
And adding a layer of PGP to it, would have the _exact_ same issue. Instead of "Do you accept this SSL key" It would be "Do you accept this PGP key". In addition, adding PGP would introduce a whole new slew of security bugs related to added complexity of PGP support in browsers, along with all the bugs guaranteed to be introduced with the additional new code.
No thanks =D.
Don't kid yourself. It's the size of the regexp AND how you use it that counts.