How do secure websites work? Part 2 of 2

Ok, in Part 1 I identified the basic components involved in the SSL process, I will now walk you through how they all come together to protect your private information while on the web.

Any secure website owner should have a SSL generated by a reputable Certificate Authority, and this SSL certificate will have been placed onto the web server you are now attempting to establish a secure session with. This SSL certificate provides several functions, when you request a connection to a secure site (one that starts with https:\\) the server sends a digital certificate to your browser to identify itself. This involves the following functions:

1. The SSL contains the identity of the Certificate Authority that issued the certificate. The first thing your browser does is check to see if your computer trusts this CA. If it does not a warning is displayed. You may choose to ignore the error (most do because they do not understand the error), you can choose to add the CA to your trusted CA list, or you can cancel the connection and not proceed with your transaction. (One example of how to add a CA to IE 7 can be found here )
2. The SSL certificate contains information regarding the domain name it is registered to. (www.yourbank.com for example) If the domain name does not match the site you just connected to another error will be displayed. Again, most people ignore these because they do not understand what is causing the alarm. This is the root cause of a failure in the SSL process to protect your information. Simple lack of understanding.
3. Lastly, the server sends a copy of its Public Key. Remember the Asynchronous Encryption information in part 1? With asynchronous or Public-Key encryption, two keys are generated. One, the Private key, must be protected and kept secure from any form of distribution. This key remains on the server and is the most important component of providing security in SSL communications. Two, the public key is distributed to anyone and any data encrypted with this key can ONLY be decrypted by the matching private key of this key pair. This confuses many people so I will explain in more detail how this protects you in a moment. So, if you were connecting to a secure website, you are now at a point where your browser is prepared to establish a secure transmission. At this point no data has been sent between the server and you. You have only prepared the two systems to communicate. What happens next is the part I think is so cool in how it actually works to protect you.

So, you now have a public key, you know the server is THE server you wish to communicate with and you are ready to send data.
As I said, with public key encryption, any data encrypted with the public key (the key sent to your PC), may only be decrypted by the private key(The key that is protected and never leaves the server), but this process is not used to send your private information. It is slow and, while difficult, could be compromised because the keys do not change and patterns could be used by a determined hacker to compromise the key pair.

Instead, the client computer (your PC) generates a random number or a “session key” (synchronous encryption) and then it encrypts this “session key” with the public key that was received from the server. Now because ONLY the private key can decrypt this message, once the server receives this session key and decrypts it with the private key, only the server and the client have a copy of this one time, unique encryption key. This will be the encryption key used to transmit data back and forth between the server and the client. This session key is only used for the current connection between the server and the client and once that link is broken, the key is destroyed. The session key is fast, uses a low amount of computer resources, and because it was exchanged in a secure manner using public key encryption it is virtually impossible for anyone to “hijack” this session and compromise your data. (A hacker would need the “Private key” to compromise this communication which is why the private key must NEVER be compromised. Administrators of these secure web servers go to great pains to make sure this is the case. If a private key is suspected to be compromised then the owner must go back to the CA and obtain a new SSL certificate.)

Congratulations, you session between you and the secured website is now secure and all data transmitted between your browser and the server is now encrypted. This entire process is usually summarized and called the “SSL handshake”.

Once you have completed your connection to the secure site. The communication process is “torn down” the session keys are destroyed by the server and the client. If you go back to this secure site again, the whole process happens all over again with new session keys created for that particular session. The SSL handshake happens much quicker than it sounds and should be completely invisible to you the consumer. If it is not then you see those error messages that were mentioned above. So read those error messages and if you are in doubt contact the owner of the site to determine what is causing the errors. Sometimes the errors or innocuous and can be safely ignored but you should understand the error and be comfortable in ignoring it. Not just ignoring the error because you do not understand or because “I get these all the time, probably isn’t important.”

I hope this helps you understand the SSL process and makes you feel more comfortable with your online experience. It is complicated but I I have tried to simplify the process and make it somewhat easier to understand.

Good luck to you and feel free to post comments or follow up questions. I will try to respond in a timely manner.


Steve