Continuing from my Crypto Primer post, I said I’d describe SSL. I’m going to stick with the simple option – the one that doesn’t involve client authentication. That’s because almost all of us use SSL without client authentication when we go to a page that asks us for a password, or in the payment pages. SSL creates an encrypted channel between the client computer and the web server.
I’m going to describe it backwards – it’s the easiest way to understand. But you’ll have to live with a little bit of “we’ll get to that in a moment” as you read it.
So, let’s use the example of sending your credit card details to an ecommerce web site. Remember this is the last step in the process – step 3. You simply encrypt the credit card details with a symmetric key that is known to you and the web site and nobody else.
The real question at this point is: how did you both get hold of a shared key in such a way that nobody else knows about it? In step 2 - as a client, you generate a symmetric key – known as the session key. You do it on the fly and it’s supposed to be a truly random number. You then pull down the public key of the ecommerce web server and use it to encrypt the session key which you send in ciphertext format to the web server. When the web server receives it, it uses its private key to decrypt the ciphertext and lo and behold – what comes out is a session key. That is the key you used in step 3 to encrypt your credit card details. I show step 2 in the next diagram.
There is still a question. How do you know that you pulled down the genuine web server’s public key? What if somebody somehow infected your DNS client so that although you thought you were going to http://buyme.com you were in fact going to http://bogusbuyme.com.
Well, in step 1 – their public key is wrapped up inside an X.509 certificate and this is what you pull down from their server, not just the raw public key. In the next diagram you can see you use the techniques we previously described in the digital signatures and certificates sections of my Crypto Primer to validate the X.509 certificate. The following diagram explains:
Sometimes you see a red background across the address bar of Internet Explorer (and other browsers) and an error message indicating the certificate is valid (conforms to X.509 standards, hasn’t yet expired etc) but that the certificate wasn’t issued to this site. You get the option of continuing anyway. This is a feature that compares the DNS name of the site you are connected to with the DNS name of the site in the certificate.
It’s telling you that although your communications with the site will be encrypted, the certificate was not issued to this site. You can sometimes spot an admin error here. The certificate is issued to say http://profile.mysite.com but you are connected to http://www.mysite.com. Is it safe to continue – I’d say exercise caution and don’t go there.
Back in the good old bad old days of the early Internet, the idea was that CAs performed extensive business checks on organisations that applied for certificates. So the idea was that if Microsoft applied for a certificate and then somebody else came along afterwards and applied for a certificate to be issued to Microsoft, the ruse would be spotted.
Over the years the thoroughness of these checks has diminished. But to get the industry to an even greater state of security – there are now, so called Extended Validation certificates (EV certificates). These put requirements on to all CAs that issue them. The main ones are that the CA must:
Also, anybody can apply for a standard SSL certificate. You could have a first name of “Un” and a second name of “Trustworthy”, running a site called http://do-not-trust-me.com and the CAs will still sell you an SSL certificate. All the certificate does is enable a client computer to have an encrypted conversation with a web server and proves that the CA issued the certificate. It doesn’t validate the honesty of the people who run the web site. Once they have your credit card information, it’s up to them what they do with it. SSL protects information in transit. Once disclosed, SSL won’t help.
So – there you have it. In reverse.
3. Use a session key to send the credit card details.
2. Use a public key to send the session key.
1. Do certificate validation to check the validity of the certificate that contains the public key.
That’s SSL in a nutshell…