TLS decryption… more specifically, decrypting employee’s web traffic. It’s one of those subjects that really seems to divide people. Some privacy advocates will argue it goes against everything a secure web is meant for. Security engineers will claim they are unable to effectively protect an organisation without it. Who’s right?

Transport Layer Security

TLS… also commonly referred to as Secure Sockets Layer (SSL - its outdated, insecure predecessor). TLS is responsible for securing the majority of web traffic today.It uses server-side certificates and a “chain of trust” approach to allow devices to validate they are talking to the site they intend.In recent years TLS has really started to increase, helped in part by companies such as Lets Encrypt who now provide the necessary certificates for free! This is a really good thing - we need HTTPS in our lives.

This post isn’t intended to be an in-depth tutorial of the TLS process. I will however start with a high-level overview just to refresh your memory…

  1. A browser makes a request to indicating it wants to communicate securely
  2. The web server responds with various information, including its certificate. The certificate includes many different fields, of particular note are:
    • Who it is issued to - e.g. the website name and other identifying information
    • Who it was issued by - the certificate authority (CA) that approved and issued the certificate
    • Validity - when the certificate became valid and when it is valid till
    • Public key - this is used in part to setup a secure communication - remember with public/private keypairs that only the private key can decrypt something the public key encrypted
  3. The browser then validates this information. This validation process includes checking:
    • That the name entered into the address bar matches the certificate
    • If the certificate is valid (not past its expiry date)
    • The certificate is issued by a certificate authority the browser trusts (if there is more than one issuing authority in the chain, the browser must be able to validate all the way back to the “root”)
    • That the certificate has not been revoked
  4. Assuming the checks above pass, the browser then uses the server’s public key and other protocols/values to setup a secure communication channel

Now remember, the chain of trust mentioned above always securely ties an identity certificate back to a trusted root. If any element fails validation then the browser is going to throw up warnings. Take my website for example (correct at the time of writing):

  1. The identity certificate is for “”. This was issued by “Let’s Encrypt Authority X3” and signed using their private key. This signature allows the browser to validate that it was actually them who signed it
  2. The certificate for “Let’s Encrypt Authority X3” was issued and signed by “DST Root CA X3”
  3. “DST Root CA X3” is the root of the chain of trust. This certificate must be in my browsers/OS list of trusted root certificates else it will not pass validation

Having one or more issuing CAs (AKA intermediate CAs) is common and good practice. It is unusual that a public CA would issue identity certificates directly under their root (I won’t get into details of why in this article).

Keep in mind that browsers may not always have all intermediate certificates installed, so a website should always send back the identity certificate and any intermediate certificates. Note however, that sending back the root certificate as well is pointless. Sure, you can send it, but if it isn’t in the trusted root store of the browser it won’t make a difference - validation will still fail.

Man in the middle

Now you understand how the TLS process happens at a very high-level, let’s review what a man in the middle (MiTM) attack looks like.

  1. A browser makes a request to indicating it wants to communicate securely
  2. This reaches the “attacking” device instead of the actual website. When the attacker receives this request, they will initiate a connection to my intended destination
  3. The actual web server responds with various bits of information as per the TLS process shown earlier
  4. The attacker re-packages this information into a new certificate (with a different public key) and signs it with a CA certificate/key that they control. This is sent back to the browser
  5. The browser then validates this information as before. This is hopefully where an attacker would fail! The name may well match, the certificate may well be within its validity period, but if the attacker hasn’t managed to install his root in your trusted list, the browser will throw up a warning

This process is not always used for malicious purposes though - this is exactly how TLS decryption in various security solutions works. The only difference being that “Bad Guy Root” would be replaced with “Your Company’s Enterprise Root”. Hopefully your administrators would have installed the root certificate and public key into the browser’s trusted root store too!

