Slashdot Mirror
Security Certificate Warnings Don't Work
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."
This shouldn't come as a surprise, since most people still don't understand how viewing a website can affect their computer.
I blame firefox's big scary error page that comes up every time a page uses a self-signed certificate. I've gotten so good at ignoring that, I probably wouldn't notice if a page said "the certificate doesn't match" instead of "the certificate is self-signed."
Mozilla isn't doing anybody any favors with their heightened paranoia.
A cat can't teach a dog to bark.
Do we really need a lab study to tell us this? Even the article admits that we've known for decades now that users will happily accept a broken cert. There was a case where the Mozilla people received a complaint from a security researcher saying their certificate checking was broken because he was connecting to a known trusted website and her certificate wasn't broken, so it must be Mozilla's fault - they concluded that it was man-in-the-middle attack and she later apologized. If a security researcher can't even tell, how are my parents supposed to?
How about this for a solution? Instead of a "Privacy Shield" you have a "Security Shield".. when you press the Security Shield button you enter Lock Down Mode and your web browser will refuse to display pages that are not retrieved via TLS. You could also enable some extra paranoia settings.. turn off plugins, Flash, etc. When you've finished your banking, or whatever, you press the Security Shield button again and now you can go back to Facebook.
How we know is more important than what we know.
The only difference between a self signed certificate and one that is signed by a CA is that someone wrote a check for the CA signed cert. No CA does any verification that the person writing that check is who they say they are, has any rights to that domain, or anything else, they only check to see if they already have a signed certificate. I've personally bought Verisign certificates for other people, without any proof that I'm in any way authorized to do so, let alone proving who I actually am. They mean absolutely nothing.
The only kind of certificate warning is one which indicates that a certificate is not what it's supposed to be. However, since there's still no central way to check a certificate(even a signed one) the only way to do that is to compare it with what you had before, which means the only viable certificate warning is one indicating a certificate has changed.
When browsers panic over things that aren't worth panicking over (most folks will have encountered a perfectly legitimate self signed cert at some point in their time on the web, is it any wonder they just bypass the error.
Certs never guarantee who you're talking to, they only provide encrypted communication.
I am reasonable computer-savvy but I also don't understand these messages most of the time. I then use the 'I have a Mac, I am invincible' attitude, which is dangerous of course. But I just want to view that website!
-- Cheers!
The problem is that those things are just a nuisance for a lot of things. It just pops up randomly because a developer forgot to test the latest update or didn't install the new certificate on all the frontends. Then you have the 'intermediate' CA's where if the intermediate issuer isn't in the browser CA's or the browser doesn't support intermediates or wildcard certificates it gives you another warning. Or somebody let the certificate expire or didn't get it signed by a well-known CA (usually the less-professional sites that are self-signing). Then if your ISP isn't honest (which apparently 99% of them these days aren't) with their DNS and you go to https://wrongname.com/ it will give you the https version of their ad page on the other domain which of course gives a big warning.
I have seen warnings on important sites like Wells Fargo and Bank of America and there are permanent warnings on some other sites that I use frequently that are either self-signed or expired. I usually verify them and it's not my system that's been hijacked so I am ignoring them largely as well.
Custom electronics and digital signage for your business: www.evcircuits.com
Ignore certificate warnings if you're not planning to give the site any important information (e.g. a password). Otherwise, don't.
So you don't want to send passwords over an HTTPS connection with a self-signed certificate. I take it you don't want to send passwords over an HTTP connection either, as HTTP is even easier to snoop than self-signed HTTPS. Should everybody who runs a forum or a wiki pay $$$ per year for a CA-signed certificate?
... these warnings can be safely ignored 90% of the time. IIndeed software and web developers bombard users with uncessary messages and errors, such they become a little keen just to click ok and see what happens anyway. Another problem is with wording of the warnings which are too formal-technical and not plain-english-ok-so-what-should-i-do-now.
Just wording it differently like 'If you are accessing what appears to be a trusted website, and you are recieving this warning, you should not visit it as it could be a nasty security risk. Try again later." Rather than "Warning: Security certificate is not valid... [etc etc..]". This makes a huge difference.
WOT is more to the point: "This website is dangerous" and the page is locked out until you navigate away or click on a very clear "Ignore this warning and proceed".
After logging in slashdot still does not take you back to the page you were on. It's been that way for 20 years.
First, users don't know what certificates are, or why it matters. That should be pretty obvious.
The situation isn't helped by the fact that the overwhelming majority of invalid certs, in my experience, are just from random sites which you find with a Google search, and those sites for some reason have https instead of http as their search result. You click, and oh shock, the administrator hasn't updated his cert in ages, because nobody cares. After endless warnings about this, even I have stopped caring. It's almost a Pavlovian conditioning to see that warning and say "Yeah, whatever."
It's even worse now. Back in the day, you could dismiss these mostly spurious warnings with one click. These days, Firefox makes you go through an utterly obnoxious process of acknowledging the warning, then manually adding the certificate, then approving it. All because I needed to see some forum where people were discussing some problem I needed to solve. I am so tired of having to go through this that I just sigh and back away from the site and try to find another one that won't make me do this. I am not shocked that users just click whatever it takes to make the warnings go away.
mirrorshades radio -- darkwave, industrial, futurepop, ebm.
Actually, certificates do guarentee that the person you are talking to is the same as the time the certificate was first issued.
So how do you know that the person to whom you are talking using a given URL is the same person to whom, say, a software reviewer was talking when he downloaded a given release?
Verisign is untrustworthy, so why should I care if a certificate is signed or not?
Signed certificates are a complete racket: If you don't pay us then when your users show up they will get a giant warning shown in their face, telling them not to trust you. You wouldn't want that would you? Nope, don't care who you are, what you do, or why. $100 bucks please.
If I can go out and get a certificate signed by "FishWithAHammer" for a couple dozen bucks from some CA which happens to have its root certificate in your browser by default (and I can), even CA-signed certificates aren't worth much. Actually, the fact that you think a CA-signed cert is much better than a self-signed one means to me that they are causing more harm than good in the form of false security.
This author takes full ownership and responsibility for the unpopular opinions outlined above.
"Legitimate sites will not do this" == lie. Seriously guys, fucking grow up. The number of changes I have had to make to firefox in code (not about:config, code) to disable autocomplete prevention, self-signed certs, etc...it's getting frustrating.
93rd rule of Slashdot: No matter how obvious my sarcasm is, my comment will be taken seriously by someone.
You could have a big pop up box that says "Clicking here will empty your bank account, steal your car, rape your women and children, and cancel your NASCAR season pass on your TiVo" and John Q Public will still click on it.
Most of the non-techies and a lot of techies are sick of "The Browser/OS who cried wolf".
I get certificate warnings for internal sites, inside the firewall, without having accessed anything external. Yes, our CA people and developers are morons. No, let me state that more clearly. They are offshored, overpaid by a factor of five, patent leather morons. And they all talk too fast, fail to deliver a statement of work, and fail to deliver even what they say they will, in writing, before witnesses. But I digress.
Certificate warnings are relatively pointless, because they point out a technical flaw without distiguishing between bookeeping flaws, expired or poorly minted certificates due to simple incompetence, private certificates that serve the purpose, and actual explotations.
Many of our certificates at work would raise warnings, and do when I indulge in testing, but the sites are application-specific. A browser never needs to access these, and doesn't unless I'm verifying connectivity. Otherwise, the firewalls and application rules kick in and discourage an attacker by either blocking their IP or delaying response and slowing the attack to a crawl.
I get these warnings pretty regularly on public sites, and generally ignore them. But anything I was linked to, or referred, or a URL I am not entirely sure of, I either close the session and start over, or try it on my phone.
So far, my phone has shrugged off some clever but Windows-specific attacks. Always fun to revel in the agony of others.
deleting the extra space after periods so i can stay relevant, yeah.
If you do have a CA-signed cert, the connection still isnt secure. Thats the real problem.
Anyone willing to screw lots of people, each out of thousands of dollars, is also willing to game the CA system with stolen credit cards.
It is all about trust. If you can't trust the signing authority, how can you trust the signer?
"His name was James Damore."
Exactly. My bank can spring for a paid certificate
Sure they can! Because those asswipes have a ton of fucking taxpayer money!
You are correct. The cert. method in FF3 sucks big time.
This UI falls into the same pool as EULA user interface. It is lawyer-ware. If it actually helps someone not go to a bad site, that is great, but that is not the design goal. The goal is to limit liability and prevent a whole bunch of stupid people for suing the browser maker for damage caused by going to a bad site. This way if it goes to court, the defendant can just say "hey, we showed them a message saying it was a bad site and they clicked it anyway." Phishing filter is similar. It doesn't take a genius to understand that a phishing filter is only useful for people who can read URLs - after all, the filter just says "check this URL and make sure it is OK". But if you can read a URL, you don't need a phishing filter in the first place.
There are actually many pieces of UX that fall into this camp, where the UX makes little sense until you understand the various lawsuits that led to it. For instance, did you ever wonder why the "Pictures" item in the Windows start menu doesn't take you to the photo gallery - which is what something like 95% of users expect?
Unfortunately, over time we can expect this to increase instead of decrease.
SSH has it right. Tiny warning the first time you visit a site, big warning if the key changes later. If you improved that with a GPG-like system where you could see whether your friends/bank/certificate authority trust a particular key, you would get rid of 99% of the warnings. Suddenly the warnings would be a once-a-month (or even once-a-year, if you only browse mainstream sites) event, and the users would click no.
As long as warnings happen all the time, people will ignore them. You can't educate your way out of so many false positives.
Finally! A year of moderation! Ready for 2019?
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.
Check out my sci-fi/humor trilogy at PatriotsBooks.
I've lost count of the genuine websites run by respectable organisations that used an "invalid" certificate - either because the certificate was for www.someone.com instead of yyy.someone.com, or because it expired last week, or something like that. In most cases they're not a site I need too much security for. So I shrug and add an exception. Unless it's ebay or paypal or my bank, I don't really care about encryption OR authentication for the site.
Here's a neato business plan. Buy a bunch of certs. Sell them to other people. http://www.google.com/search?q=anonymous+ssl+cert
Of course, if all it takes is an email from the domain you just registered for your phishing site, how is it that you won't get the email? I once bought bought cheap cert from godaddy for a site I ran (legit site) -- I never got a phone call. What's an email prove -- nothing except I can fill in some forms on a webhost admin console to set up an email. It doesn't say a thing about who I am.
What changed under Obama? Nothing Good
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.
Check out my sci-fi/humor trilogy at PatriotsBooks.
Get a free certificate, then. http://www.startssl.com/ generates basic certificates at no charge. It works in most major browsers, and IE support is expected in the near future. Now that startssl exists, there's really no excuse for self-signed certs even inside a corporate firewall, much less for a real public website.
Free, schmee, that is not the problem at all. Why in hell should I trust someone ELSE to verify my ownership of a domain name on MY internal network? The real problem is everything using their own damn CA lists, making it impossible for us to easily publish internal CA certs. Subversion has one, Windows has one, OS X has one, Gnome probably has one, Firefox has one, Java has one, SSH does NOT have one, etc, etc, etc.
Why aren't CA's delegated just like DNS is? I own all of foobar.net, so grant me an intermediate CA responsible for only *.foobar.net and let me verify & issue certs for my own fraking domain names (internal or NOT!). It is much easier to chain an intermediate cert to the server than add a new internal CA to the clients. Obviously, distributing trust to the rightful owners cuts the CA roots out of their silly trust monopolies.
The determination of who owns a domain name TWICE, for registration & certification is a straight up failure. Own the domain, you should own the CA authority, stop owning it, your cert chain is revoked.
So now instead of crying wolf very often you want to scream very loudly in their face, in an inescapable manner. You have not solved the problem that the "failed certificate" problem occurs too often, neither have you solved the problem of making the user understand why a failed cert MIGHT be important in some case (when a trusted conn is really necessary like to do bank ops).
Instead you just screan loudlier while hold them by the shoulder. That will not help, it will only do two things 1) search for a web browser which do not scream at them 2) ignore even more the cert warning by going take a coffee and click it away anyway when they come back.
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
There are basically two reasons to use SSL:
1. connection encryption (i.e. nobody else can read the transmission);
2. site authentication (i.e. you can be certain that this page is actually your bank's website).
See, here's the problem. Many a time I need to put up encryption, but have no need whatsoever for authentication (sending data like passwords or whatever, but not that critical to be a target of somebody setting up a bigus copy). Firefox says "whatever", and proceeds to complain about 2. above not being satisfied. And complain loud!
Something's wrong in this image. I think there should be 2 classes of SSL certs - "encryption-only" and "full-mode", or whatever they'd be called. the "encryption-only" cert could allow you to use SSL without warnings; the "full-mode" cert wouldn't. The icon or other graphical method of identifying "trusted sites" could even be completely different for both modes.
CA's take a long time to get revoked. Check google for Comodo as an exmple of a lazy CA.
"and taking almost a month to revoke the certificate has to change. The excuse that everyone else does it, so we do it too else we lose business, is weak at best. "
But the whole point is that people do not really understand certificates. There are big warnings, but people are kept in the dark what they should do. Also people are clueless what the small lock actually means. The fact is that if there is a certificate you should be able to idntifiy the people behind it. That does not help you if those people are international scammers in a country where the police does not care. (Maybe because there are bigger problems in that country , like speeding violations)
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
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.'
Having a smoking section in a public restaurant is like having a peeing section in a public swimming pool.
A company which is running their own CA for internal use should have the means to install that CA on each workstation -- thus, no warning, and as a bonus, no possibility of MITMs inside their network.
Don't thank God, thank a doctor!
The warnings of SSL certs rely on something, that doesn't exist: a sense of distinguishing security on the users part.
As the cited study shows, that sense does not exist, in fact blatant decisions contrary to the initial design goal (of SSL errors etc.) get made consciously! Therefore we can reasonably assume the entire system to be broken in both design and application, because other than your geek crowd the vast majority of users don't know, and worse, don't care about SSL errors.
The dangers are invisible: The same resistance you get on other security issues ("You gotta encrypt your email." "Umm...why?) you also get here: If the benefit of applying your mental, time and other resources is not big enough to have a specific/perceptible gain in security and safety, it is mostly not worth bothering with. No amount of re-writing error messages (while in itself not a bad thing at all) will change that! What would make a difference is to sniff a few million unprotected login's and post them somewhere publicly. Ditto for e-mails (the bodies please), chats etc.pp.. Make the risk perceptible and you will make the negation of the risk perceptible and worthwhile.
It is not a computer nor a PEBKAC problem, it's PEBLEARE (Problem Exists between Left Ear and Right Ear). This is not a 'fault' or even stupidity...quite the opposite: We filter our bombardment of information to what's needed the most...actually a very smart and efficient prioritizing of our daily activities. So unless you make e-risks real enough until every mother tells her kids: "Make sure to encrypt your electronic communications!" as they now say "Make sure to look to left and right before crossing the street!" security measures as currently implemented with SSL are largely irrelevant.
"Hi, I'm sosume. I say I'm sosume, and that's all that matters. Please enjoy the random stuff I have to say, and log in with an otherwise pointless username and password if you want to leave comments."
See how it changes when it's just some random dude's website?
Obviously, there's no way for Firefox to tell the difference between a bank's website and some random dude's blog, but it seems to me there must be a middle ground between a tiny little notification saying, "Hey, you should worry about this website!" and an error page saying, "I didn't load this website because of a serious security error! Proceed at your own peril!".
Dan Aris
Fun. Free. Online. RPG. BattleMaster.
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.
..right.. but how does the email get delivered? if the bad guy has hacked the right dns server he can tailor the MX record as well and get the "confirm you want a certificate" email delivered to himself...
The big problem that keeps most users from understanding the warnings (thereby making the warnings useful), is that the warnings are only shown when https is used. This leads to the ridiculous and misleading situation where..
..browsers like Firefox 3 (probably the worst of the bunch, in this regard) makes the user think that an uncertified identity is unusually vulnerable to eavesdropping, when in fact it's vastly more secure than 99.9% of their web usage. They see the message and think something exceptional and more worrisome than usual has happened.
And this implication is utterly false. An identity being certified by someone the user trusts, is the actual exceptional situation (at least right now, until serious efforts are ever made to secure the web). Not being sure who you are talking to (thus, you might be getting MitMed), is the "normal" situation.
Firefox 3 makes the classical mistake of trying to enumerate the bad things that can happen (as though a typical user understands what those bad things are); block or display a warning when it doesn't know who is on the other end (and then it totally flubs up even this mistake, by only doing it sometimes), instead of pointing out when things are going right (the unusual case where you actually know whose webserver you are talking to, and know that you're not being eavesdropped).
I think the core reason that browser people keep getting this wrong (and evolve toward getting things wronger in the case of Firefox), is that they think the protocol displayed in the URL bar, is an important part of the UI. They think that when "https" is in the URL bar, then the requirements have changed and the browser should behave differently than when "http" is displayed. Joe Sixpack doesn't even know what SSL is, though, much less understand how it works. As long as we pretend that Joe Sixpack understands key exchange and identity certification, the browsers are going to have horrible UIs.
https is something the user enters (either directly, or by clicking a link). It cannot ever signal the user agent's evaluation of the situation's security. The padlock/keyhole/whatever icon is for that, as is a color added the URL bar or an icon to the left of it, or a look-at-this-cert popup (whatever--the point is, it's information provided by the browser, not the user). Use of SSL doesn't mean you need MitM protection. Whatever the user is doing (e.g. entering bank account access credentials, as opposed to, say, reading Twitter) dictates whether or not they need to see the padlock icon.
What really ironic is the Firefox 3 does do the right thing just left of the URL bar. When the user wants to know how safe things are, the FF3 actually team gave them a pretty good UI for that. But the obtrusive cert warning that happens when (and only when!?!) using SSL, is totally stupid. It's like part of the FF team had a clue, and part didn't, so they compromised on something half-assed.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.