SSL certificate warnings – nuisance or value?

2010-02-01

Chester Wisniewski

Sophos, Canada
Editor: Helen Martin

Abstract

‘[SSL certificate] warnings are a nuisance for the same reason they may help.’ Chester Wisniewski, Sophos


In a paper entitled ‘Crying Wolf: An Empirical Study of SSL Warning Effectiveness’, Carnegie Mellon researchers examined the results of a study on user behaviour in response to invalid SSL certificate warnings. While the paper makes for an interesting read on how humans perceive risk, how too much nagging breeds disregard, and how the sternness of language used to explain the situation changes perception, it mostly leads me to wonder what the point of these warnings is at all.

Primarily, the warnings protect against Man-in-the-Middle (MitM) attacks. If you are using a non-compromised browser on a non-compromised machine and manually enter your online banking URL, these warnings could alert you that something is amiss. However, I have not heard of anyone going to the effort of hijacking SSL sessions in any volume in order to execute an attack like this.

A MitM attack requires the attacker to be able to intercept/redirect the connection between a victim computer and an SSL website they are communicating with. If the interloper tried to sign a certificate convincing the client it was Chase Bank and they were not taking advantage of the SSL null byte vulnerability reported last summer at Black Hat, then the user would receive a warning that the certificate was self-signed or somehow modified. It’s certainly possible that this would protect users, but the effort required for this type of attack tends to limit the number and scale of such attacks.

Warnings are a nuisance for the same reason they may help. Almost 100% of the time they can safely be ignored. If you receive a warning at your online banking site, more often than not the warning is because your bank’s certificate has lapsed and they have been unable to retrieve a new one. This is not something your end-users should be concerned about, nor is it something they are likely to figure out based on the way browsers present the information.

Why warn your users of something that is not really indicative of an attack? This simply leads to the ‘boy-who-cried-wolf’ scenario. Every false warning or pop-up undermines all the work you have done as an administrator to secure a user’s workspace. The users begin to second guess your entire approach and question other technologies you have used, and it can have consequences outside of the specific application.

Most attacks are phishing attacks and do not utilize SSL to begin with. If the attacker wants to be sure the padlock appears in the browser they could simply purchase a certificate for their bogus domain – it is trivial to request an SSL certificate from many providers. On 22 January I looked at approximately 100 phishes in our spam queues, and none of them used an https connection. Many URLs were obviously bogus, while some tried to manipulate the way the browser displayed the domain name to trick the user.

It is my opinion that more effective SSL warnings will not improve Internet browsing safety. The Carnegie Mellon paper does make an excellent point that may be better used in other ways. When designing software and choosing which options we present to users, we should be careful of how and when we interrupt users’ work flow.

There is value in telling a user that you have blocked access to his USB drive, or that an email was blocked because multiple credit card numbers were contained in an attachment, but when you start sending alarming messages to users that they either misunderstand or that present them with a problem they cannot fix themselves, you start to create a sense that warning messages should be ignored. Users want to get back to performing the task that was interrupted and we need to design our systems to ensure that we only interrupt them when it is truly important.

Security needs to be simple and transparent to be truly effective. As an industry we need to rethink how we approach the concept of SSL certificates for verifying identity. We cannot depend on end-users to understand the implications of public key infrastructure and digital signatures and make the right choice.

twitter.png
fb.png
linkedin.png
googleplus.png
reddit.png

 

Latest articles:

Throwback Thursday: The Thin Blue Line

In 1994, UK Fraud Squad detectives started making inroads into the most puzzling 'Whodunnit' since the Great Train Robbery. Had an outbreak of computer crime swept Britain? No, it was all part of a police training program.

VB2015 paper: Effectively testing APT defences: defining threats, addressing objections to testing, and suggesting some practical approaches

As targeted attacks gain more attention, and protection developers pay more attention to the implementation of new defensive technologies, the need arises for the testing of product efficacy with respect to this new kind of threat. However, compared…

Throwback Thursday: Peter-II - Three Questions of The Sphinx (July 1993)

How much does a user really need to know in order to defend his computer from computer viruses? In 1993, the latest news from the anti-viral battle-front was that if the user wanted to defend the contents of his computer from viral attack, he should…

VB2015 paper: The ethics and perils of APT research: an unexpected transition into intelligence brokerage

Information security researchers are increasingly finding themselves involved in investigating state-sponsored or geopolitically significant threats. In his VB2015 paper, Juan Andrés Guerrero-Saade looks at the perils and ethical conundrums involved…

VB2015 paper: Digital ‘Bian Lian’ (face changing): the Skeleton Key malware

When the Skeleton Key malware is installed on a domain controller, the attacker can play a face-changing trick on the domain by logging in as any user it chooses and performing any number of actions on the system including, but not limited to,…