Practical Secured Socket Layer (SSL) – Basic & Practical
Silan Liu, Feb. 2004.
This article views Secured Socket Layer (SSL) from two view points: fundermental principles and practical applications. For more technical details, see Netscape article “Introduction to SSL”.
The secrets in the “unbreakable” SSL channels lies in the use of cryptographic public/private key pairs.
When you have a public/private key pair, you are free to give out your public key to anyone, but must keep your private key secret to only yourself. Public and private keys are used in two cases:
You sign a piece of data with your private key. You send out this signed data with your public key. Anyone can validate with the public key that this piece of data had been signed by the matching private key. The public key is usually contained in a certificate signed by a well-known certificate authority (CA), which proves that this public key does belong to the person.
The data to be signed may be something useful that you don’t want to be tempered, or just some random data. The signed random data is called digital signature and used to prove that it comes from the one who owns the public key.
You can publish your public key at a online center or give out to anyone you like in other ways. When they want to send you some secret data, they can encrypt it with your public key. Only you can decrypt it with your private key.
A server certificate is a piece of data issued by a CA such as VeriSign to a particular organization, indicating the organization’s name, location, business type and IP address (called Common Name). For example, when my IE 6.0 browser connects to my bank “https://olb.westpac.com.au/”, a padlock is shown at the bottom of the browser. When I double-click it, a certificate dialog is shown. In “Details” tab page, the “Subject” item will show following details:
CN = olb.westpac.com.au
OU = INTERNET ONLINE BANKING
O = Westpac Banking Corporation
L = Sydney
S = New South Wales
C = AU
This certificate was presented by the Westpec server to my browser at the beginning of the SSL Handshake. My browser checks this certificate to make sure that
1. The certificate has not expired. If yes, server authentication fails.
2. The certificate has been signed by an accepted CA – client browser has installed a list of trusted CAs as the “trusted root CAs” during the browser’s installation. The server certificate has to be signed by one of these CAs and the signature has to be verifiable by the corresponding public key available from the pre-installed CA list. If the certificate is issued by a CA not registered in the client browser, the browser will prompt user a message saying “the certificate was not issued by a company that you trust”, and ask for user’s decision. If user chooses to proceed, a secure channel can still be setup. If the certificate has been tempered, authentication fails.
3. The actual domain name is the same as the one on the certificate. If not, authentication fails.
Because the browser does not parse the web page, it can not check whether the company name shown on the web page is the same as that on the certificate. User has to do this checking by double-clicking the padlock and reading the certificate. If he doesn’t, theoretically there is a chance that a butcher’s company acquires a server certificate then claim on their web page to be IBM and start to sell computers (must be greasy ones).
If all the checking is done, client can be sure that he is dealing with the web site of the company of his choosing.
The other use of server certificate is for data encryption. When a server certificate is issued by a CA, it contains a public/private key pair. When this certificate is installed on the server (see Installing a Server Certificate), the private key is stored on the server. When the certificate is presented to the client during SSL handshake, it only contains the public key. The client browser encrypts the premaster secret it generates with this public key, and sends it back to the server. Then both client and server can use this premaster secret to generate the master secret and then session key to encrypt data.
Server certificate is also known as server ID.
A SSL handshake is performed to setup a secured channel. The main process is:
1. Server presents client a server certificate and client authenticates server;
2. Client generates premaster secret and encrypt it with the server’s public key (contained in the server certificate), and send it to server.
3. Server decrypts the encrypted premaster secret.
4. Client and server both generates a master secret from the premaster secret, and then generate session keys from the master secret. The session keys are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity.
After this handshake, the server and client can communicate using encrypted messages that can only be decrypted by each other.
From the two previous sections (Server Certificate and SSL Handshake), you can see that all that are needed for a secure channel to be setup between the client and the server is that the server has installed a server certificate issued and signed by a CA trusted by the client browser. Therefore, if you are building a new web site that needs to use secure channel, all you need to do is to get a server certificate from a publicly trusted CA and install it on your server. If the CA is famous enough like VeriSign, client browser would have already has it registered.
Most CAs provide free trial certificates/IDs for research purpose. These certificates are not signed by the CA that is among the trusted root CAs installed in the browsers. The CAs that offers them provides separate root CA files for the trial certificates. If you want to prevent the browser from prompting warnings, you should install the test CA file. To do it in IE 6.0, go to “Tools | Internet Options | Content tab page | Certificates button | “Trusted Root Certificate Authorities” tab page | Import”. Browse to the test root CA file.
To apply for a server certificate/ID, you must first generate a CSR, which is basically encrypted data about the information of your company (name, address, telephone, etc.) and the common name of your web site. For example, if the URL of your web site is http://www.mywebsite.com.au/, then the common name should be www.mywebsite.com.au. If the server is on Intranet and the computer name is fliu2000, then the common name should be fliu2000. Note that if you want to secure URL http://www.mywebsite.com.au/payment where, the common name should still be www.mywebsite.com.au.
To generate CSR in Microsoft IIS 5.0: right-click ”Default Web Sites” in IIS | “Properties” menu | “Directory Security” tab page | “Secure Communications” group | “Server Certificate...” button. Then follow the instructions.
Then contact a CA, provide them with the file containing the CSR, plus IDs of your company, then you will finally get a piece of encrypted data as the server certificate. Save it in a .cer file.
To install the server certificate in Microsoft IIS 5.0, follow the same steps as generating the CSR. Choose to process the pending request, and select the .cer file which contains the server certificate.
To secure a particular URL or virtual directory in Microsoft IIS 5.0: IIS | “Default Web Sites” | right-click the virtual directory that needs to use SSL | “Properties” menu | “Directory Security” tab page | “Secure Communications” group | “Edit” button | tick “Request secure channel (SSL)” tick box.
For each server certificate, there is a machine key file in the following directory
“C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys”
The date and time of the file is the same as when you install the certificate. This file must give “Administrators” group Read/Write/Execute privilege. If the certificate installation fails with an error “Keyset not exist”, or the SSL just doesn’t work, make sure that this machine key file is accessible to the “Administrators” group, then remove the certificate and assign it again.
A client using SSL could be a web browser or a web service proxy. As a browser client, just make sure the URL address of the server starts with “https://“ instead of “http://“. As a web service client, just make sure that when the proxy class is generated, say using wsdl.exe, the used URL starts with “https://“. Otherwise wsdl.exe can not find the WSDL of the web service and the generation will fail. Apart from these concerns there is no other things that a client has to do to use SSL.
A client certificate is used for two purposes:
1. Prove the identity of the client (more precisely, identity of his/her browser) to servers that accepts client certificates. Client no longer needs user name and password to log on to the server.
2. Sign or encrypt user’s email. For most email applications such as Outlook or Eudora, signing or encrypting one single email or all emails are just a matter of one button click or one security setting. If user A wants to send an encrypted email to user B, A should acquire B’s public key (most email applications has the facility to store recipient’s digital IDs), and encrypt email with it. Then when the email reaches B, he can decrypt it with his private key.
The principle and authentication process of a client certificate is almost the same as a server certificate. The differences are:
1. Client browser sends the client certificate to server, while the server sends the server certificate to client browser;
2. A server is stationed – it resides on a fixed IP address, which is stated in the server certificate. Therefore, if someone steals the server certificate of IBM and installs it on his own server, client browser finds out that the lunching IP address of the server is different from that on the certificate.
In comparison, a client is mobile. The email address signature of the client email is also easily forgeable. Because of this, the client authentication process has one step which is different from the server authentication: the client browser is required to sign a piece of randomly generated data and send it along with the client certificate. Server is then able to verify using the public key contained in the client certificate that this piece of data was signed by the matching private key. Because of the assumption that only the real client has this private key, server can be sure that the connection was from the real client.
You go through similar process to apply for a client certificate from a CA. Again trial certificates are usually provided for free. To install it, go to “Tools | Internet Options | Content tab page | Certificates button | “Personal” tab page | Import”. Browse to the certificate file.
IIS | “Default Web Sites” | right-click the virtual directory that needs to use SSL | “Properties” menu | “Directory Security” tab page | “Secure Communications” group | “Edit” button | “Client Certificates” group | select the corresponding button.
A client browser that has client certificate installed knows to send the certificate to server. But a proxy doesn’t know the certificate. Therefore, you have to export the certificate to a file, then assign it to the proxy. To export the certificate into a file in IE 6.0: Tools | Internet Options | Content | Certificates | Personal tab page | select the certificate that you want to export | click “Export...” button.
To assign it to the proxy:
Client.localhost.Service1 s = new Client. localhost.Service1();
X509Certificate cert = X509Certificate.CreateFromCertFile("c:/TrialId.cer");
By acquiring the details of the client certificate, server can find out the identity of the user.
public string Hello()
The output should be something like:
E = firstname.lastname@example.org
CN = Silan (Frank) Liu
OU = Digital ID Class 1 – Microsoft
OU = Persona Not Validated
OU = www.verisign.com/repository/RPA Incorp. by Ref.,LIAB.LTD98
OU = VeriSign Trust Network
O = VeriSign, Inc.
If we want to acquire the email address or the user name, for example, we should parse this string.
We could map client certificates to Windows accounts, so that we do not need to acquire the certificate details and parse them. To setup server to map client certificates: go to IIS | “Default Web Sites” | right-click the virtual directory that needs to use SSL | “Properties” menu | “Directory Security” tab page | “Secure Communications” group | “Edit” button | tick “Enable client certificate mapping” tick box | “Edit” button.
There are two ways of mapping. One-to-one mapping maps one client certificate file to one user account. Obviously you should have the client certificate file (.cer) at hand. IIS does not check whether the user account actually exists or the password is correct. Many-to-one mapping maps any client certificate whose certain fields contains certain substring. For example, we can decide that any client certificate whose “Subject” field | “O” sub field begins with “Sealand Consulting” (by using a criteria “Sealand Consulting*”) maps to user account “fliu2000/Administrator”.
With the genius invention of the cryptographic public/private key algorithm, with the involvement of a trustworthy third party such as VeriSign, secured connection and identity verification are made possible across the Internet, which is the most important corner stone of today’s booming e-commerce industry.