SSL Still Mostly Misunderstood, Even By the Pros 292
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?"
Moderators, are you all friggin' retards? (Score:4, Insightful)
Who proofreads these article submissions, anyway? Does anyone?
Re:You're doing it wrong (Score:3, Insightful)
SSL is dead for 10 years (Score:2, Insightful)
SSL is no more for 10 years.
You have to copy TLS 1000 times on the blackboard :
http://en.wikipedia.org/wiki/Transport_Layer_Security
http://tools.ietf.org/html/rfc2246
Re:You're doing it wrong (Score:5, Insightful)
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.
SSL is trying to do too much. (Score:5, Insightful)
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)
Re:SSL is trying to do too much. (Score:5, Insightful)
Of course IT proffessionals don't get it (Score:5, Insightful)
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.
it's the browser implementation (Score:4, Insightful)
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
Re:You're doing it wrong (Score:5, Insightful)
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.
Re:You're doing it wrong (Score:5, Insightful)
>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.
Re:As usual, no one wants to be the leader. (Score:3, Insightful)
I blame JAVA.
Java dev to any other IT dude: "I don't need to know about that the jvm abstracts that away for me. So buzz off and let me do real IT work. "
Just kidding :) Well actually I'm not. In general Java devs know ZIP about anything out side of a JAR file.
Re:You're doing it wrong (Score:2, Insightful)
I think the idea of a public revocation database has merit. How would I make sure that my connection to the database has not been tainted? How could this database as a business entity be designed in a way that's less vulnerable to social engineering attacks than the current system?
Re:Of course IT proffessionals don't get it (Score:3, Insightful)
I'd like to second that motion. The same thing goes for encryption used for wireless routers. When a non-tech friend is setting up a new wireless router and is setting up the encryption part, they just see a list of 3 and 4 letter words they don't understand. And the only reason I know which is the best to pick is reading around the web to know which are easy to crack.
Re:You're doing it wrong (Score:3, Insightful)
> "Reguly's survey found that while 83 percent of users check they're using an SSL-secured session before entering their credit card information on a Website, only 41 percent do so when typing in their passwords."
I found this one of the silliest parts of the story. First, to what type of sites does that 41% figure apply? Are they the same sites where people are entering credit card information? There are a number of sites where I enter passwords without SSL encryption, this site for one. Those are sites where I don't really care if my password is sniffed or not. Does that place me in the 59% of supposedly inattentive users? For sites where I care about protecting my authentication information like my bank or Amazon, I make sure the password transaction is encrypted.
Next, the article presents a laundry list of apparent security flaws in SSL. How common are these? Do we have demonstrated evidence that they've been used to subvert transactions with well-known sites like major banks and online retailers, or are these just theoretical flaws? Like the article on piracy in today's news, the statistics in this piece seem intended to drive sales of security software and services by fear-mongering.
Finally there's the suggestion that browsers never permit people to accept certificates that have expired or are self-signed. I'm sorry, but that's just not going to fly. I find the current plethora of hoops I have to jump through with Firefox annoying enough. If I want to sign a cert so my employees can read their mail with a web browser, what's wrong with that?
Re:SSL is trying to do too much. (Score:3, Insightful)
So you are saying you shouldn't change the public/private key for for 20 something years?
If all you're securing is a session to a web forum where there are no assets at risk, sure.
It's more security than not using TLS at all.
Re:SSL is trying to do too much. (Score:3, Insightful)
Where have I suggested that Paypal should use self-signed certs?
The point is that there's thousands of sites... no, hundreds of thousands... that are wide open for sniffing that would be using TLS if it was possible to set it up as easily as you can set up SSH. This possibly didn't used to be an issue but is getting more so as more and more businesses provide things like free wifi.
For these sites the same level of authentication as SSH, "this is the same server as you visited last time", is adequate to deter MITM attacks.
Re:Of course IT proffessionals don't get it (Score:2, Insightful)
You may be right about SSL, but I think you're incorrect about encrypted Email. PGP was a very easy-to-use program for its time, complete with plenty of documentation that (as a previous poster mentioned) posed the problems and solutions in clear, Alice-and-Bob terms.
Furthermore, the PGP/MIME standard was very clear, and had a clear RFC [ietf.org]. I implemented this RFC myself for two different email systems over 10 years ago. Nevertheless, PGP/MIME didn't catch on, and I myself rarely use it now.
Why? Part of it was FUD with S/MIME, but mostly it's just critical mass I think—anything that takes more than a few minutes total won't be done by most people unless it averts an immanent catastrophe (and sometimes not even then).
Re:You're doing it wrong (Score:2, Insightful)
Uh, simply add that self-signed cert once.
Someone in IT will do it.
If people want to access email from home, tell them to remote into their machine at work.
Setting up your own CA doesn't fix the problems you mentioned (random access point fud).
Re:You're doing it wrong (Score:3, Insightful)
Then another time for the website, and another one for the IM server, another time for the VPN, and a couple times more when servers get replaced...
Setting up a CA is a long term solution that only needs to be done once. You can then generate a new cert that will be recognized as valid by somebody in another country.
Yes it does.
If you're lucky:
You go to https://example.com./ [example.com.] It uses a self-signed cert. You accept it, connect to the right server. All is good.
If you're not:
You go to https://example.com./ [example.com.] It uses a self-signed cert. The man in the middle examines your cert, makes another self-signed one with the same details, and presents that to you. You accept it. Connect to the man in the middle who then connect to your server. You read your mail, administrate your servers and so on, while somebody is quietly logging all that data.
With a CA, your cert would be signed by the company's cert. Your company can sign certs with its key, but some random guy running an AP for nefarious purposes can't. The best he can do is to make a self-signed cert with your company's details, but you're not stupid enough to ignore that, are you?
99% of developers don't understand PKCS... (Score:1, Insightful)
I read the article and it's a pile-o-crap but the title is correct...
99% of developers simply don't get what public key crypto is, nor how it works. They don't understand what the 'key exchange' phase of SSL is nor why it is needed (theorically, it's not needed, but practically, good luck without that phase).
How do you want developers to understand what SSL is when they don't understand how public key crypto works? (granted, in some case TLS works with pre-shared keys, but that's a tiny minority).
Of course they've got no clue about SSH neither. They just now that "SSH is more secure than telnet" but they have no clue as to why.
Wanna have fun? Ask during a job interview: "Why is a symmetric key exchanged when two parties need to communicate securely over an insecure network?"
To me programmers that don't understand how public/private crypto works SHOULD write a simple application that simulates how, say, a very basic RSA system works. It's not hard, it's lots of fun (who doesn't like messing with prime numbers ;)
I've done it last century, just for the fun it.
That's the real problem today: most developers use technologies they don't understand (like TLS/SSH) and tools the don't understand either (do you think developers have the slightest clue as to how a kernel or a device driver work? Of course not.
It all looks like "magic" to them. That's a very concerning issue.