共用方式為

Crypto Primer: How does SSL work?

  • 發行項

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.

image

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.

image

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 https://buyme.com you were in fact going to https://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:

image

  1. The digital certificate is retrieved
  2. The encrypted portion of the certificate is pulled out
  3. The CA’s public key is retrieved
  4. the encrypted data from step 2 and the key from step 3 are plugged in to the RSA algorithm and what comes out is…
  5. A plaintext version of the encrypted portion of the X.509 certificate.
  6. The plain text portion of the certificate is pulled out
  7. The plain text from the certificate is compared to the decrypted plain text (which originally came from the certificate). If they both match, then we can say the private key of the CA was definitely used to sign the certificate. We can therefore be assured that this certificate was issued to this site by this CA.

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 https://profile.mysite.com but you are connected to https://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:

  • Establish the legal identity as well as the operational and physical presence of website owner;
  • Establish that the applicant is the domain name owner or has exclusive control over the domain name; and
  • Confirm the identity and authority of the individuals acting for the website owner, and that documents pertaining to legal obligations are signed by an authorised officer.

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 https://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…

Planky

Technorati Tags: ssl,secure sockets layer,tls,transport layer security,certificates,x.509,public/private key,crypto,cryptography,encryption,decryption,ecommerce,plankytronixx,planky,session key,symmetric key,asymmetric key

Comments

  • Anonymous
    February 27, 2011
    Thanks for the clear explanation of SSL.

  • Anonymous
    February 27, 2011
    You're welcome!

  • Anonymous
    July 10, 2011
    Awesome explanation, thanks very much!

  • Anonymous
    February 12, 2012
    Thanks for the explanation.  Demystifying the problem from solution during explanation is interesting.

  • Anonymous
    December 18, 2012
    This was incredibly helpful - especially for a technical person who understands SSL but just needs a few of the gaps filled in.

  • Anonymous
    December 26, 2012
    thanks much. it was helpful. still trying to understand the client authentication which is likely reverse.

  • Anonymous
    December 16, 2013
    Thanks a ton. The article is framed in a nice way for beginer like me.

  • Anonymous
    April 22, 2015
    Very simple and straightforward article. Thanks a lot.

  • Anonymous
    April 22, 2015
    Very simple and straightforward article. Thanks a lot.

  • Anonymous
    April 22, 2015
    Thanks for the vote of confidence! It's always nice to know people find this stuff useful...