What does the little lock icon mean in my browser? – Part 3

July 17th, 2009 by Chris Leave a reply »

In the first two parts of this post, I described what goes on when creating an HTTPS connection to a Web server. In this third and final part I’ll get into what can go wrong.

What can go wrong if I trust the rabbit hole?

For the sake of argument let’s assume we “feel” the HTTPS process is trustworthy all the way down to the bottom of the rabbit hole. Our first problem is we never actually go there. Check out Figure #1. This shows some of the configurable options for Internet Explorer 8. Note the two circled lines.


The first one, “Check for Publisher’s certificate revocation” attempts to validate the locally stored digital certificate. Its on by default, but all its really doing is checking to see if the trusted third party has identified their signing server as being compromised. If they have not figured it out yet, or if an attacker is able to compromise this session, all bets are off. In other words, in part 2 I described a path all the way down the rabbit hole to a self signed digital certificate. What this option is tells us is that we are never going to check down that far. We’ll do a quick check one level deep and stop there.

Now, look at the second line which is circled, “Check for server certificate revocation”. Note this option is turned off by default. So while you could be checking to see if the Web server your talking to had it’s digital certificate revoked, you don’t bother because of an options setting. The concept is “Hey you can trust Verisign because they never mess up”. In part 2 we also discussed how this is not always the case.

Does SSL and TLS always encrypt my data?

As mentioned in part 1 of this post, SSL and TLS are a framework. They pull together a lot of possibilities for securing your data but leave the particulars to the negotiation between the client and the server. Consider the picture shown in Figure #2. These are the SSL and TLS options for a Firefox Web browser. Note the lines within the red box.

Firefox let's you select which privacy options to support

Firefox let's you select which privacy options to support

The first option says “Use RSA for initial authentication and HMAC-MD5 to authenticate each packet”. The second option says the same thing, but to use HMAC-SHA for packet level authentication. Notice anything missing? Like… how should we be encrypting the data? Both of these options specify authentication without any kind of encryption.

Why is this even a possibility? Because sometimes its enough to know your datastream can not be changed in transit. You might not be worried about people seeing the data or it may be possible that you are located in a country which does not let you encrypt your information. If either is the case, SSL and TLS can still help you out.

Now, remember back to part 1 of this post I said that in an SSL/TLS handshake we go with the highest level of data privacy supported by both ends of the connection. With this in mind, you hopefully will never see “no encryption” negotiated in the wild. If however this is all the remote server wants to support we may be in trouble. Luckily Firefox has both of these options disabled by default. But what about other browsers? That’s the kicker. Most browsers will let you select the version of SSL and/or TLS you want to support. They will not let you drill down to specific protocols. So this could be on and you would never even know it.

And now back to that little lock icon

I have a love/hate relationship with the little lock icon. I like the idea of making it simple for users to figure out when their data is being secured. I hate the idea that the accepted implementation is a little graphic that it very easy to duplicate. For example, have a look at Figure #3. Note the bank has placed a copy of the lock icon right on the logon page. Does this really tell us the data is being secured? Absolutely not! It could just as easily be a picture of a cute kitty cat. In this context the lock icon is nothing more than a display graphic.

Note the lock icon within the HTML page

Note the lock icon within the HTML page

OK, so let’s look around our browser window a bit. In older browsers I got used to seeing the lock icon at the bottom right of the screen. Hey look at figure 3 again, there’s a lock icon at the bottom right of the window! So that tells us our data is secure, right? Nope. In IE8 Microsoft changed the browser layout. That specific lock icon will tell me if the browser is filtering content coming from the Web site. So a user who does not do their homework will probably think every site on the Internet has been secured. Why didn’t they use another graphic to avoid this confusion???

Look to the right of the URL. Hey, there’s the lock icon! Yup, so this is where the user is suppose to look. There is just one problem however. If you are reading this post directly from my site you will notice you also have a lock icon to the left of the URL. All I did was mess with favicon. So by drawing the users eye to the URL to look for the lock icon we just made it easier to fool people into thinking their data is secure when its really not. Will the typical end user notice/care that the lock icon is before or after the URL? Yuck.

