Decrypt SSL Traffic to Look for Hackers
Encrypted traffic is a huge security problem for companies trying to monitor their network for security
breaches. After the Edward Snowden revelations, Google search, Twitter, and most other sites have
added encryption now, thus compounding the difficulty. Because https traffic is encrypted, monitoring
software cannot read it. So the security system cannot tell when hackers are moving large quantities of
stolen data through the firewall using HTTPS. The obvious way to solve this problem is to decrypt this
traffic. This is possible under certain conditions, although there are practical limitations. Here we
discuss that. You might want to check out the best books to learn hacking.
The Man-in-the-Middle Attack
Most IT persons are familiar with a man-in-the-middle (MIM) attack on an SSL session. This is when a
hacker has positioned themselves between either ends in an HTTPS session (i.e., HTTP over SSL/TLS).
The man-in-the-middle hacker reads traffic coming from the source user, decrypts it, reads it, then
encrypts it again and sends it to its destination. The victim does not know they are attacked, however,
the browser usually throws up a warning. It works because the hacker has grabbed the data packets that
contain the public key of both parties to the session.
Several firewall vendors have built the ability to do man-in-the-middle attacks into their devices so that
security engineers can monitor encrypted traffic and look for stolen data. These companies include Palo
Alto Networks and F5. Using this approach, the firewall can decrypt traffic and directing it to their SEIM
system or to syslog. There they can writing scripts or programs with regular expressions designed to
look for specific items like, “account number” or a specific account number, and flag that as an alert.
Such scripts would need to be able to read zipped data too, as hackers usually zip up data when they
steal it and send it to their command and control center. That is not a problem as programming
languages like Python can work with zipped files.
The Approach
The ability to do a man in the middle attack in a firewall is no different than a hacker using ssldump or
other tools to do it on Ubuntu. In other words, the approach used by Palo Alto and others is not any
newer than what hackers have always done. In particular, the lack of some way to improve the process
means the user is still going to know that their traffic is being decrypted. This is because the browser
will warn them. If there is no browser, as in machine-to-machine communications, then the encryption
will just stop.
The reason the browser warns the user is that the certificate authority (CA), i.e., the server that issued
the certificate is not trusted by the computer. This is because the certificate issuer’s root certificate—in
this case the CA is the firewall device—is not installed in the computer’s list of certificate authorities.
And even if it was, the cn (common name) of the certificate would not match the domain where the
user is going thus causing the SSL algorithm to reject it. In other words, the firewall will not have
certificates issued to itself for google.com, microsoft.com, wellsfargo.com, and all the other thousands
of web sites visited by users. But that is not necessary. It just means you cannot get rid of the browser
warning and not break machine-to-machine SSL sessions.
An Example
This is best illustrated with an example. In the example below, on a Windows PC we run mmc and add
the certificate snap-in to see what certificate authorities are on the PC. You can see that DigiCert is one
of them.
Then when the user goes to fastmail.com, the SSL encryption algorithm checks the certificate chain and
sees that the certificate is issued by a trusted authority. The certificate below was issued by DigiCert to
www.fastmail.com, so the SSL algorithm proceeds without throwing an error, which would show up as a
browser warning.
Here we see the cn or common name of the certificate. It is cn=www.fastmail.com. The firewall device
does not have that IP address. Thus the SSL negotiation session will throw an error which also causes
the browser to show the user a warning.
Privacy Concerns
Employees in the USA are taught that they should not expect privacy when they are using company
computing assets to conduct private business, like checking their bank account or personal email. In
Europe the privacy laws are different. If a policy to decrypt traffic is put in place, users will have to be
told that their employer is literally reading their mail. They will also need to be trained what to do when
the browser throws up a warning. Most user’s click right through this browser warning anyway, which is
in itself such a problem as you would not want to train users to continue doing that. Palo Alto Networks
lets the firewall administrator configure a different message to remind the user’s that their traffic is
being decrypted to not reinforce such behavior in the absence of firewall-based MIM. A great book that
covers Intrusion Detection and Malware Analysis can be found on this link.
Technical Limitations
Here are some technical limitations:




The MIM approach does not work for ssh traffic. You would think it does, as that also uses
SSL/TLS. The way that Palo Alto handles this is the firewall knows what program created the
traffic. If that was not ssh or any program on the approved list, it rejects the traffic.
It does not work for SSL that uses authentication, like DNSSEC.
MIM does not work with PKI. So you cannot read encrypted email or PKI authenticated browser
sessions.
It runs slow. The administrator would have to create a whitelist of sites, like gmail, to omit from
this process as there will be an enormous quantity of data to decrypt and encrypt. Think of it
this way: each browser is running the SSL algorithm as it each communicates with web servers,
like Twitter. And Twitter is handling encryption and decryption at its end. So that work is
farmed out among many parties. To ask one single device to handle all of that at the same time
would require a powerful computing platform, perhaps too large to be practical. So the targets
of decryption would have to be selected based on some eliminating factors, like IP.

VPN traffic will no longer work if it is riding over SSL, like the OpenVPN protocol, as the SSL
algorithm will simply shut down when the CA is not trusted. The way around that is to program
the firewall to ignore VPN traffic. But that would then leave VPN open as a path for hackers to
steal data yet block legitimate users. Most companies use VPN to for their employees to connect
to the corporate network.
Summary
The MIM approach is necessary if one wants to inspect encrypted network traffic to help discover
hacking attacks. Users will have to be told and trained how to use the system. Plus there are technical
and practical limitations. Perhaps because of the practical limitations it could be done on some random
basis to lower the workload and only on certain subnets.
If we think about this more, the MIM approach must not be working too well in actual practice in the
field or companies are not using it enough. If it did work then we would not be reading so much in the
news about high profile hacker victims who use encryption yet are still hacked. Or perhaps it does work
and we don’t know about that. It’s only when security breaks down that the whole world becomes
aware of it.