Too Many Security Warnings Results in Complacency

Research that proves what we already knew:

Crying Wolf: An Empirical Study of SSL Warning Effectiveness

Abstract. Web users are shown an invalid certificate warning when their browser cannot validate the identity of the websites they are visiting. While these warnings often appear in benign situations, they can also signal a man-in-the-middle attack. We conducted a survey of over 400 Internet users to examine their reactions to and understanding of current SSL warnings. We then designed two new warnings using warnings science principles and lessons learned from the survey. We evaluated warnings used in three popular web browsers and our two warnings in a 100-participant, between-subjects laboratory study. Our warnings performed significantly better than existing warnings, but far too many participants exhibited dangerous behavior in all warning conditions. Our results suggest that, while warnings can be improved, a better approach may be to minimize the use of SSL warnings altogether by blocking users from making unsafe connections and eliminating warnings in benign
situations.

Tags: , , , , , , ,

Posted on August 4, 2009 at 10:01 AM • 32 Comments

Comments

Billy Oblivion • August 4, 2009 10:39 AM

The organization I work for uses a proxy that has the ability to do a MTM attack. I never get a valid SSL cert.

And yes, I do consider this a problem.

vwm • August 4, 2009 10:40 AM

One of the reasons why I would like to see sites with self-signed certificates presented by the browser like plain unprotected sites. No coloured address bar, but also no annoying warnings.

Dave Andersen • August 4, 2009 11:09 AM

vwm: Or try using Perspectives for Firefox ( http://www.cs.cmu.edu/~perspectives ). It does some, though not all, of what the Sunshine paper that Bruce linked to suggests in terms of minimizing warnings and making the real warnings stronger. Full disclosure: Perspectives was written by one of my students–but I use it because it saves my sanity with self-signed websites, not out of loyalty.

Kevin • August 4, 2009 11:14 AM

@Billy Oblivion: You should get a “valid” certificate if your employer’s SSL Intercepting proxy and corporate desktop/browser are configured correctly.

Yes, it sucks for privacy, but a well-implemented MITM proxy will validate the server certificates (possibly more stringently than some browsers would) and use it’s own certificate to sign a new synthetic certificate, using a key that has also been pushed out to all the browsers/desktops.

One advantage of SSL Intercept is that the proxy can enforce a policy (with appropriate exceptions) on cert strength, CAs, and forbidding self-signed certs, rather than trusting your users not to just click “Add Exception” when they come across a funky site…

Phil • August 4, 2009 11:26 AM

Same problem applies to those endless prompts spewed out by personal “firewalls” and Microsoft’s wonderful (not) UAC.

D0R • August 4, 2009 11:26 AM

I remember surfing on a website that
1) on its home page, presented a SSL certificate with a Domain Name mismatch i.e. the certificate was released to a different domain and host name;
2) on its internal pages, for a secure connection to the intranet, used a digitally signed Java applet… with an expired certificate.

The scary thing is that it was the website of an Italian Certification Authority.

Impossibly Stupid • August 4, 2009 11:31 AM

“cannot validate the identity of the websites they are visiting”

Wouldn’t it be more correct to say they cannot validate the certificate authority? That seems to be the crux of the problem with the broken way web browsers handle SSL. Warnings for self-signed certificates are false positives 99.999% of the time, so it’s no wonder that users just click right through them.

Henning Makholm • August 4, 2009 11:41 AM

The paper says:

Among our strangest results were the answers to the questions: “Before this study, had you ever seen the warning you saw at the bank/library web site?” … We do not think 30% of our participants have been scammed by man-in-the-middle attacks at their bank

Apparently the authors think that a “yes” answer means that the respondent has previously received a certificate warning when accessing the bank website.

But it’s much more probable that the respondents simply parsed the question differently: “had you ever seen [the warning you saw at the bank/library web site]?”, i.e. that they were being asked about whether they had ever seen such a warning before, not where they saw it.

Jason • August 4, 2009 11:44 AM

When a proxy breaks SSL to do its MITM, it should take it upon itself to validate the certificate of the true destination.

For example, the proxy server I use validates that the CA is a trusted CA (definable in the proxy config), that the certificate is not expired, and that the certificate name matches the host name. If any of these checks fail, the access is blocked. There is no option to “access it anyway.” If someone needs to get to a blocked site, they have to go through the Help Desk. The access is evaluated, and changes to allow the broken cert for that specific site may or may not be made.

