[Back|
Home|
Programs|
Documentation|
Internet|
People]
SSL
What is SSL?
So now that you have all this new information about encryption, certificates, certifying authorities, and authenticating certificates how are all these things actually used? SSL, or secure sockets layer, is the process that uses all of these technologies to create secure web sites. When ever you enter a page that begins with "https://" rather than "http://" you are entering a secure page that is encrypted using SSL. SSL is protocol that will sets up an layer of encryption between the server, where the HTML pages are stored, and the client, you and I. Again, it is SSL secured sites that can encrypt information such as credit card numbers transactions and grades. Without SSL studentlink could not be encrypted and someone could intercept the page and press the button to drop a your class on finals week.
SSL uses all the existing technologies and combines them to create a seamless interface so that clients can't tell the difference from a normal page or an SSL page other than typing "https." Https stands for HTTP + SSL. (Http is the stand Internet protocol for transporting web pages from the server where the web page resides to the client who requested the page.) SSL uses both types of encryption, public and private key. This is so the benefits of each can be taken advantage of without running into disadvantages of either. SSL does require web sites to have a certificate so that the site can identify itself to the client. SSL doesn't require, but allows for, client certificates so that you and I can identify ourselves to the site, this step is just another level of security.
Getting SSL to work is all done on the server side. This means that the average user does nothing more than typing "https" and use an SSL enabled browser. All modern Internet browsers are capable of SSL (IE 3.0 and above and Netscape Navigator 3.0 and above). The web serverís administrator must first get and install a certificate for the server. This certificate is not for a person, but a web site. Thus the owner of the certificate would be the web site. However, the CA will verify the identity of the individual requesting the certificate in the usual manner. This process is also another level of protection for the consumer, we can be sure that the certificate was issued for this site was intended for this site. The administrator generally gets a certificate from a commercial, trusted CA so that any user can connect without receiving and error message (one of the trusted CAís in an Internet browser, remember all SSL enabled browsers come with a list of trusted CA's). Once the certificate is installed the system administrator has to turn SSL on. How he actually turns SSL is of no concern to the user, but not a difficult task. At this point, the web server is running and someone can connect to the secure page stored on the SSL enabled server. The only other option that the administrator can set is to require client certificates. A bank or corporation would use this option so that the bank can be sure of the user's identity, however Internet stores would not want to use this option as most individuals do not have a certificate.
SSL begins during the handshake process and lasts until you leave the site. As soon as you type "https" and connect to the server the handshake takes place. If the handshake is fails you can't connect to the page. Once the handshake succeeds information begins to be sent across the net. The fact that SSL take place before any information is sent over the web means all information that you see has been encrypted. You are probably asking, "what is this handshake and why don't I notice it when I connect to a page like studentlink?" The answer is that the handshake is completely invisible to the user as long as it succeeds.
The SSL handshake
The handshake process is as follows:
(One note, in SSL private key cryptology is what will be used to encrypt the data that you see, but the public key cryptography is used to encrypt the private key when it is sent across the network.)
1) The client, you and I, connect to the HTTPS page.
2) The server asserts its identity by returning its server certificate and a random string. The random string is just a string of random numbers and letters which will be used later.
3) The client authenticates the servers identity by making sure a trusted CA issued the server certificate and that the digital signature on the certificate is valid. This is just the procedure described here. One other step is performed, the name of the web site must match the name on the web siteís certificate or an error message will be displayed to the client. This extra step allows the client to be sure that the server is using a certificate that was intended for this site.
4) Once the client has verified the server's identity, the client will generate a master session Key. This key is a "private key cryptography" key and will be used to encrypt the data during the SSL session. For security reason it is the client who decides the algorithm and key that will be used. In SSL the client and server have a list of different algorithms that can be used as the private key encryption algorithm. Together they try to negotiate the strongest algorithm (the one hardest to break). The master key is the server key and the client key. The server write key is the client read key and the server read key is the client write key as they have to reverse each others operations.
5) The client will encrypt the server private key with the server's public key contained in the server's certificate. Here public key cryptology is being used to send the private key over the Internet. This is done so no one can intercept the key that will used later. Symmetric cryptography is used to encrypt the rest of the transactions because it is faster, but private key cryptography is used to send this key over because no prior communication is needed. This method uses the benefits of both types of encryption while avoiding the disadvantages of both.
6) Finally the server will return the random string that it originally sent, but this time it encrypts the string with its private key creating a digital signature. The client will then use the public key of the server to decrypt the random string. If the original string and this string match the server is authenticated.
7) If the web site is configured to handle client certificates the server now requests the client certificate.
8) In addition to the client certificate the client also sends a hashed version of server random string.
9) The server now attempts to authenticate the clients identity by following the same steps the client used in step 3). The server then rehashes the original string that it sent, and if this hash matches the hash that the client sent back and the certificate will be found to be valid, and the client is authenticated.
10) If every step finishes successfully the handshake is complete. The data (web page) that the client requested is sent across the net encrypted with the server write key. The data is then decrypted with the client read key and displayed on the screen.
SSL and security
This entire handshake process is transparent to the user, unless the server needs a client certificate or the process fails. This entire handshake seems lengthy on paper, but completes in a couple of seconds. One of the two cases that would make the user aware of the handshake is if he is required to send a certificate. At this time a message will pop up asking the user to send his/her certificate. The clientís certificate will be stored in the browser and the client will only have enter a password to unlock and send the certificate to the server. The only other time that the user would be aware of this process is if it fails and an error message comes up saying the connection could not be made because either the server couldn't authenticate the user or you could not authenticate the server. The client can choose to proceed with the handshake and ignore the error messages. This is not recommended, especially if you will be sending credit card information. When you connect to a site like studentlink you don't notice anything since studentlink doesn't require certificates and the certificate that studentlink uses was purchased from a commercial trusted CA.
The user may also notice a message when he/she types "https" which will say something to the affect that, "You are entering a secure site, do you wish to continue?" This is a normal message and is there just to remind you that you are entering a secure site. There is also an icon of a lock on most browser which will lock when ever SSL is being used and this icon will be unlocked when SSL is not being used.
How long does SSL last and what if I go to a new page that is secure but on the same server? The handshake happens only one, when you first enter the secure site. Any other secure page on that server will also use the same symmetric key that was negotiated during the original handshake. On a site like studentlink once you enter the site, the same key is used for the remainder of your stay there. Once you leave, however, the SSL session ends and you will have to go through the whole process again if you wish to enter again.
SSL is uses all the benefits of public and private key encryption and uses certificates to establish identity. Therefore when you are in a SSL enabled site, just look for the https and the locked icon, and you can be sure that any information traveling between you and the server is. If you are still unsure about the site most browser allow the use the option to view the certificate that the server is using to establish its identity. Here you can view the CA's name, the digital signature, and the name of the site that the certificate was issued to. During the authentication process and the handshake, your browser checks all of these fields.
The next advance in Internet security is PKI which builds on some of the SSL functions. The PKI page will describe the different types of PKIís, a corporate PKI and PGP. The difference between the two is who uses them.
To go back to main page click here or to proceed to the page describing PKI, click here
Send your comments and sugestions to
rrwallac@ucsd.edu
Contact information
URL: http://sdcc10.ucsd.edu/~rrwallac
e-mail: rrwallac@ucsd.edu
[Back|
Home| Programs|
Documentation| Internet|
People]