How an SSL Connection is established?

Lets say we want to access the following site via SSL: https://www.oracle.com

• The browser and web server establish the SSL protocol version, Ciphersuite, and a Session ID. The Protocol and Ciphersuite negotiated depends on the version of the browser and the web server used. SSL Protocol versions are SSLV2, SSLV3 and TLSV1, with SSLV3 being the most common. The SSL Ciphersuite outlines the following:
  • The Key Exchange Algorithm - how the client and server exchange symmetric keys, i,e RSA or Diffie-Hellmann)
  • The Symmetric Encryption Algorithm e.g. RC4 128bit or DES 56bit
  • The Message Digest function i.e. MD5 (128bit), or SHA-1 (160bit)
  • For the purposes of this explanation the negotiated Ciphersuite is RSA-RC4128-MD5
• The server sends the certificate to the browser
• The browser takes the certificate, and checks via the trusted CA certificate that the certificate is valid. Remember that the certificate contains the validity date, DN of the Issuer CA, the webserver's public key and the CA’s digital signature (i.e a hash of all the data in the certificate, encrypted with the CA’s private key).
• Firstly the client checks that the certificate is valid as per today's date and the certificates validity period. In this case the validty dates are Valid From:16 June 2003 00:00:00, Valid To: 15 June 2005 23:59:59. At the time of writing the date is 23rd February 2004 , hence the certificate is valid.
• It then checks that the Issuer DN matches the DN on the clients list of trusted CA’s certificates. These are stored in the browsers trusted certificate list. If it matches one of the trusted CA’s certificates then we have proved that the issuing CA is trusted. In this case the certificate for www.oracle.com was issued by "OU = Secure Server Certification Authority ,O = RSA Data Security, Inc., C = US". As this is a common certificate provider it ships with most browsers by default.
• Next the digital signature is decrypted using the CA’s public key, which it has as it is contained within the CA's certificate stored in the browser. Then the original certificate is put through the hash to produce a digest. If the two digests match we know that the certificate was issued by the trusted CA and has not been tampered with.
• Next, the Subjects Common Name (CN) from the Subjects DN, is checked against the hostname of the server where the certificate came from, to prove it came from the server. In this case we made a connect to http://www.oracle.com , so the browser checks the Subjects CN matches. As the certificate has "CN = www.oracle.com" then this test is passed
• If everything checks out, the browser can now trust that it has the servers public key. In this example all the tests succeed. If however it doesn’t check out then the user is informed of the problem via a warning message. Lets say for example that the Certificate had expired, in this scenario the warning message would be displayed: "The security certificate is expired or not yet valid"
• Now the browser has the webservers public key, the browser requests that the server proves it’s identity again by sending a randomly piece of generated data for it to digitally sign.
• The server produces a digest of the data using the hash, encrypts it with its private key, and sends the digital signature.
• The browser receives the digital signature and decrypts it using the servers public key to produce a digest, and then puts the original random data though the hash algorithm to produce another digest.
• If the two digests match then the server has proven it’s identity.
• The browser and server then exchange symmetric encryption keys using the Key Exchange Algorithm (KEA) defined in the negotiated ciphersuite. In our example the negotiated KEA was RSA .
• At this point the SSL Handshake is complete and these symmetric keys are then used to encrypt and decrypt data over the session using the encryption algorithm negotiated at the beginning of the session i.e RC4128
• Any data transmitted is also put through the negotiated hash algorithm (MD5) to prevent tampering

More on Certificates

Server Certificates can be obtained from many online vendors, or software can be bought or downloaded that allows you to generate you own certificates e.g: OpenSSL. As there are many different vendors it is impossible to go through what everyone calls their server certificates, so we will outline the ones issued by two of the main Interent vendors: Verisign and Thawte.

Server Certificates

There are 2 major types of server certificates, and their marketing name varies depending on the Certificate Authority issuing the certificate.

1. Global Server ID's (GSID) (issued by Verisign)
   Global Server Certificates, sometimes known as Server Gated Cryptography or 128bit certificates, are certificates that enable all browsers to use 128bit symmetric encryption, even if the browser is an Export browser where only 40bit symmetric encryption is allowed. A GSID usually has two parts, the certificate itself, and an extra intermediate certificate, which is used to provide the step-up. This is useful because of past export regulations where only Export browsers could be used outside the US. Now export regulations are relaxed new browsers can use 128bit encryption world-wide. As outlined earlier the names of these certificates vary. Thawte for example, calls these certificates 128bit SuperCerts. These types of certificates should not be necessary at this point in time as all the latest browsers support 128bit symmetric encryption.
2. Secure Server Certificates (issued by Verisign)
   These are sometimes called 40bit certificates. However, they will allow 128bit bulk encryption or higher if both the web server and client browser support 128 bit symmetric encryption or higher. This sounds illogical but it is down to the ciphersuites used for generating the symmetric key. Thawte calls these certificates SSL Certificates. In reality there is no such thing as a 40bit or 128bit certificate. They both support the same levels of encryption, it’s just that GSID’s will allow old export type browsers to use SSL Symmetric Encryption at 128bit. The certificates can be said to have a key size, but it refers to the length of the public key contained in the certificate (I.e 512/1024/2048 bits). The names of the Certificates were chosen purely for marketing reasons.
3. Client Certificates
   In most Internet applications the server sends a certificate to the client for the purposes of server authentication. In SSL it is also possible for a server to ask a client to authenticate itself to provide extra security. This is not common practice in most Internet applications, but is common in web based Intranet applications. In this scenario, both the client and server both have a certificate, and the server will perform the authentication against the client as well. If client authentication is desired, then a client certificate needs to be issued for your browser/application. These are available via Internet vendors like. Verisign or Thawte, and also using commercially avalaible software like Oracle Certificate Authority, Netscape Certificate Server, RSA Keon Server. If a browser is used, then the private key for the corresponding client certificate is stored within a browser database usually protected with a password. If using somebody like Versign or Thawte for the client certificates, then all the private key generation is performed by a combination of the browser and the Web site. During generation you will be asked for a PIN which you will need to enter when you make a SSL connection if the server requires client authentication. Client certificates are sometimes referred to as Personal Certificates. Client certificates contain the same information as a server certificate, however they do not have a User Common Name (CN). Instead, they tend to have this attribute set to your full name or email address. When a server authenticates the client, it therefore does not do validation against a hostname.