It is important to realise here that the decrypting device in the middle maintains two unique sessions - one to the internal client (with a spoofed certificate) and one to the destination website (which the server would see as a normal connection). The device in the middle will take the client session, decrypt it, do whatever it is going to do (good or bad!) and then re-encrypt to the final destination.

TLS decryption in the workplace

Most “next-gen firewalls” (marketing love that phrase!) and other devices, such as load balancers and web proxies, support TLS decryption. Decryption is either for outbound traffic (which operates as I outlined earlier) or for inbound connections to your servers (where you already have possession of the private key - this process differs from above and I won’t cover it in this article).

I work with a lot of devices that support TLS decryption, but don’t see clients particularly using it. Why? A lot of people seem to avoid outbound TLS decryption primarily due to performance degradation. Decrypting all that traffic is resource intensive and can significantly reduce throughput. This largely depends on the architecture of the device and any hardware offloading it does though, so not always as relevant.

But what about privacy and security implications though?

The good points

Let’s start on a positive note. Decrypting the web traffic of your employees can be an incredibly useful thing to do from a security point of view. As highlighted earlier HTTPS is so much more prevalent nowadays. Looking at Google’s transparency report we can see some statistics they have for percentage of pages loaded in Chrome over HTTPS. Pretty high and now well above 50%…

This increased use of HTTPS is a good thing! The web needs HTTPS to fix a lot of problems. However, it also brings with it some challenges. It isn’t just trustworthy sites that use HTTPS - malware is commonly downloaded over it as well. Where this is the case, that fancy next-gen firewall with all its IPS and anti-malware features isn’t able to protect you. If it can’t see the content it can’t determine if it is malicious or not.

So, if you decrypt your user’s web traffic what are the main benefits? The newfound visibility provides the following benefits:

  • Improved malware detection of files - Files downloaded from a HTTPS site are no longer invisible to the appliance in question
  • Better Intrusion Prevention System (IPS) protection - Attacks that would previously have gone unseen can now be caught
  • More accurate URL filtering - Instead of relying solely on looking at the certificate for classification, the appliance can now view the actual host header and full URL requested
  • Data Loss Prevention (DLP) - Being able to see what users are uploading to the Internet allows you to implement DLP controls and prevent employees maliciously or accidentally exfiltrating data they shouldn’t
  • Application Visibility and Control (AVC) - Many different applications can be tunnelled over HTTPS and its standard port 443. Being able to see into the encrypted packet allows you to control these per your company policies

As you can see being able to view the traffic allows you to do a lot more to protect the network. But what about the drawbacks?

Privacy issues

If your IT security team are performing an intentional man in the middle, then clearly there is the possibility for privacy violations. The device that is carrying out the man in the middle operation has the capability to view your traffic in clear text before re-encrypting to the end destination. This traffic could be any number of things:

  • Login credentials to websites
  • Your bank details
  • Your credit card number
  • Private medical information
  • A really private email to your Nan

You get the idea… if someone with appropriate administration rights wanted to, they could probably login to the device and capture lots of private data. Now, hopefully they won’t do this and there are processes in place to limit administration access to the device. And hopefully they have configured the device to exclude certain sites from decryption (such as banking). And hopefully the device is secured correctly from the outside world. But that is quite a few “hopefully’s”…

I’m fairly sure there are also likely to be plenty of legal issues surrounding the use of TLS decryption. This will vary hugely based on the country of implementation, what you are doing and how you have communicated it. I’m no legal expert by any stretch of the imagination. It is not something I usually have to get involved in, but as far as I can see from some research (Googling!), it seems to be perfectly legal in the UK at least. As long as the end users clearly understand this is going on and agree to the relevant policies. However you go about it, it would seem wise to consult your legal team (or external legal professional) before implementing such a technology.

Note: If you know more on the legal aspects of this technology I’d be keen to hear from you - drop me a line.

Security issues

What about security issues? As we’ve established from looking at the process above, your traffic is only in the clear whilst it is inside the box that is doing the inspection - so that is pretty secure right? What if your security team have misconfigured the device? There are a couple of potential issues I can foresee.

