What is SSL?
SSL is a protocol, not a HTTP extension, not a digital certificate nor an encryption method. As it finds itself at the TCP layer it can be employed for other application protocols than HTTP (i.e FTP, SMTP, etc). SSL is the predecessor of Transport Layer Security (TSL) and although they do the same thing – until a certain point – the former definition is much popular among the developers. TSL has a few enhancements compared to SSL when it comes to client’s and server’s ability to specify which hash algorithms to use, sha-256 for pseudo random function, etc.
SSL protocol enforces 3 aspects of client-server communication:
- authentication – both one-way (server authenticates to client) and two-way (client authenticates to server as well)
- privacy – which is message encryption
- message integrity – by using MACs to make sure the message content hasn’t changed during transmission
The certificates are at the base of SSL protocol as they encapsulate the vital information needed for this protocol to work. The most important information in a certificate are: the certificate issuer, the identified entity, validity dates, the public key and the algorithms used to create the signature and public key.
Simply put the main roles of a certificate are to guarantee that the entity presenting it, is the entity claiming to be (that is a valid CA signing the certificate) and to generate the “master secret” needed for the symmetric data encryption.
CA comes from Certificate Authority which is an entity that issues digital certificates. Every browser out there has a predefined list of CAs that come along. Everytime a SSL session is initiated with a server, the root CA of the certificate is verified against the local list of CAs. Whenever an issuer is not on that list, the browsers pops up a security warning, usually in a dedicated page.
This the most common deployment form of certificates today and it employs an one-way authentication mechanism. This assures the client that the server is who pretends to be by providing it a digital certificate. The client checks the CA that signed the digital certificate against the local CAs list. The detailed procedure used to establish the SSL session is detailed below in Handshake section.
The diagram below (taken from HP site) depicts the server certificate check.
With this approach the client is not authenticated to server, so the server has no guarantee that the client is who pretends to be from the SSL protocol perspective. Application level authentication is out of the question here.
Server certificates are heavily used by social networks, public webmails, intranet portals and so on.
Client certificates leverage the full power of SSL protocol by employing the two-way authentication model. Here, not only the server is authenticated to client but the client, at his turn, is authenticated to server. This way both parties are trusted and the identification problem is solved.
This model requires a certificate to be installed on the client machine (his/her browser most likely). The client certificate is signed with the private key of the issuing server. The client certificate contains both a private and a public key and, exactly like with the server certificates, the public key is sent along with the certificate to the server requesting it. An important thing to note here is that the client certificate is used during the handshake process only, when establishing the SSL session parameters.
Given the fact that each client must install a client certificate to access a server or a service, this model is not easy to scale and that is why it is less popular nowadays. It is especially used by banking institutions where knowing the identity of both parties is a must.
The diagram below (also from HP site) shows the two-way auth process with client and server certificates.
With client certificates you can easily achieve a two-factor authentication by combining something you have (a digital certificate) with something you know (a password). This could be a good option for the random code generator devices that most of the banking systems uses today.
One downside of client certificates could be in the fact that they are no easily portable. That is once you installed a certificate on a browser, you cannot use it from another work station unless you install it there too.
The handshake is that process in which the client and server agree on various parameters to establish the secure SSL session. A detailed description of each step involved in handshaking process can be found in the corresponding wiki article.
The authentication part of the handshake process is encrypted with asymmetric algorithms, while the rest of the SSL session communication is encrypted with symmetric algorithms which are by far much faster.
By default the SSL handshake is performed with every new TCP connection being made to server. That is why the Connection: Keep-Alive header should be used so a TCP session (and therefore a SSL one) to be reused across multiple HTTP requests. By not doing so you will overwhelm the server in the SSL handshaking process.
Any major browser supports at least on TLS version with fail-over to SSL 3. For instance IE8 on Win has TLS 1.2, FF 3 and Chrome have 1.0 and Safari on Mac has on version of TLS (not specified which one though).