SSL Visibility Appliance

 View Only

Now supporting TLS 1.3 (RFC 8446) – no downgrading! 

Sep 03, 2018 08:43 PM


Yes, we’re pretty sure we’re the first.  There are many solutions for Encrypted Traffic Management and whether you call the go-to network devices a TLS Interception Application (TIA), a Middlebox, a SSL interception tool, or anything else; we think that the Symantec SSL Visibility Appliance (SSLV) has beaten all others to the punch. 

As of Wednesday August 29 the Symantec SSL Visibility Appliance is able to provide inspection of native TLS 1.3 (RFC 8446) sessions that does not require downgrading to an earlier TLS version. The IETF published RFC 8446 on August 10, based on the approved Draft 28.  Don’t be confused, while Draft 28 was very close to the final, it isn’t exactly the same.  Of course, SSLV has supported Draft 28 as far back as last March.

This means that the Symantec SSL Visibility Appliance can act as a controlled man-in-the-middle device to intercept TLS 1.3 traffic, enable inspection, and re-encrypt the traffic with the same protocol version and cipher strength.  As far as we know, all other solutions on the market will need to knock the session down to something older and weaker.

The SSL Visibility Appliance has supported TLS 1.3 in its draft forms for nearly a year, starting with Draft version 18. We’ve had several updates to keep pace with the evolution of the drafts and now we’re happy to say that the waiting is over.  TLS 1.3 is now final-final, fully-baked, and done.  If you were waiting for this change to make a move and upgrade your infrastructure to TLS 1.3 – now is the time to act.

Many of technologies biggest names are going to move fast to implement TLS 1.3 for the performance and security benefits that come with it. A quick internal test shows that Facebook, Mozilla, Cloudflare are using TLS in the Draft 28 form.  Google Search may be using TLS1.2, but Gmail is also showing TLS 1.3 Draft 28.  It’s highly likely that these internet giants will be using the final version (RFC 8446) soon. When they are ready, we’re here and waiting. 

If Google, Facebook, Mozilla or Cloudflare traffic is hitting your network, shouldn’t it be protected with TLS 1.3 and inspected for malware and other hidden threats? We think you should.  Now you have a choice: wait for your middlebox solution to catch up to us in support of TLS 1.3, or give us a shout and let us show you how quickly we can help.


0 Favorited
0 Files

Tags and Keywords


Mar 08, 2019 07:12 AM

Hi Dave

I'd like to ask an additional question based on your explanation on the interception of the server's certificate in the outbound case with TLS 1.3. If I am not mistaken, the server's certificate is already encrypted in the TLS 1.3 handshake. Do I assume correctly that the proxy will be a visible proxy in that case (or an honest mitm so to say...). Just to explain what I mean. I think that is what happens in case a client tries to reach an external server using TLS 1.3

  • client sends DNS request to the proxy
  • proxy replies with its own IP and resolves real server's DNS as well
  • proxy connects to the real server to get its certificate's common name (that is encrypted in the handshake, hence proxy has to connect first)
  • client connects to proxy who now presents a certificate with the real server's CN but signed with a special intermediate CA (trusted by the client)
  • like that, the proxy sits in the middle of two TLS1.3 connections and hence, can inspect all traffic

Is that accurate?



Dec 18, 2018 04:58 AM

Perfrec forward secrecy is not unique to TLS 1.3, it is supported in earlier TLS version whenever the key exchange mechanism during the handshake is Diffie Hellman rather than RSA. TLS 1.3 does not support RSA key exchange so all TLS 1.3 sessions provide perfect forward secrecy (PFS). In order to provide visibility into a PFS session any device doing this must be a bump in the wire i.e. it is in-line between the client and the server. This is required because PFS sessions rely on random elements that are created by the client/server and that are not communicated over the wire. In order to negotiate a session key a device between the client and server must be able to use it's own random elements when handshaking with the client and with the server. So, the device is effectively a proxy at the TLS layer and when it is inspecting traffic there are two TLS sessions, one from the client to SSLV and another from SSLV to the server and these two sessions will have different session keys. The fact that the two session have different session keys means that SSLV needs to decrypt traffic using one session key, to get visibility of the encrypted traffic, then re-encrypt it with the other session key before it is sent on to the destination. 

The answer to your question about certificates is separate from the issue of how to gain visiblity into a PFS session and depends on what information is available to SSLV. There are two major use cases:

  • inbound SSL traffic, where a client you have no control over establishes a TLS session to a server that you do control
  • outbound SSL traffic, where a client you have some contorl over establishes a TLS session to a remote server that is outside your control

In the inbound use case you have access to the server certificate and private key and these can be loaded into SSLV and then used during the SSL handshake. When SSLV responds to the client during the SSL hanshake the client will "trust" SSLV as it is using the real server certificate and private key that the server uses. SSLV will still need to be between the client and the server and will need to use it's own random values when a PFS session is established and there will be different session keys in use between the client and SSLV and between SSLV and the server.

In the outbound use case you have control over the client which allows you to configure the client to trust an enterprise intermediate CA certificate. This intermediate CA will normally be issued by the enterprise PKI and will be a private CA i.e. not publicly trusted. In order for the client to truse any certificates issued by this enterprise intermediate CA the intermediate CA will need adding to the client "trusted" CA store. Once the client is configured to trust this intermediate CA it can be used by SSLV when inspecting traffic. The intermediate CA it's privafe key are loaded into SSLV and used to sign modified server certificates that are sent to the client. The process to inspect a flow is as follows:

  • TLS session is initiated by the client and the CH passes through SSLV and on to the real server on the Internet
  • Server responds with handshake messages including it's server certificate which is used by the client to authenticate the server
  • If SSLV policy is to provide visibility into this session then it will intercept the SSL server certificate from the server, modify it so that SSLV has the private keys corresponding to the public key sent to the client, sign the modified server certificate with the intermediate CA and then send it on to the client
  • The client will receive the modified server certificate and will check to see if it trusts it by looking at the issuing CA. As the enterprise intermediate CA is in the local store of trusted CAs the client will trust the server certificate and the session will proceed.

TLS is a secure protocol so the gaining visiblity into the encrypted session is only possible if you have some level of control over either the client or the server, as can be seen from the details above. In an enterprise environment control over intrernal TLS servers or internal clients is possible allowing an enterprise to inspect TLS traffic in order to carry out security checks that are required by the enterprise. 

Hope this answers the question?

Best regards


Dec 17, 2018 01:49 PM

How are you handling Perfect Forward Secrecy in TLS 1.3 ? Do you only support full proxy mode where you break the connection between the client and the server ? What if you don't have the certificates for the server the client is trying to reach using TLS 1.3? 

Sep 17, 2018 03:06 AM

Well done guys!


Related Entries and Links

No Related Resource entered.