Posts Tagged ‘HTTPS’

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

July 17th, 2009

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

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

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

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 »

Posted in 2-alert, VPN

Tags: best practice digital certificates HTTPS lock icon SSL TLS

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

July 16th, 2009

In my last post I started talking about why your data might not be as secure as you think during an HTTPS session. We made it as far as the mandatory handshake requirements with SSL and TLS. In this post I’ll get into the optional features which is the start of where things can go wrong.

Optional portions of the SSL/TLS handshake

After the initial client/server exchange, the two end points are free to choose which options they feel are appropriate, depending on how the administrator has configured them. Next we could:

Client can check the authenticity of the server using local info
Client can go back to the trusted authority and check the certificates authenticity
Client can check the authenticity of the trusted authority’s issuing server
Client can send a copy of its digital certificate to the server
Server can validate the client’s digital certificate if it has one
Server can require the client to have a valid digital certificate

Wow! Lots of possibilities. We typically don’t implement the last three unless we have control of both ends of the connection (like with a VPN). For a secure connection to a Web server, we’re typically looking at just the first three possibilities.

How digital certificates work

First, let’s talk about those digital certificates. A digital certificate contains the public key for the entity described within the certificate. So the server is basically saying “This is who I am and here is my public key for asymmetrically encrypted communications”. The way you know you can trust this certificate is that it has been digitally signed by a mutually trusted third party, like Verisign. Specifically, its been signed using the private key of a certain server under Verisign’s control. The concept is you can use the public key of the Verisign server to check the signature created by its private key. If the hash validates, you know the digital certificate has not been messed with.

OK, here’s our first problem. The information we use to validate the web server’s certificate is actually a copy of the Verisign server’s digital certificate stored on the local system. Hummm. So if the client becomes compromised, we can fool it into thinking a bogus digital certificate is actually legitimate, right? Absolutely. However this would only be useful in specific situations. If I can compromise the client there are probably easier ways to get access to the information I’m looking for.

If we want to ensure we’re safe however, we can go with option #3 above and check the validity of the locally stored Verisign certificate. This would send us out to Verisign server #2 to get its digital certificate. If we want to insure that our copy of Verisign server #1′s digital certificate is OK, we can use Verisign server #2′s public key to check the hash. If the hash validates, we know the digital certificate for Verisign server #1 is valid.

Hummm. So how do I know an attacker didn’t mess with the transfer of Verisign server #2′s digital certificate? Because that has been digitally signed by Verisign server #3. Go get that server’s public key and check the hash. How do I know Verisign server #3′s cert has not been messed with? You guessed it. Go get the digital certificate from Verisign server #4. While this sounds pretty complex (and it is!) this gives us sound math we can work with. In other words, smart crypto people can look at this math and predict how safe it is to use. Cool. I’m a geek so trusting math is a natural. The problem however occurs at the bottom of the rabbit hole.

Why should I trust you?

Eventually we will run into what is called a self signed digital certificate. This is basically a server’s way of saying “trust me because I say so”. In other words, there is no math to calculate if we should trust this server or not. All we have is “warm and fuzzy”. In other words, we need to sit in a Buda pose, sign Kum Ba Yah, get in touch with our inner child, pointy up our ears, and ask ourselves “How do we feel?”. Really, that’s all we’ve got, and there is no wrong answer because its subjective. If we “feel” that final system is secure, then it is. If we “feel” it is insecure than it is. There is no math to help point us in one direction or the other.

What if the trusted third party messes up?

So you may be asking yourself “All that sounds great, but what if the trusted third party makes a mistake and gives a digital certificate to the wrong party?”. First of all, that could NEVER happen. Oh wait, it has happened. Seriously, this is a valid concern as the chances of catching this after the fact are minimal.

Its possible to “revoke” a digital certificate. This is a trusted third party’s way of saying “Oops, we screwed up. You really should not trust that digital certificate we said is trustworthy”. So the concept is, when you get the Web server’s digital certificate you can go back to the issuing server to see if its been revoked.

OK, that’s set the groundwork for our HTTP session. In the next installment we’ll talk about what can specifically go wrong if we trust the security of the rabbit hole.

1 comment »

Posted in 2-alert, VPN

Tags: digital certificates HTTPS SSL TLS

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

July 15th, 2009

You’ve been lied to, or at the very least mislead. Most sources will tell you:

If you see the little lock icon in your browser
If you see “HTTPS” instead of “HTTP” in the URL
If you see the URL background change from white to yellow (depends on the browser)

Then your data is secured. By “secured”, most of us assume this means “The session is authenticated, encrypted and the authenticity of the server has been verified”. Unfortunately, this is not always the case. All the little lock icon tells you is that SSL and TLS is in use. Depending on where you actually see the little lock icon, even that much may not be true.

What is SSL and TLS?

Normally communications on the Internet take place in clear text. This means that anyone looking at your traffic can read it, and just as importantly, change it in transit. The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols are attempts to provide some level of protection for TCP based communications. When you see “HTTPS” in your URL, what that really means is you are running an HTTP session secured by either the SSL or TLS protocol.

We started off using SSLv1. Today we are up to SSLv3 and moving towards TLSv1. What’s the difference between SSL and TLS? For the most part, SSLv3 and TLSv1 are pretty much the same thing. The big difference is that Netscape created and owns the rights to SSL. TLS is an open specification. On the Internet we like to use open standards as often as possible.

Both specifications can be considered “sticky frameworks”. By that I mean the real job of SSL and TLS is to meld together a bunch of other specifications for the purpose of securing a datastream. For example neither defines specifically how to authenticate each packet, they simply point to HMAC-MD5 and HMAC-SHA and say “use that”. Neither specifically tells you how to encrypt the data, they just point to other specifications like RC4, DES and AES and say “use that”. This modular structure is pretty cool as it makes the specifications very flexible. It also ensures that these specifications will not easily be outdated. For example most of us know that DES uses far too small a key size to withstand a modern day brute force attack. No problem for SSL or TLS, just change to another encryption algorithm.

How SSL and TLS work

Both SSL and TLS are pretty lose frameworks. By that I mean that while some things are mandatory, a lot of what goes on in the communication session is optional. Let’s look at a typical session to see what we mean:

The client initiates communications with the server and starts the negotiation. The conversation goes something like this:

Client to server:

“Hi, I can fall back as far as using SSLv2 but would really prefer to use TLSv1. Here are the methods of securing the datastream I support …”

Server to client:

“No problem, I can support TLSv1. Out of the data protection methods you support, here’s the highest one we have in common…”

Server to client:

“Here’s a copy of my digital certificate.”

A couple of things to pull out of this exchange. The client identifies which security protocol it wants to use, but gives the server the option of falling back if required. This help with backwards compatibility, but its key to understanding why your session can end up being less secure than you thought it would be. The same thing happens with the methods or authentication and data privacy. The client identifies what it wants to use, but gives the server less secure options in case they are needed. Finally, the server sends the client a copy of its digital certificate for initial authentication purposes.

All of the above negotiations are required under the SSL and TLS protocol. What happens next however is optional. This is where our problems begin, and I’ll discuss that more in part 2 of this post.

No comments »

Posted in 3-err, VPN

Tags: HTTPS lock icon SSL TLS

chrisbrenton.org