SSL (also known as TLS) provides the padlock and HTTPS secure version of websites you visit. When you request a secure version of a website, such as https://www.facebook.com you are setting up a secure channel to communicate over, which stops attackers eavesdropping and manipulating the data in transit. This confidentiality and authentication is provided by the server and client agreeing on a set of algorithms and keys to use.
The process of agreement is known as the SSL Handshake protocol. Over a number of passes back and forth both parties agree on which encryption and authentication algorithms to use. They will also agree on a symmetric master private key to derive further symmetric keys for the encryption and authentication.
Once the handshake is complete and the secure channel brought online by invoking the ChangeCipherSpec protocol the communications will be ‘secure’.
There are though more things that can be done to increase the security of the SSL connection and improve in places its performance, and I will talk about these in this article.
HSTS – (HTTP Strict Transport Security)
HTTP Strict Transport Security (HSTS) protocol helps mitigate against active man in the middle attacks where by the attack ‘strips’ the https connection from the request you made.
You browse to https://www.facebook.com an active attacker is performing some form of man in the middle and can manipulate the data between your machine and the Facebook web server. The attacker downgrades your request for the HTTPS version and facebook sees that you requested the http (none secure) version so returns this.
If you have been attacked you may not notice that you are actually communicating with the http (none secure) version of www.facebook.com and inadvertently enter your login credentials which will now be tramitted over the network in clear text – allowing the active attacker to harvest your login details.
Enabling HSTS on the Facebook webserver tells your web client (i.e. Chrome) to always use HTTPS for Facebook connections. This means that if you requested https://www.facebook.com a few days ago, even if you later request the http (none secure) version your browser will automatically correct this and request the HTTPS version.
One minor problem is you do have to have successfully requested the HTTPS version at some point in the past. If the active attacker has been active before you ever went to Facebook then they will make sure that the header response from Facebook’s website never returns the flag to tell your browser to use HSTS – meaning Chrome doesn’t know to force HTTPS.
Forward Secrecy with Ephemeral DIFFIE-HELLMAN (DH)
Forward secrecy in a nutshell offers the security that if the private asymmetric key used as part of a asymmetric SSL handshake was later recovered, then it is possible to decrypt captured handshakes and messages and retrieve the symmetric key that was encrypted using the related public key.
When certain SSL handshakes take place, such as using RSA (in other words a type of public key encryption) a symmetric encryption key is created by the client and that is then encrypted using the public key of the server and transmitted to the server. The server using its private key decrypts the message, and then extracts the symmetric key. This key is then used to encrypt the actual traffic.
Asymmetric public key encryption works by encrypting using the public key and decrypting using the private key. You must have the private key to extract the symmetric key. If an attacker records communications between a server and client they could later steal the servers private key, extract the symmetric key, and decrypt the traffic.
One way an attacker could retrieve the private key would be to extract it from a decommissioned web servers hard drive.
Stop using RSA only, and use cipher suites that support forward secrecy. These make use of a protocol called Diffie Hellman, which rather than sending the symmetric key over the wire, both parties derive the key privately without ever transmitting the key itself (I will not go into detail about DH in this article, but it’s very clever).
SHA-2 is a hashing function, which in essence compresses some arbitrary message down into a fixed length output string which is a representation of the input, known as a digital fingerprint or message digest. Therefore, supply different input you will generally get different output. A hash function is commonly known as a one-way function.
SHA-2 is an improvement on SHA-1, which is widely believed to have become less secure with a number of academic and theoretical attacks being discussed within the community.
This relates to SSL because the SSL digital certificates, known as X509 v3 certificates that are issued by Certificate Authorities (CA) take the contents of the X509v3 certificate and hash the contents, this is then digitally signed by the CA’s private key.
You buy a digital certificate to use to provide SSL for www.facebook.com. You create the certificate and send it to a CA to get signed, this certificate contains the domain name, public key, expiry date, and other arbitrary data. The CA hashes this data and creates a fingerprint of the certificate using SHA-1 (now it should be SHA-2). The CA then using its private asymmetric key digital signs the fingerprint, attesting to the authenticity of it.
If someone can spoof the digital fingerprint using different certificate data, then they can produce a forged (hash collision) certificate that will appear genuine against the CA’s signature. In other words, SHA-1 may allow an attacker to do this, while SHA-2 as of this moment in time, is believed to be out of the reach of even the most determined attacker to conduct these types of collision attacks. The attacker can then serve the spoofed certificate, which to your browser will appear genuine.
Most, if not all, certificates today are issued having been signed using SHA-2. If not get a new SSL certificate. Modern web browsers are checking for SHA-2 and commonly altering users to ‘insecure’ SSL sites that still use SHA-1.
Elliptic Curve Cryptography (ECC)
Public key encryption has traditionally been seen as using RSA (a type of formula for creating the keys, and performing the operations on the data itself). The ‘newer’, even though its decades old, is known as Elliptic Curve Cryptography. I will not go into the mathematical differences, but in essence ECC is seen as a more efficient way to provide the equivalent strength of RSA encryption. ECC uses much shorter key lengths than RSA, reducing the computational requirement to work with them which is ideal for mobile devices and smart cards, offering potentially better performance.
Online Certificate Status Protocol (OCSP) allows a web client to check the validity of a received certificate live. The client can check if the certificate has not been revoked or otherwise marked as untrust worthy.
Traditionally SSL certificates were validated by checking against a register of known bad SSL certifcates known as the Certificate Revocation List (CRL). This required the web client to download the whole list, which is not very efficient, that’s why OCSP is seen as a better approach as you actually ask the service "Is the certificate I have here for the domain facebook.com still OK?".
The problem with this is it requires the clients web browser to make an additional outbound connection to check the validity. OCSP Stapling works by allowing the web server that is offering the SSL certificate to download the OCSP response and ‘staple’ it to the certificate and return it to the client. Commonly the web server will cache the OCSP response for sometime to speed up the process. This way the client can check the OCSP and certificate without needing to do another connection.
TLS Session Resumption
This is fairly simple in what it is attempting to achieve. HTTP is a stateless protocol, it makes a connection and closes it when the data is returned. This means for HTTPS connections a new full handshake needs to be completed for each request, this is not very efficient. Session Resumption allows the client to ‘pick up’ an already established session from a few moments ago and carry on without needing to complete the handshake again. The session resumption is a feature that needs to be supported by the server and it works by returning a Session ID within the SSL handshake which the client uses on its next connection as part of the ClientHello initial message.