Security Certificate Warnings Don't Work 432
angry tapir writes "In a laboratory experiment, researchers found that between 55 percent and 100 percent of participants ignored certificate security warnings, depending on which browser they were using (different browsers use different language to warn their users). The researchers first conducted an online survey of more than 400 Web surfers, to learn what they thought about certificate warnings. They then brought 100 people into a lab and studied how they surf the Web. They found that people often had a mixed-up understanding of certificate warnings. For example, many thought they could ignore the messages when visiting a site they trust, but that they should be more wary at less-trustworthy sites."
Re:That's because security warnings are stupid. (Score:3, Informative)
I do agree with most of the posters here though, there's no reason that they can't change that ignorant warning to something a bit more user friendly. Users obviously don't care what it says.
Re:I would probably do the same thing (Score:5, Informative)
authentication (which very few sites need
When I log into $FORUM, how do I make sure that I am giving my password to $FORUM and not to someone who has intercepted my Internet connection?
You don't. Unless you call up $FORUM_OWNER at a verified number (not off the domain)---which means you first have to investigate and verify who the owner is---and get them to verify their certificate fingerprint. You do that every time you log in somewhere? I didn't think so.
The PKI "authorities" do no checking. Anyone with a few hundred bucks can get a "valid" cert, so if you're relying on that ...
banks and so on
Every time you shop online, you deal with banks.
No, you deal with merchants. Merchants deal with a chain of other people, who may or may not be banks. Credit card companies are not, but your card may be managed through one.
Re:If it wouldn't pop up everywhere it shouldn't (Score:3, Informative)
There's so much certificate misuse. A typical mistake is getting a cert for, say, "*.slashdot.org", and then serving it for "slashdot.org". That will cause a reject. Then there are U.S. Government certificate authorities, too many of them. Try, for example, USMC Doctrine Division [usmc.mil]. The CA is "DOD CA-13". DoD alone has root CAs "CA-5", through "CA-18", and not all browsers know all of them.
This is a headache for SiteTruth [sitetruth.com], which uses certificates as a indication of web site validity and a source of business names and addresses. Only certs that are valid, using the Firefox cert file as authority, are accepted. There are more rejects than there should be.
Re:I would probably do the same thing (Score:2, Informative)
well if you managed it properly and installed the proper certificates and a proper root in your browser, you wouldn't have the certificate warning problem.
like you said - you work on a lab intranet. You're the one responsible for setting it up properly.
Re:I would probably do the same thing (Score:4, Informative)
You know you can import the certificates manually. And if you carry them by hand instead of over the network, it really is more secure than the CA solution. The only way you should have extra clicks every time is if you're changing the certificate frequently. Or the guy running the MITM attack on you is changing his certificate frequently...
Re:But is this person the same as that person? (Score:3, Informative)
Re:'People' don't understand computers (Score:3, Informative)
(That's the idea. In reality, you just skip by that screen and bemoan the annoyance.)
Re:'People' don't understand computers (Score:5, Informative)
Firefox makes users jump through hoops for a reason. Once upon a time, webmasters were terrible at keeping websites up to date, and browsers didn't work very hard to make it apparent. If the website is built and operated correctly, users never see a damn thing.
The first hoop is the most important: the page looks like an error, because it is. The proper thing to do is contact the webmaster, or call your helpdesk, and get the cert fixed. Don't continue. The wrong thing to do here is all the rest of the crap where you "pay attention" but intentionally make a stupid decision and "continue anyway." That process does actually give much more information than previous incarnations. If it's self-signed, or expired, or invalid, it'll say so. Not that it matters, because you as a user have no control over whether the certificate is valid or not. These messages should be intended for power users and developers, since they're the only people who might be able to escalate or *fix it*.
The problem as I see it is that web people seem okay with the idea of allowing bad certs. Helpdesk might have previously told users "just click continue anyways, and go on your way." So yea, error dialogs were much easier for users when they could click once and permanently ignore security warnings caused by incompetent IT.
Re:Maybe Firefox will Chill Out now (Score:4, Informative)
Uh, no, they'd better not be doing that. A certificate authority (CA), in order to be recognized by any of the major browser vendors, is required to contact the people responsible for a domain before issuing a cert for that domain. Normally, the CA does this by sending email to the contact addresses in the domain's whois record. Unless one of those contacts clicks a link or takes some other action to confirm that the person is authorized to obtain a cert on the domain's behalf, the CA is not allowed to issue the cert. Some CAs will also allow certified letters from the registrar if your whois contact info is stale, but that's likely to be an even bigger hoop.
If you know of a CA that is violating this policy and is just issuing a cert if the credit card clears, please contact every browser vendor out there, and that CA will immediately cease to be a recognized CA.
Re:Maybe Firefox will Chill Out now (Score:5, Informative)
Standard certs do nothing to establish identity. They merely establish that the site is not being spoofed. Thus, the purpose of the whois email verification is not to prevent illegitimate sites from getting certs. The purpose of the whois email verification is to ensure that I can't get a cert for www.bankofamerica.com, hack an ISP's DNS server to redirect their traffic to my site, and pose as Bank of America. For those purposes, it is sufficient to merely require that the domain owners confirm via email that the request was authorized.
If you want to confirm that a domain owner is in any way anything approaching a legitimate business, that's what an EV cert is for. Only an EV cert establishes identity in any way.
Re:Maybe Firefox will Chill Out now (Score:5, Informative)
Right now, the only suitable infrastructure for such delegation is DNS. And it's horribly insecure for such things.
Fortunately, it'll become possible with DNSSEC. Indeed, there are groups working on certificate delegation via DNS.
http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel5%2F10467%2F33214%2F01565268.pdf%3Farnumber%3D1565268&authDecision=-203 [ieee.org]
It's no wonder they don't work (Score:3, Informative)
Companies don't even use security certificates properly. I've worked at several places in both the public and private sector where the IT folks didn't even get proper security certificates. So when you go to their websites, or some internal servers, you'd be greeted with 'invalid certificate' warnings and just take it as normal.
One company I worked for was an IT security company whose main services were conducting C&A activities for government and private sector agencies. You can't even go to their company website (https) without getting an invalid certificate warning. You would think a company that is trying to get their name out there in the IT Security world would 'do it right.'
Re:I would probably do the same thing (Score:1, Informative)
(mycompany.com/url1 would return a valid cert whereas mycompany.com/url2 would return a non-valid response)
Care to link to an example of that behavior? The reason why you typically need one IP address per SSL domain is that SSL is a tunnel and HTTP only comes into play after the SSL connection has been established. The server does not know anything about the URL, not even the domain name, when the SSL connection is initiated, so it would not be able to choose the right certificate for the path.
Re:'People' don't understand computers (Score:1, Informative)
Your phrase "a self signed certificate is ten times better than no certificate at all" just points out that your knowledge of encryption is ten times worse than you think it is.
Re:'People' don't understand computers (Score:3, Informative)
Except underscore is not a legal character in a host name.
Hyphen however is.
Re:No shit (Score:1, Informative)
Amegy bank has already started doing exactly that