2010-02-01
Abstract
‘[SSL certificate] warnings are a nuisance for the same reason they may help.’ Chester Wisniewski, Sophos
Copyright © 2010 Virus Bulletin
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.
