Join Sean Colins for an in-depth discussion in this video Understanding SSL transactions, part of Learning Secure Sockets Layer.
- In this movie, we're going to talk about SSL transactions, from start to finish. We're going to give you the whole picture, and we're going to put it into context with what we're trying to protect against as well. So, let's get started. We start this process off with a handshake. It all starts with you or someone in a browser probably making a connection to a server, right? So, this is coming from a client. The client is going to send to that server the encryption types that it supports and a random number. The server will then send back its supported encryption types, including hash methods and encryption algorithms and the server certificate.
Now that certificate contains the server's domain name, which is called the common name, it's public key, the owner of the certificate or the subject, the issuer of the certificate, or the CA or certificate authority, the expiration date, the serial number. Next, the server encrypts that random number the client sent with its private key. The server then sends the encrypted number back to the client. The client then takes the encrypted version and decrypts it, and it takes the results of that transaction and the original number it sent and compares them.
If they're identical, then the challenge has been successful, and the identity has been confirmed. After it checks the identity, it has to check to see if the certificate is still valid. So, it checks the certificate's status by issuing an OCSP request. It also may check with a CRL database or a certificate revocation list database. If the certificate was revoked, then the client returns an error, but if it was clear, then communication continues. Once that happens, a unique session key pair is established, and then an encryption tunnel is established with that key.
From that point forward, all traffic is encrypted. So, how does that work in the context of the man in the middle attack? The idea behind the man in the middle attack is that when a client tries to communicate with a server, a hacker will get in the middle, and they'll try to intercept the communications between the client and the server, pretending to be the server all that time. If you're using SSL, then the server will return the certificate, as we just described, and if it does so, the hacker's just out of luck because the signature on an authentic certificate will be good, but the signature on an inauthentic certificate will not be correct.
When the client receives the response back from the server, if it's coming from the server itself, the response will be encoded with the true private key, which means the public key will decrypt it appropriately, and the signature will be authentic. If a hacker were trying to fake it, then the response that came back would not decrypt properly with the public key. For this reason, if SSL is being used and there are no valid attack vectors in use, the transactions will go back and forth in an encrypted tunnel that cannot be hacked, and your hacker will go on to someone else.
So, the man in the middle is based on this idea that the private key is unique and that if anyone tries to fake it, it just won't survive the challenge that's being presented by the client. So, this just points out that private keys must be kept secure. The big takeaway from this particular lesson is this, your private key is like gold. You must protect it. Keep it secure, because it is the one thing that if compromised, can ruin your entire SSL implementation.
This last slide on untrusted certificate messages just serves to point out some of the messages your users might see if they were to encounter broken SSL services that are attached to your servers or your network. The implied trust that we talked about in earlier movies means that users will always assume that things are working properly. When they see messages like this, those messages erode their trust in your services.
It is mission critical that you get your SSL implementation working properly, so your users never see messages like this.
- SSL communications
- Certificate authorities
- Public key infrastructures
- Symmetric and asymmetric key pairs
- Cryptographic hash functions
- Encryption algorithms
Start now, and by the end of this course you'll have the knowledge to create SSL certificates, as well as revoke and renew them, from the command line.