The yellow padlock

30 11 2011

Web browsing is a common activity for people nowadays; if we don’t browse to search for something, we do to shop, to check our bank accounts, to send emails, watch videos, etc. The number activities we can do at modern websites is immense; moreover, the tendency is to have even more and more significant activities performed this way through cloud computing and other technologies.

However, in several of these cases the interaction requires some level of security. In above mentioned scenarios we would expect to have some security when we shop, check bank accounts or send emails at least. There are few things that we as users can do on our end to enhance the security like having strong passwords and keeping them safe and look for the “yellow padlocks” in the website if we don’t understand the difference between http and https and look for it in the address bar.

The yellow padlocks exist since early versions of the most popular web browsers and have been implemented in newer versions and newer browsers, in many cases maintaining the symbol of a padlock that although it might have lost its color in some cases it can be displayed as locked or unlocked to remind the user of the security implemented in the server. Some people have been educated to trust blindly whenever they see a closed padlock and don’t even question what is happening behind scenes; in fact from my experience I’ve seen that people many times don’t even know what the yellow padlock really means and the security decisions we are making just by trusting it.

For some people that dig deeper and try to understand, or that have been educated to question (like myself) the findings of the reality of yellow padlocks might be a little bit scary. By this I don’t mean that they provide no security, but only that we should understand what is behind and to not just trust the symbol just because.

In simple terms the padlocks mean that the connection being made between the server and the client supports the implementation of SSL/TLS encryption through the HTTPS protocol instead of HTTP which means that the information sent back and forth could be encrypted.

Moreover, not any website can just show a padlock in the website. In fact, for a site to display a padlock it requires the website to be validated by Certificate Authorities which will issue a certificate that then is used to validate the SSL connections [4]. This presents the first issue we should take into consideration: Do we really trust the certificate authority? These certificate authorities have a process to become one and try hard to maintain its credibility (after all that is what their business is about, to have credibility so you can trust them), however, there has been cases of certificate authorities that lose their credibility because of different reasons; so to what extent can we trust the current ones?

Obviously this is beyond the case when we try to log to a website that has a certificate that expired, is invalid or issued by a certificate authority not previously defined by our browser. Nowadays, browsers come with a predefined set of “trusted” certificate authorities and therefore any website using a certificate from them would be trusted as reliable by the browser [3]. There are cases when the websites use authorities that are not specified in this list, think for example back to the day you logged in for the first time to an HTTPS website hosted at CMU and you probably were prompted about the unknown certificate and if you wanted to trust it or not. Many people just trust the certificates when they appear because they are from sites they want to go to. Anyway, going beyond the user education issue and back to the topic, we need to understand certificate authorities and their reliability according to us and nit just what our browsers predetermined to ensure that the websites are legitimate and trustworthy.

After we defined trust of the certificate authorities, the padlock can then be closed and the connection to the server can be made using therefore SSL/TLS which refers (as expressed before) to a method of encryption and authentication on the World Wide Web. SSL is a protocol that is implemented between the application layer and the transport layer (between HTTP and TCP/IP) and provides for three main aspects [1]:

  • Server authentication
  • Client authentication
  • Data encryption.

The server authentication refers to the aforementioned and is performed by confirming the server’s identity by checking its certificate to be valid and issues by a trusted certificate authority. The client authentication is a similar process in which the server is the one to confirm the identity of the user by a similar process; however, many users do not have certificates and therefore this optional aspect is not implemented in the connection [1].

Data encryption is the third aspect and the second point of concern related to the padlocks because it is an optional requirement in the connection specified as such in the SSL handshake process [1]. Without going into detail of the handshake process, there is a possibility that the session if performed without having an encrypted link. So, how much do we trust now that the connection is secure if it could be not encrypted? The implications of this issue are huge, because the traffic sent and received is then subject to potential attacks or exploits, for example, a simple sniffer tool could read the information being sent and/or received as plain text and use it for malicious purposes or perform man-in-the-middle attacks [2].

In conclusion, despite of how used we are to web browsing and the different activities we do while surfing the web, it is important to understand what is happening behind the scenes. The padlocks are a good example of mechanisms that we are used to seeing every day and trust without question. After more about this, are you curious to see which certificate authorities are you trusting? Would you question yourself next time you see a padlock? I surely hope so.


[1]. Lidner, Martin. Crypto in the real world. From the lectures at Heinz College, Carnegie Mellon University. Course 95-753 Internet Security. 2011.

[2]. Microsoft Corp. Microsoft Security Advisory (2588513) – Vulnerability in SSL/TLS Could Allow Information Disclosure. September, 2011. Microsoft Security TechCenter.

[3]. Naraine, Ryan. SSL Broken! Hackers create rogue CA certificate using MD5 Collisions. December, 2008. ZDNet.

[4]. Instant SSL. SSL Certificate Validation. 2011.




Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: