Decrypting SSL: Methods, Techniques and Implications

SSL uses two keys, a private key (also known as a server key) and a public key. The private key can decrypt and sign, while the public key can only encrypt. In general, the process goes like this:

1. A web SSL certificate is electronically signed by a Certificate Authority (CA). The CA’s certificate is embedded in browsers.
2. When your browser initiates an SSL connection to the server it responds with its signed SSL certificate. Your browser verifies the signature of the certificate with correct CA’s certificate that is embedded your browser. If verification passes it extracts the public key from the server's certificate.
3. The browser then sends a small parcel of information (typcally 50-60 bytes) to the server. This parcel is not stored anywhere and is encrypted with the public key and can only be decrypted with the corresponding private key.
4. The parcel forms the basis for a slightly larger key, used to encrypt the actual transmission of content between the browser and the server. This is typically a much faster cypher than that used by the original parcel. There are variations in how different cyphers operate, but the general principle is the same.

When a packet capture appliance captures the initial parcel of information, it would show you the encrypted state of that randomly chosen short key. Without the private key, you cannot decrypt the data and see the unencrypted content. The computer participating in the transmission, however, retains the key in its memory so that it can continue to communicate with the server throughout the SSL session.

SSL and Packet Capture

Unless modified, packet capture appliances capture Ethernet / IP traffic exactly as transmitted, which means that if a captured session is conducted using SSL encryption, the captured packets would be encrypted as well. To know the content you would need a way to decrypt the SSL.

There are basically two methods for decrypting SSL transmissions. One way is to hack it, that is, using brute force to expose some irregularity that will help with decryption. A simpler way is to use the private (or server) key.

Alternatively, you could deploy a custom packet capture solution that employs a method for decrypting and storing SSL transmissions on the fly. We can customize our IPCopper packet capture appliances with a feature to enable SSL decryption, however, in many cases, it is not actually necessary to know the SSL content. In fact, decrypting SSL content could have many ramifications and unintended consequences.

Is It Necessary to Decrypt SSL Sessions?

In many circumstances, you may not find it necessary to decrypt SSL transmissions. For example, if a business has deployed a packet capture appliance to, in part, see whether employees are accessing Facebook or private Gmail accounts while at work and using company resources, decrypting the SSL is not necessary. SSL transmissions do not hide the destination and origination of the session, so you would be able to tell whether someone went to Facebook or Gmail just from the raw packet capture and from what computer on your network.

SSL decryption is not necessary, even if the purpose is to catch transmission related to malware or advanced persistent threats (APTs). The vast majority of malware, which comes in the form of email, spyware and etc, is not SSL encrypted. Currently most organizations do not employ continuous packet capture, giving hackers very little incentive to go to the effort of trying to hide their transmissions.

Implications of Decrypting SSL Sessions

Continuing with our example, if the business above were to decrypt SSL sessions automatically, it could be generating more of a liability than a benefit if the captured SSL sessions are private and personal. For example, if an employee used his or her computer during a break to conduct online banking, the banking session would be automatically decrypted and the employee’s password and the content of the banking session would be captured and stored on the business’s packet capture appliance in plain, unencrypted form. The same thing would occur with private emails – the business would have captured and recorded both the private email passwords and the content of the email(s). In such circumstances, it may be best to not decrypt SSL sessions automatically and simply capture and record the encrypted transmission as is.

The fact that SSL sessions are encrypted does not impede investigation and prosecution. Avenues exist to decrypt the data, as long as you have the captured session. For more information on solutions to decrypts SSL, contact us and we can discuss the specifics of your situation.