Introduction to SSL

SSL Handshake:
Website
Browser
<----- Request

The browser asks for an SSL protected page

Response ----->

The server responds with an x509 certificate (signed public key) and a set of intermidiate certificates needed for confirmation of the site identity

<----- Request

The browser validates the websites's certificate and sends a random key encrypted with it.

Both website and browser now have a shared random key to use for symetric encryption.

Secure socket layer, a secure internet connection widely used by many internet protocol, aspecially web traffic. While an application, such as a browser, can treat an SSL connection like any other connection, sophisticated algorithems are used to validate the identity of the servers and encrypt the transmissions.

SSL combines both symetric and asymetric encryption. Symetric encryption is achinved using a pre-shared key between the website and the browser. Asymetric encryption is achinved by using a pair of matchines keys, known as the "private key", or "server key" and the "Public key", or "Certificate". While asymetric encryptions removes the burden of exchanging keys, it is consuming a great amount of CPU resources. In a "best of both worls" approach, SSL will use an asymetric key pair during the connection phase, known as the "SSL handshake", during which the website and browser will exchange a uniqle generated key used to symetrically encrypt the rest of the connection.

The SSL handshake is a process in which an SSL connection is established. To do so, the server must offer a valid certificate confirmining the identity of the website and both client and server need to find compatible cipher suites and compression methods.

The certificates used in SSL, also reffered as "Public key", "x509 certificates" or just "certs", have many properties associated with them except their use as public key. Each certificate has a subject which it "certifies", such as a domain, or a signing service provided by an authority, And an issuer, a name of a certificate that "signed" this certificate. So, when a number of certificates sign each other in order, a "certificate chain" is formulated.

Certificate chain:
First certificate in chain - my website's certificate
Certificate subject: www.mywebsite.com
Issuer: Some CA, product of class X
Signed by:
Second certificate in chain - intermidiate certificate
Certificate subject: Some CA, product of class X
Issuer: Some CA root
Signed by:
Third certificate in chain - Root certificate of a CA, self-signed
Certificate subject: Some CA root
Issuer: Some CA root

Every browser or operation system has a package of bundeled certificates, root and common intermidiate certificates of trusted certificate authorities. If a website public key, or an intermidiate key that signed the websites key, is signed by a certificate that is available in the browser bundle, the chain of certificates is considered authentic, and thus the identity of the web site is confirmed.

Certificate authorities, CA, for short, are organizations that has their root certificates bundled with major browser products and thus all the certificates signed by their root certificates are considered as valid. Those companies in turn validate the buisnes, identity, and other details of the of companies for which they sign certificates.

It is a common practice for a CA organization to have a number of encryption services, with different levels of buisness validation and insurence levels. In this case intermidiate certificates will be used. The CA will use it's root certificate to sign a number of intermidiate certificates for various CA products, and companies entitled to those services will have their certificates signed with the relevant intermidiate certificate.