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."
Those damned full-stop full-page security warnings about self-signed certs are really freaking annoying. Maybe this will be the impetus needed to have them revert to the older behavior.
This shouldn't come as a surprise, since most people still don't understand how viewing a website can affect their computer.
Given the users I've seen using systems where I work, the computer could say it'll format or shut itself down and users will ignore it and click whatever to make it go away. I've seen the shutdown one personally several times....
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.
Ignore certificate warnings if you're not planning to give the site any important information (e.g. a password). Otherwise, don't.
Give me Classic Slashdot or give me death!
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?
A couple years back when FireFox threw a security warning on every single freaking site, including legitimate ones you basically had to ignore it. It was either that or just don't get anything done. FireFox isn't that bad anymore, but because of that people are used to just clicking through without caring.
This is why there is a delicate balance between too much and too little security.
A Magic the Gathering Article and Forum Aggregator
I have ran into countless situations where a self signed cert is the only cost sensible way to provide a secure HTTPS connection, and it comes across to users like me as something like this:
Oh great this again -- reminds me of UAC -- stupid security measures for site owners / browser makers / site users / who don't want to be caught in the aftermath of a criminal situation -- by appearing to make some people feel safer by telling them they are potentially NOT SAFE... :-)
"You agreed that you may not be safe, and you did it anyways! YOUR FAULT!
Hmmmm well I want to see this page, *NOW* And I know its the page I want to see, it is secure... that is good because I'm logging into this, oh it looks like they didn't go through Verisign etc, big deal. Cheapskates! Oh well..
God I hate being asked stupid questions ACCEPT, YES, OK
(I wish clicking "get me out of here" meant YES OK FINE!!! Let me log into the site already!)
I really think this practice of certs and security theater is just making cheap yet good *secure* sites look bad...
The cynic in me sees this as a way to line the pockets of so called "trusted authorities".
Cant this be done in a NON PROFIT manner???
Either way the users needs what the user needs and no amount of paternalism will save them from the monsters!
Dj fuQ [url="http://djfuq.org"]djfuq urges you to listen to the beats[/url] [url="http://djfuq.org"]http://djfuq.org[
oh gawd, how i get here. i not good with computer.
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.
The only warnings I ever get are from .mil and .gov sites....
Which is about right...
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".
... The Everything's-Okay Alarm, as invented by Homer Simpson. Now you to can have a very annoying warning go off every few seconds if everything is indeed okay!
If you think this is bad, consider that most electronic medical records pop up pointless warnings even more frequently. Sometimes they catch a legitimate error, but it's hard to not get conditioned to ignore those without really reading them.
I think I read some story many years ago about a boy who cried wolf... Same principle. Warnings cease to be effective if they pop up all the freakin' time for no good reason.
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.
The parent's comment doesn't make sense and it is clearly spam. Hopefully a mod will come along and mod it down to -1 Offtopic.
This space is not for rent.
In general, the reason that such warnings don't work, is because they present an impossible choice to the user.
If the display were: "visit this site securely and safely; or visit this site dangerously", you'd get everyone wanting the big fancy secure and safe method -- whether they need it or not -- because people are paranoid and trained to listen to fear-tactics.
But the display is currently: "visit this web-site dangerously, or don't visit it at all". That's never been anything that most people can handle. Think of why they wound up there in the first place. They were either sent by a colleague, sent by an employer, sent by a friend, or clicked from an interesting link. If you expect them to say no to their employer, or friend, or colleague, then you're crazy -- people don't do that. They simply lack the confidence and self-esteem for such things. As for the following-an-interesting-link scenario, you've thrown a negative warning when a human being was expecting a pleasant experience to continue into a new place. They'll push ahead for the chance that it'll be "ok", rather than cut-off their good experience.
And, of course, it takes $12 and five minutes for anyone to get a valid certificate, so it really doesn't have much meaning in the first place. It's the encrypted protocol that's important, not the trusting of the site owner by the visitor. That's something completely independent.
My email provider changes the name of their imap server every now and then and it's always something different than what is documented. If I don't figure out what the name in the certificate is and update my settings accordingly I get warnings. If I'm busy with something more important I just click past them.
Now, at least I can figure out how to fix (check out) this but most people wouldn't, they'd just see some problem that more than 99% of the times (if they are in my situation) is no attack but just some kind of administrative thing that fortunately you can click your way through and won't have to waste half a day trying to catch an admin for.
@those who whine about stupid users: I don't think this problem is about stupid users.
that very few websites implement security certificates correctly and keep them up-to-date. Many have signed certs for their site but it is old and subsequently gets flagged. No one is ever going to actually pay attention to the security certs until they are implemented correctly across the board... ya, like that's going to happen! :-/
Get your FRAG on!
The only time I ever pay attentions to these warnings is when I'm sending important data. Otherwise, really, I could not care less. On top of that if there are images being accessed using http on a https accessed web page, a similar warning comes up.
Most of the time though I'm just trying to view a web page - don't care about security.
The researchers first conducted an online survey of more than 400 Web surfers, to learn what they thought about certificate warnings.
How much credence can you give an online survey?
You could reasonably argue that respondents are a self-selected and overly trusting audience to begin with.
OpenBSD doesn't exactly have a fork of Firefox, but their port has been patched to make the horrible Firefox certificate warnings better (certs can be added with one click).
The fact that they make the warnings are so scary is a bad thing, and kind of silly. Self-signed certs are no less trustworthy than plain HTTP connections, and they are encrypted which is better.
Personally, I would like to see a browser that does it the SSH way. When you first connect to an untrusted server, you get a message like this:
The authenticity of host '192.168.0.66 (192.168.0.66)' can't be established. RSA key fingerprint is b1:22:9b:bd:a8:c9:22:d7:04:52:79:7c:9c:0e:e7:d6. Are you sure you want to continue connecting (yes/no)?
If you choose to trust it, the key is stored in your SSH options. The next time you connect, no message, because you chose to trust the cert. But if the key fingerprint ever changes:
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
This, in my opinion, makes more sense than the way browsers currently do it.
Why is there any unencrypted HTTP traffic going around? Encrypt everything, absolutely everything, traveling over the wire. Then, when it's important, you should also worry about whether the machine on the other end is who they say they are.
--Matthew
It seems that for the past few years, more and more "average" sites (blogs, web forums, straight HTML pages) have SSL turned on for no particular reason. They're not banking sites, and some do not require/use any kind of authentication whatsoever. Most likely they have it on simply because they read somewhere "it's more secure", or because it's a 1-line edit in httpd.conf so why not, or to proactively opt out of all current and future mid-pipe page-rewriting shenanigans (BT/Phorm and alikes), not realizing how many clicks of busywork and Dire Warning desensitization this is causing for Firefox users everytime they want to read some guy's anonymous blog post.
Thus, I have no doubt people have become used to clicking away all these warnings, even to the point of getting themselves into trouble when a legitimate one appears on a site where they might actually enter confidential information.
Maybe they need to simply start treating self-signed sites as indistinguishable from plain HTTP (no Dire Warnings, no padlock symbols, broken or not, etc.), or save the Dire Warning dance until the first time the user attempts to submit data (e.g. clicks to type in a textbox). If they're not submitting *any* data, they're not submitting their financial data...
Caveat Emptor is not a business model.
The real problem is that all browsers throw up these warnings far too often. Self signed certificates have issues, but they aren't going away. There will always be applications for which the cost of a signed certificate isn't justified.
If you want to solve the problem, work on a zero cost certificate authority. All the scary warnings are doing is training users to ignore them.
You want me to let the vast majority of users, who we all are agreeing are confused about the warnings about bad certificates, rate those certificates for me?
How is your Average Joe going to do that? If he's been MITM'd, how is he going to figure it out? You're going to give him instructions to wait 6 months and see if his bank account gets drained, and if not, he should go back and rate the certificate "good"? That's going to work real well, eh?
If I didn't know that botnet masters have better things to do than propose very stupid security ideas on Slashdot, I'd suspect you to be one of them, just waiting to be able to raise any bogus cert to an excellent rating with two or three commands to their waiting minions.
Unless I'm entering in a password or data I care about, I ignore them too. Why? The "proper" response is to call up the server's admin, and manually verify the probably out of date or misspelled cert over the phone. It's faster to wait a couple hours for someone to fix the problem than it is to find out who you're supposed to call (and if you can call them, they won't have time to chat).
So, I think people just don't care.
6.8SPC TR of 550, l xwind at 6, drift rt at 26" drops 77". AT has 503 ft-lbs at 1403 fps. FT 0.86
I must say that it has been a LONG time since I purchased a cert. Thawte and Verisign were competing companies at the time. I know when we got ours there were LOTS of hoops we had to jump through to get it. We had to verify phone numbers, addresses and Dun and Bradstreet crap. I can't imagine that over the years they made it so just anyone would be able to purchase a certificate saying the were a new paypal site?
MISSING - Sig file. 2 years old black and white and very funny. If found please email me.
"If you do have a CA-signed cert, the connection still isnt secure. Thats the real problem." Are you sure of that ? The connection in itself AFAIK is secure / encrypted and cannot be snooped, what isn't sure is WHO I am talking to, and could well be talking to Vladimir hackov in Ukraine instead of Wells Fargo.
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
AVCWare Blu Ray Ripper
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.
I frequently get cert warnings for certain forum sites or other sites where it doesn't matter three shits whether the site it pretending to be someone else. In those cases I just click through the warning, not caring that it is misconfigured.
I'd never click through a warning to make an online purchase or enter personal information though.
Sometimes there's nothing wrong with clicking through a warning. I've found that to be the case more often than not with me.
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?
Usually such a warning comes from a website I know, which forgot to renew their certificate. I hate it that you need so many mouseclicks in firefox to finally view the content.
How many times have we (administrators, geeks, etc) shown something to someone and had a security warning pop up, and we just quickly ignore it and continue on?
Now granted, WE know what we're doing, but the user just watches us skip right over it.
Or, how many times have we set something up and haven't configured the security yet? So we tell our users that it's okay, just press OK and try it out.
The best example is when we get a software driver that has been unsigned, and the instructions say to just skip over the warning.
What kind of example are WE setting when we don't even follow our own advice?
-David
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.
There was an extended period last year where official sites were displaying warnings. I knew the sites were good...
It was odd but I guess they failed to update and the certificates expired.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
There's a possible flaw in this study in that these people were using a lab computer, not their own. Their own computers with all their stuff were not at risk.
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.
Speaking just from personal experienece, we're trained to do it at work by poorly designed and maintained "Enterprise" apps. The specific browser involved may concentrate towards IE6, but that doesn't mean anything except for the unholy number of "Enterprise" web apps that still require it.
They then brought 100 people into a lab and studied how they surf the Web.
If I'd be asked to participate in this kind of experiment I know my behaviour would be quite different from my normal behaviour:
I'm assuming they have some kind of monitoring software installed for the experiment, so no way I'd be entering any of my own personal information. Since I'm not entering any real data anyway, I probably wouldn't be bothered by any warnings, especially if you're asked to surf to a list of websites for the experiment I'd just ignore the warnings and get the list done with.
Even if the researchers asked me to treat some provided fake personal information for filling out I'd be tempted to just play dumb, fill in the forms and get the experiment done with, instead of e.g. calling the bank and asking what's wrong with their certificate.
**TODO** [X] Steal someone elses sig.
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.
It costs twenty fucking dollars to buy a certificate for a year.
If you can't afford that, then yes, I have serious concerns about the legitimacy of your site.
Don't thank God, thank a doctor!
Hopefully, this will help Firefox users realize what those warnings actually mean.
The reason they don't work is precisely because the old behavior allowed people to easily misinterpret just how serious a certificate warning is.
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.
I used to report certificate problems to my banks. Invariably the person in the data center would ask, "What browser are you using?" And when I told them Firefox or Safari, they would say, "well, you need to switch to Internet Explorer." They do not care about IE's lack of security. I click right thru bank security certificate warnings now, because I know it is pointless to report when certificates go out of date or have other problems.
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.
Those of you in charge of maintaining SSL servers, you might be interested to know that there's a new online assessment service.
Free, no strings attached (not even ads).
https://www.ssllabs.com/ssldb/
Cheers, Ivan
The issue of public self-signed certs seems best resolved by using Perspectives (http://www.cs.cmu.edu/~perspectives/firefox.html), which solves the man-in-the-middle problem using a distributed set of auditing servers to verify you are getting the same certificate others on the internet are.
This method has advantages over paying for a certificate from a CA vendor. It is possible for a determined man-in-the-middle attack to succeed without any errors on the client using social engineering or other measures to get a validly signed copy of the certificate for a site without being the actual site owner due to the lax verification measures used by some of these vendors.
Another common issue, companies should be creating their own CA certs and deploying them to clients in situations where the client is controlled (for example intranet sites), but most instead train their users to ignore these errors. See this example, (http://www.debian-administration.org/article/Creating_and_Using_a_self_signed__SSL_Certificates_in_debian) note that these basic instructions work on any operating system, not just Debian, using openssl at the command line.
StartSSL.com certificates are free and trusted by Firefox and Safari, among others
I didn't see Windows Internet Explorer listed. But it might be good for a site that's sufficiently geeky or Mac-y or HTML 5-y to attract a crowd with little IE representation.
GoDaddy certs (trusted by all browsers I've ever tested) are a whopping $15/year
Thank you for pointing this one out.
To lazy to search if someone already thought of that one... but, instead of having certificates signed by CAs why not just have only self signed certificates and add certificate's fingerprint to a special TEXT record in the DNS as it's done with SPF? I know someone could modify DNS replies on the fly and replace the fingerprint of the certificate and so on, but this could be taken care easily of by DNSSEC I guess...
"Yeah, it's kind of sad how regular people are expecting us programmers to have our shit together." - by Goaway (82658) on Sunday July 26, @11:11PM (#28832621) Homepage
WTF? We do WHAT WE ARE TOLD, & only suggest what needs doing & sometimes?? We are not understood, or even listened to, as to what is needed being indicated by us coders, & it gets "blown off" by mgt. & their "#1 lackies", the IT techs/network techs/network engineers (who, face it, are ONLY USERS WITH A BETTER PASSWORD, that cannot do the job without us coders inventing tools for them to MERELY USE, but that they barely understand & could not create themselves, period)).
AND, "excuse me":
IF I am told that doing the job ABSOLUTELY AS CORRECTLY AS IS HUMANLY POSSIBLE, interferes w/ time & budget constraints (that these mgt. know-nothings (not all, but many, have NOT even done the job nearly as long as I have, if @ ALL period) make insane delivery deadlines & tell us as coders, to "issue it anyhow with a list of known issues" (which usually are kept to "intermittent" ones, hardest type to 'zero-in' on)))...
Had it happen to me in 2006 in fact, when I was hired on to help a healthcare insurance provider in securing where they were putting the SSN# on the member ID cards & far more... which went FINE, the programs generating that info. were restructured thus to 'scramble SSN's' & instead, place in a member ID # in lieu of the SSN#).
Great, right?
WRONG!
The company was not securing the server &/or workstation infrastructure, period... nor educating end-users about what to use in say, a webbrowser, or not (such as javascript)... this, when I brought it up in weekly meetings, was "shut down" fast by the then CIO/CTO there, & I merely asked why... I was told "it would take too long to do" which was NOT true, I provided a prototype machine that ran ALL or MOST of their wares in fact, flawlessly, & it was indeed, security-hardened. What I used was already automated in group policies templates &/or .reg files + batches to merge them in seconds/minutes if need be, once it was proven across their ENTIRE enterprise & all of their apps.
I got fired.
(For merely pointing out that the person who was heading the IT dept. @ said organization/company, was a lazy incompetent stooge who was shackling myself & others there because of budgets etc. et al (great, until you get hit by a lawsuit for gross negligence, that is!))
APK
P.S.=> Funniest part was, my main detractor, their CIO/CTO, had setup TREND AntiVirus wrong, period! I also pointed that out in our weekly meeting, after I was attacked by he for pointing out what else NEEDED DOING, period.
E.G.-> My system turned up a virus & he said "Well, Alex has a virus!" yes, I did - but, I never setup the system, myself, in the first place (I had it handed to me with a virus on it no less, & when I asked if they were shadowing me, they said "no", & I said basically "HOUSTON: We have a problem!")...
They then turned to AVG instead but ONLY AFTER I POINTED IT OUT TO THEM IT WAS 6++ MONTHS OUT OF DATE in its signatures DB's on client rigs... &, they did so, WITHOUT LICENSING AVG PROPERLY NO LESS!
(Which is a violation of the software agreement AVG has no less in corporate environs on their FREE model)
Yes - this goes to show you how SHITTY the job is that is being done by our nearly TOTALLY UNQUALIFIED "fearless leaders" in this field...
(&, I am sure many of you devs have faced the same horseshit too! How sad... We only DO WHAT WE ARE TOLD, & get shit on for it? No... no way! You've just heard how it IS, from someone who has put up with crap like that @ the hands of BLATANT INCOMPETENTS (who never did the job as long as I had in fact, hands on, in the trenches for years to decades to LEARN MORE & better myself, for the betterment of those I work for))... apk
We're all accepting the results of this survey because it meshes with our intuition that people ignore security warnings. But the article says nothing of the method of the experiment. Were people told specifically to evaluate the warnings, or were they told to visit site X or Y to answer some questions? How much was the idea of security influenced by the authority of the person who gave them the URL? How important did they feel that encryption was to the security of the connection? I.e., did a portion of them decide that the encrypted connection was unimportant for the task they were performing? All of these things can factor into the results.
But assuming the results are valid, I concur with another poster who lays the blame squarely on the widespread misuse of certificates. Many sites use a single certificate for multiple URLs other than the URL(s) listed on the certificate. (https://m.gmail.com/ anyone?) Others fail to promptly renew their certificates before they expire. The attention people pay to warnings is inversely proportional to the frequency with which they appear, and proportional to the severity of consequences for failing to heed it. Relatively high frequency warnings with no visible consequences for ignoring it = 0 attention.
https://www.eff.org/https-everywhere
.. for one, popups are annoying, certificate security warnings included, and two, too much chatter, buttons to push, agree not agree, I just want to get to my link. The concept is good, the warning is important but the implementation is bad. Solution? Here's one, when surfing a site with a 'bad' certificate: 1) 'Lock' the OS 2) Run various tests on the website (phishing, etc..) 3) OS to change the browser skin with one that shows WARNING - SURFING SUSPICIOUS SITE, display this in large characters all around the browser window.
TOP DSLR Cameras Reviews of the top DSLRs
Theres the issue of encryption, and identification. Both your lax solution and browser's chicken little solution conflate the two.
If you're visiting your bank's site, you need to know that the connection is encrypted and you need to know that it is in fact encrypted for your bank and not a man in the middle.
If you're configuring your router, you don't need a certificate authority to assure you that your router is in fact your router. In fact it would be quite impossible to do anything of the sort. Even ignoring the logistics of adding $5 to the cost of every home router, it would be meaningless. An attacker would just have to extract a signed certificate from another of the same model to invalidate the entire process. (and there's no DNS record for DNSSEC).
For ubiquitous encryption, we'd still need certificate authorities to stop the Phorm asshats. ISPs could otherwise just rewrite DNS responses with their own key.
If it's your ISP pulling Phorm style man-in-the-middle asshattery, you still need a trusted third party to sign keys.
Well now lets look at this situation.
I use SAFARI and every once in a while I will see the message about an invalid certificate.
*IF* I am at a site that say is a newspaper. I ignore it as I am just reading articles and not doing any $$ transactions.
Isn't his a reasonable reason to ignore the message?