Incidentally, we use an Active Directory push to get end-user systems to trust the certificate that the proxy server uses to impersonate the destination.

phessler • August 4, 2009 12:10 PM

hey firefox, pay attention!

I hate hate hate the firefox 3.x ssl certs warnings. this above behaviour is what they are encouraging. I have completely and totally stopped paying attention to ssl certs, because of the ff3 problems.

bob • August 4, 2009 1:00 PM

I typically drilldown through the certificate information to find the root vouching authority.

The problem is, even the “big companies” (like thawte or verisign) have a -bunch- of different CA names, titles and spellings. Granted the browser recognizes the cert, but if Verisign, for example, has 27 different spellings of their root CA, then that gives 27 times the possibilties to generate a valid-looking hash collision signature and create a real-sounding but totally fake CA that is recognized by the browser.

Each root authority should have ONE AND ONLY ONE name that they sign ALL their certs with; like “VeriSign Prime Certificate Authority” or “DoD Root CA”.

Bill P. Godfrey • August 4, 2009 1:18 PM

How about the browser people making the SSL certificate warning into an unpassable error?

(People using self-signed certs really need to be singing with their own CA root instead.)

Tynk • August 4, 2009 1:22 PM

@ Bill P Godfrey

That would be inching rather close to Nanny State Legislation. Making rules rather then teaching people proper use.

Clive Robinson • August 4, 2009 1:55 PM

….

“We then designed two new warnings using warnings science principles”

What branch of science does “warnings science” fall under? It’s a new one on me…

Or is it like metrology (not a spelling mistake see http://en.wikipedia.org/wiki/Metrology ) something we don’t get to here a lot about unless it’s a speciality we have/use.

Clive Robinson • August 4, 2009 2:08 PM

First off certificates to web sites are worth approximately squat.

That is if you check back to the root certificate authority and look up their T&Cs you will usually be more than somewhat surprised (unless you where expecting “we wash our hands…”).

That aside there is the question of does the user need a warning on loading the page or when doing a POST/GET or moving to another page?

Perhaps if the browser worked a little more elegantly within the context of what the user was doing with these issues then the warnings would be more meaningfull to users (I hear HAL saying “Dave I don’t think you should do that..” 8)

However that gives rise to the issue of what is and is not data with security strings attached. How does the browser recognise such data unless it has stored it away which is probably a greater security risk.

Bill P. Godfrey • August 4, 2009 2:14 PM

@Tynk

I was thinking more of the browser makers might want to do it willingly. The world would probably demand an “advanced” option to make the error a warning again.

In a nutshell, I’d say the best thing™ would be that lay people are prevented from going through the SSL warning. (Not by force of state, but just because its the right thing to do.)

pstj • August 4, 2009 4:32 PM

One way to make folks more responsive to security warnings is for the warning to instruct them what they can do.

Most people look at warnings like this and think, “So?” Not one in a million internet users know what to do when so warned.

Can we pass a law somewhere that every security warning or every type must include appropriate instructions to respond to the warning?

neill • August 4, 2009 6:25 PM

the whole system is broken and not working correctly.

checking certs (and especially getting new CRLs) got to be easy/convenient enough so that the ‘normal user’ is able to do it on their own

an example: i do NOT trust ‘turktrust’, but after removing it i’ll see it again as ‘built in security token’ – what if it’s compromised? do i have to wait for the next FF update?

(nothing against the turkish, it’s just an example)

Nostromo • August 4, 2009 11:00 PM

Installing a new root certificate is beyond the sophistication level of most users, so if you expect users to take certificate warnings seriously, you are limited to CAs pre-defined in the browser.
Mozilla has a procedure for accepting CAs:
http://www.mozilla.org/projects/security/certs/policy/
but of course more than 50% of all users (and probably more like 95% of non-technical users) use MSIE. The procedure for a CA to get its root certificate shipped with MSIE consists mainly of paying $50,000 to Microsoft.

Calum • August 5, 2009 4:06 AM

@Clive – Absolutely right. Certificates are worse than worthless. I believe a user should pay money to subscribe to a root certificate – that would bring the economic incentives into line with the goal of security for the end user.

Cassandra • August 5, 2009 5:09 AM

One way of detecting SSL proxies is to remove all the root certificates from your browser. As some posters have said, certain organisations ensure their users browsers have had the SSL proxy’s certificate added, making MITM attacks easy.

Problems I have found with removing the root certificates from Firefox are:
a) It is extremely laborious
b) It makes Firefox upgrades fail. I’d add the appropriate certificate back in, but the automated upgrade process doesn’t let me determine which one that is.

