Spent some time reading up on SSL and how it defends against against the ‘man-in-the-middle‘ attack. All the pieces to the puzzle were there in my previous post – I just needed a good reference on the protocol. The best references I found were:
- Introduction to SSL
- An Overview of SSL (version 2) (Thanks Craig)
- Special mention: Mentalis’s Secure Socket Library – free and open source implementation of the Secure Socket Layer (SSL) protocol version 3 and the Transport Layer Security (TLS) in C#!
Examining the protocol reveals how SSL defends against a man-in-the-middle attack.
|
|
|
| ClientHello: SSL version number, cipher settings, randomly generated data | ||
| ServerHello: SSL version number, cipher settings, randomly generated data, server certificate. The server certificate contains the server’s public key. | ||
| ClientKeyExchange: premaster secret for the session – derived from a hash of all the communcations to this point. This is sent encrypted with the server’s public key. The server decrypts this, and ensures the hash matches its own hash of the communcations. | ||
| The client and server both create a session key to be used for the remainder of the session. The session key is derived from the premaster secret, client random data, and server random data. | ||
| ChangeCipherSpec: Finshed | ||
| HTTP GET (communcations now encrypted with the established session key) | ||
The server certifcate delivered in the ServerHello is signed by a trusted certifcate authority (CA). The client tests this signature against its own list of CA public keys. The server certifcate also contains the domain name of the server. This is used to confirm you have the certicate that has been authorised by an authority for the website located at amazon.com. If the certificate does not pass either criteria your browser will give you a warning.
If an attacker did sit in between your browser and a server and they passed along the certificate in the ServerHello – they wouldn’t be able to decrypt the ClientKeyExchange. As this has been encrypted with the server’s public key – and the attacker is only in posession of the public key. It is possible for the attacker to substitue their own certificate in this step. But the browser will issue a warning if the certificate isn’t:
- signed by a trusted authority,
- and certificate’s domain matches the site the client is connecting to.
As you may have already guessed: To have your server certificate signed by a trusted CA’s (like Verign, Thawte and Comodo) you have to provide evidence you own the domain! The other weakness is the list of trusted authorities you have installed in your browser. As mention by Steve Gibson in the Security Now podcast (episode 36) some corporate environments have inserted their own CA certificate in the client installations exactly so they can perform a man-in-the-attack to filter content at the proxy.
Now, there is an exception, though, which is the other reason I put this question in here today, because when you connect to a remote server you are accepting the credentials of the server, which has been signed by someone who signed their certificate, like we were talking about briefly before, about VeriSign, for example, signing GRC’s certificate. Some corporations do want to proxy and filter and literally basically decrypt and be able to read their employees’ encrypted traffic. So what they do is they run a proxy server in their corporate environment, which has a certificate. And every browser in the company has been told to trust that certificate. So essentially the encrypted traffic is decrypted at the corporate border.
It’s decrypted at the corporate border and then, essentially, filtered, proxied, checked for spyware, or even for naughty content. I mean, they could do anything they want to once they’ve got your connection decrypted. Then it is reencrypted using a certificate that every corporate browser has been deliberately installed with in order for the browser not to complain. So employees may believe they have encrypted and secure SSL connections, when in fact it is being decrypted in, you know, en route, essentially, you know, by their corporate firewall or IT staff or proxy server for whatever corporate reasons.
Which finally does explain how SSL defends against this attack!
Post a Comment