Expired/untrusted certificates

As I’ve highlighted above, the certificate your browser validates isn’t from the actual website - it is from the security appliance in the middle. But what if the destination website it actually serving up an expired or untrusted certificate? Your browser would have no way of knowing this unless the appliance indicated this somehow.

Fortunately, most appliances I’ve come across cater for this and will present an expired/untrusted certificate to the browser in this scenario. That way, the client would still receive the same error message it would have received if it had connected directly.

Cipher strength

Whenever you setup a HTTPS session to a remote web server, your browser and the server negotiate which cipher suite they will use. This cipher suite ultimately dictates what protocols to use for encryption and integrity checks - the stronger the better. A modern-day OS that is up to date will support nice strong cipher suites when talking to an equally well configured web server. But put a device in the middle and you are at the mercy of whatever that supports.

If the appliance is old or misconfigured, it could be significantly reducing the security of your HTTPS session, both internally and between the appliance and the web server.

HTTPS on the inside, HTTP on the outside

I will start by saying this one is less likely and probably more a hypothetical scenario. But, if the device has been configured badly enough, is it not plausible that whilst it may be secure between your laptop and the appliance, the appliance could be forwarding your traffic on the Internet side as plain HTTP? Your browser would have no way of knowing if this was the case.

As I say, I think this is probably quite unlikely and as far as I know most devices will establish a secure session to the remote server first before trying to generate a certificate (else how can they be sure what to include in the certificate). So unlikely, but I wouldn’t go as far as to say impossible.

My two cents

Whilst I recognise that there is clearly the potential for privacy and security problems, I would say I am mostly in favour of this technology within corporate networks. The additional protection you can gain from seeing inside the data is invaluable.

Do I not care about my private data? Absolutely! But my view is this… if I am at work, my usage of the corporate Internet should by and large be for business purposes. Therefore, any risks associated with privacy and security are likely to be related to business and not personal data. If you don’t want to take the risk then wait until you are back home before accessing anything for personal reasons.

That being said, let’s be realistic here - people do use corporate Internet for personal reasons. Perhaps company policies permit it, perhaps they don’t, but it is still going on. So, with that in mind, whilst I am in favour of TLS decryption it should be implemented correctly, with the appropriate controls and a decent helping of common sense. In my opinion this includes:

  • Exclusions - Certain categories of website should be excluded from inspection. This includes the obvious ones such as personal banking. The decision to exclude is usually based on the name in the certificate value and a known mapping to a certain category, so whilst it isn’t always going to be bullet-proof it is better than nothing
  • Policies - I am referring to policies in a couple of ways:
    • Firstly, user acceptance policies and associated training. End users must clearly understandexactly what is being done and why. People are a lot less likely to get upset over the use of such technology if it is all explained up front. Do not just try to sneak this technology in under the radar - its asking for all sorts of trouble
    • Secondly, policies and procedures to protect against the possibility of rogue administrators. You don’t want someone going in and sniffing people’s data for no reason. If the appliance supports role-based access control and command authorisation, consider locking things down so that administrators can’t just go in and run tcpdump without prior approval and a justified reason
  • Secure implementation - Taking the points above into account, ensure the product is configured correctly. Ensure you are enabling the securest possible settings to help protect your end user’s data. Importantly, make sure you test everything thoroughly. What ciphers does the appliance negotiate? How does it behave on receiving an untrusted certificate? How does it behave if the certificate has expired?
  • Keep it maintained - Like all systems, vulnerabilities are inevitable. Ensure you monitor the vendor’s vulnerability notifications and patch the appliance in a timely manner when you need to. It’s seeing a lot of private data - you need to make sure you keep it up-to-date

Your thoughts?

I am keen to hear other people’s thoughts on the use of this technology. Do you use it currently in your network? Is it something you are considering or are you dead against it?

Drop me a comment below or get in touch with one of the social media options.