Secure Sockets Layer (SSL), also known as Transport Layer Security (TLS), is a security mechanism that gives you three guarantees:
1) No one can listen in on my traffic. (Confidentiality)
2) No one can modify my traffic. (Integrity)
3) I am talking to the correct server. (Authentication)
Over the web, trust is hard to come by. HTTPS takes the somewhat shaky building blocks of the web (DNS, HTTP) and adds SSL to make the communication channel more secure.
SSL doesn't always work as advertised. An attacker can perform a Man-In-The-Middle (MITM) attack and defeat all of the guarantees above. However, the browser will issue a warning when the certificate the attacker presents isn't valid (assuming the attacker hasn't actually compromised the private key of the domain in question). This should let the user know when the security of the SSL channel has been compromised.
I'd like to examine browser SSL warning messages. Lately, I've been thinking about the trade-offs that we make between security and usability. Jakob Nielsen's article on Password Masking made me think about the security "cargo culture" - we use the security mechanisms we're used to using, even if they aren't effective. And SSL warning messages are pretty ineffective at communicating risk to the average user.
I believe that the overwhelming majority of the SSL warning messages received in the real world are false positives. I'm basing that on my personal experience, of course, and I assume that I can reliably tell the difference between a malicious MITM attack and a bad web server configuration. I can't remember ever feeling there was a chance that someone was actually attempting to hijack my SSL session by presenting a false certificate, but I've encountered numerous SSL warning messages for a variety of tamer causes.
Certificates can be expired, malformed, revoked, for the wrong domain, or self-signed - there are plenty of reasons why SSL certificates don't validate properly. There are only a few causes, however, that I've seen with any frequency: expired certs, certs for the wrong subdomain, certs for the wrong domain, and self-signed certs.
The problem is that people (including myself) have been trained to ignore SSL warning messages, because they effectively mean "do you want to wait until the server administrator fixes the problem, or do you want to do your job right now?" Once people start to ignore these messages, it makes the attackers job easier. As with any security technology, we should be wary of the callousness caused by false positives.
I'd like to humbly suggest that we re-consider the current binary approach to SSL warning message (the certificate is valid, or it isn't) and consider incorporating the role of human foibles (specifically, the web server administrator) in the SSL experience. Let's examine two common configurations errors I mentioned previously:
Expired Certificates
Based on personal experience, I would guess that expired certificates are probably one of the most common SSL warnings. They are also one of the most benign.
Meaning: The expiration date on the certificate, or one of the certificates in the validation chain, is in the past.
Usual cause: The server administrator forgot to create and install a new certificate.
Risk: As an attacker, I'd find it a lot more difficult to find an expired legitimate certificate for a domain than create my own self-signed certificate. Alternatively, it's easy for an administrator to forget to swap out old certificates before they expire. The likelihood of attack here is low.
Certificate with an Invalid Sub-domain
This warning is also fairly common, especially when you manually enter the an HTTPS URL. Yahoo (https://mail.yahoo.com/, certificate is for www.yahoo.com) and Verisign (https://verisign.com, certificate is for www.verisign.com) exhibit this error. These warnings are, in my opinion, usually pretty trivial.
Meaning: The certificate is for a different domain than the URL, but the root level domain is the same.
Usual cause: The server administrator is using the same SSL cert for multiple DNS-resolved endpoints.
Risk: If an attacker can get a hold of a valid certificate for anything on the domain, something is usually wrong. Perhaps there's a shared hosting situation or some other extenuating circumstance. This is much more likely to be a configuration error than an attack.
I'd like to suggest that both of these cases display a more appropriate warning message. Something like :
The SSL certificate is expired. Please contact your administrator to remind them to update the certificate. There is a small chance the security of the session is compromised.
For bad sub-domain errors, the message could read
Although you are visiting <sub-domain>, the owner of <domain> can read your data. Would you like to continue?
We could even provide some metaphors – perhaps the idea of an expired or out-of-state drivers license may be helpful.
Certificates with completely mismatched domains or certificates that are self-signed could also be legitimate, but are also pretty easy for an attacker to create. We can at least draw attention to these more dangerous scenarios if we soften the user experience around the previous two problems.
I know the latest versions of browsers such as IE and Firefox have changed their SSL warning message strategies, usually in a bid to scare people away from using sites with broken certs. IE has a scary red button you need to click. Firefox requires a half-dozen clicks to continue. I think there should be a little more emphasis on clearly expressing the risk to the user instead of assuming all broken certs are created equal. While the user may not make the right security decision every time, the overwhelming majority of false positive SSL warnings indicates to me that the current system isn't working.
