SSL Visibility Appliance

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?

best

Carolin

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
Dave

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? 

Well done guys!