The potential downside is having to go through the Firefox UI to add certificates back in when visiting SSL using sites, but once you’ve done your usual ones, it’s not too bad.

Bill P. Godfrey • August 5, 2009 5:20 AM

I would love to see a world where browsers were delivered without any root certs. (But then I am a nut.)

The CAs would have to communicate with the public and earn their trust.

Browser makers would have to improve their certificate management code to allow people to securely import CA certs.

Websites would want to offer a many certificates by different CAs instead of the current one-CA-per-site, opening up the market to fringe players.

It’ll never happen though.

Cassandra • August 5, 2009 5:52 AM

@Bill P. Godfrey

I’d like removal of root certificates from browsers to at least be an easy option.

Mark R • August 5, 2009 6:54 AM

There’s also the issue of browser behavior on non-SSL sites. As Moxie Marlinspike pointed out with sslstrip, users get scary warnings when visiting an HTTPS site with an expired certificate, but no warning at all if they visit that site (or are silently redirected by a MITM) through HTTP. In recent browsers, the visual cues distinguishing between SSL and non-SSL have been toned down significantly, while the warnings of invalid SSL certs have become much more alarming. Sslstrip takes advantage of this by just intercepting a client’s https request, redirecting the user to http, and MITM from there with no cert warnings at all.

I agree with the suggestions of having browsers default to disallowing connections to invalid SSL sites, but there are legitimate reasons for connecting to servers with cert. mismatches. E.g., you manage a set of servers that are load-balanced under a single DNS entry, but need to connect to a particular one by machine name to diagnose a problem.

dhasenan • August 5, 2009 8:21 AM

The problem is that you cannot run some sort of query to find the SSL certificate for a domain except by asking the site running on that domain. If there were some coordination between CAs, there could be a lookup system to prevent MITM attacks (unless they could suborn the CA queries).

If this were the case, it would be quite clear whether a site using SSL should be trusted.

There would be some issue with a person forging a self-signed certificate and using a MITM attack when someone let their certificate expire. But you can mitigate that by having CA queries return recently expired certificates.

grendelkhan • August 6, 2009 1:00 PM

“a better approach may be to minimize the use of SSL warnings altogether by blocking users from making unsafe connections and eliminating warnings in benign situations.”

Isn’t the whole point of TLS warnings that this is an impossible-to-automate situation? Given the technical nature of the system, benign situations look exactly like unsafe connections.

I, too, am bothered by Firefox 3 demanding that I either accept a certificate permanently or not view the site. When I’m reading through an HTTPS-only mailing list archive (yes, a read-only, publically-accessible site), I don’t really care if my traffic is unencrypted. I just want to read the damned messages.

But I suppose there’s a common pitfall in trying to make the dialogs easier to use; I’d imagine that simply not showing the security emblem would fix the issue–pages with bad TLS are, in essence, as good or bad as unencrypted pages.

Anonymous • August 6, 2009 6:50 PM

Why do browsers always try to hide all the cryptography from the user while at the same time undermining security? A browser should at least display the secure hash, or “fingerprint” of an SSL certificate presented by a secure site.

Then the user would find it convenient to manually verify the certificate fingerprint.

Andrew S • August 13, 2009 5:22 AM

Why display warnings at all if a cert is invalid? Over 99.999% of the time, the warning is due to either a misconfigured, expired, or self-signed cert. I think a more appropriate behavior would simply be to not show the “lock” icon.

A https site with an invalid ssl cert is still safer than a site running on plain http. If a browser is displaying warnings for sites with bad certs, it would be consistent if it displayed warnings for all non-ssl sites as well.

Instead, we have firefox 3.x, which takes four clicks to accept a self-signed cert…what was the motivation behind that?

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.