So where are we at

To summarize what has been discussed so far:

  • Liberal use of the lock icon can fool users into thinking their data is secure
  • Our security protocols support transmission of data without encryption
  • Digital certificates have a server at the bottom of the rabbit hole saying “trust me because I say its OK. Here, have some candy little geek” (OK, the candy bit is not part of the spec ;) )
  • The rabbit hole really is not a problem because we never look all the way down it anyway
  • We have security checks we choose not to use
  • We produce error screens that end users have become accustom to ignoring
  • If an attacker can break initial authentication, the integrity of the whole session falls apart
  • Security experts keep figuring out how to forge certificates and are finding new exploits all the time

Sanity check time

OK, so its easy to feel like the whole thing is insecure and we should run away to Vermont and build a moat around our house (inside joke, I know someone who has done this). Here’s some simple advice for the non-cipher- wienies that will help keep you relatively secure on the Internet. If you want full protection, disconnect now and build your own moat.

1) Look for HTTPS in the URL

Forget about lock icons and other fancy stuff. If you see “HTTPS” instead of “HTTP” then you know you are using SSL or TLS to secure the datastream. Remember this does not guarantee data privacy, so we still have more to do.

2) When in doubt, check the connection

Take a look at Figure #4. When I connected to this site and saw “HTTPS” I double clicked on the lock icon. That produced this dialog box. There is some real useful information here, like what level of encryption is being used to provide data privacy. This will tell me if my data is “safe” (encrypted).

Double click the lock icon during an HTTPS session to produce this screen

Double click the lock icon during an HTTPS session to produce this screen

This will also identify who issued the digital certificate. Remember the bottom of the rabbit hole is warm fuzzy. This means you really have to ask yourself if you think the issuing company has a clue about security, because you have little ability to check for yourself. Personally I never trust a server or company that signs their own certificates (this means you American Express!) because your options for verification are even more limited. They are just begging to get their client’s data compromised in order to save a few $$$ by not purchasing a certificate from a well known authority (note: Its OK to sign your own certs if you manage both ends of the connection, but this is not the case when we visit an e-commerce site).

3) Tweak your browser options

Finally, leverage what ever options your browser gives you to lock down your HTTPS sessions. I mentioned initial authentication comes down to a subjective judgment call, and the security of the rest of the session teeters on this point. If you sleep better verifying all certificates, go for it. If you feel comfortable just verifying with local info, that’s fine too (its your data after all). Yes SSL and TLS have some issues, but its the only game in town so do the best that you can with it.

4) Leverage your common sense

Last December I logged on to my bank site to pay some bills. When I was redirected to the payment server, I was presented with a self signed certificate. I’ve used this bank for years and know they use Verisign to sign their certificates. I immediately told my browser “no thank you”, and found out a day later the site had been hijacked.

The best way to keep your data safe is to use your head. If things do not look right, there is probably a reason why. While it can sometimes be hard to wrap your brain around the intricacies of technology, good old fashion street smarts can go a long way towards keeping you out of trouble.

That’s about it. Hope you found this info useful and don’t forget to tip your waiter!



1 comment

  1. Vinc says:

    Hi Chris,

    thank you for your explain. It’s the best guide I ever seen.

    But I’ve a question: If you go on name.com all the site s with “https” and lock icon.(if you just type https://www.name.com)

    When you go to checkout, the lock icon disappear but the address is still https.
    Now, I’ve ask to my browser and It show me the answer: the page of checkout has element encrypted (the fields for credit card, I hope) and some fields non encrypted (the advertisment and so on, I presume).

    So, what I do ??? Can I trust to a page build like this ? The site is safe and certainly serious, but how do I know that the information on the page can not be intercepted?


Leave a Reply