TCP + SSL Session

[Harmeet Singh]

Hi,

I have a firewall with URL filtering enabled. SSL is also enable for this filtering. When client try to communicate with google.com (example), first it get IP of google from DNS and then start TCP 3 way handshake process. All communication go through firewall and client-server establish TCP connection. Now they start SSL handshake and establish that also. But when I check certificate detail after opening google page, it shows my firewall certificate. How does this happen.

As I know first TCP session does establish and then SSL. If TCP session does establish direst with google server then how does firewall certificate come in picture because SSL should also get establish with google server. How this all happen. Even I checked on wireshark also. i saw there that First TCP build with server and then TLS with same server IP. But certificate in browser was from my firewall. If TCP and SSL connection is with actual server IP only then how firewall certificate come in between.

Thanks. 

[Rob Ingram]

@Harmeet Singh sounds like your firewall is doing SSL decryption, so it is intercepting the SSL request and resigning with its own certificate. https://www.cisco.com/c/en/us/td/docs/security/firepower/670/configuration/guide/fpmc-config-guide-v67/getting_started_with_ssl_policies.html

[Harmeet Singh]

Hi Rob, appreciate your revert.

My query was not related to configuration. I want to understand the process how this happen.

[MHM Cisco World]

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/214581-firepower-data-path-troubleshooting-phas.pdf

simple answer NGFW have SSL policy, what mean 
the FW be between the Client and Server, this way the FW have KEY/CIPHER for SSL to decrypt any SSL secure traffic pass though it.

[Harmeet Singh]

If SSL is between client and server then how does firewall has key/cipher.

[MHM Cisco World]

Client->FW
client send TCP handshake to FW
FW->Server 
FW send new TCP handshake to Server 

from view of Server it see FW not see client and this how FW protect the inside client.

@amojarra explain it with more detail see below his comment 

[Harmeet Singh]

@MHM Cisco World  

I captured in wireshark. Client direct establish TCP +SSL with server.

[MHM Cisco World]

in your wireshark capture 
are the TCP stream index is same for TCP client and TCP server ?

[Rob Ingram]

@Harmeet Singh the links to the cisco document above has the information you require.

If the system detects a TLS/SSL handshake over a TCP connection, it determines whether it can decrypt the detected traffic. If it cannot, it applies a configured action:

• Block the encrypted traffic

• Block the encrypted traffic and reset the TCP connection

• Not decrypt the encrypted traffic

If the system cannot decrypt the traffic, it blocks the traffic without further inspection, evaluates undecrypted traffic with access control; otherwise, the system decrypts it using one of the following methods:

• Decrypt with a known private key. When an external host initiates a TLS/SSL handshake with a server on your network, the system matches the exchanged server certificate with a server certificate previously uploaded to the system. It then uses the uploaded private key to decrypt the traffic.

• Decrypt by resigning the server certificate. When a host on your network initiates a TLS/SSL handshake with an external server, the system resigns the exchanged server certificate with a previously uploaded certificate authority (CA) certificate. It then uses the uploaded private key to decrypt the traffic.

[Harmeet Singh]

@Rob Ingram I gone through the document that you shared and also found attached document. What I understood is that TCP session would be single  but SSL session would be dual. 

TCP>>>>Between Client and Server

SSL>>>>Between Client and FW + Between FW and Server

Am I right.

[amojarra]

@Harmeet Singh 

This is like what happens in the HTTPS Proxy, 

There are 2 separate Https sessions :

1- Client to F/W ( or https Proxy )

2- Firewall to Webserver 

In this case the F/W act as the Google Web Server and reply to you with Google IP.

On the other hand it will send the request to the Webserver acting as it is the real client.

Since the traffic is HTTPS, your browser need to trust the Certificate generated by your firewall which is acting as the real Google Certificate in your case. 

+++++++++++++++++++++++++++++++++++++++++++++++++++

++++   If you find this answer helpful, please rate it as such  ++++

+++++++++++++++++++++++++++++++++++++++++++++++++++

[Harmeet Singh]

@amojarra 

In proxy case, traffic directly go to proxy (IP configured in browser). Even DNS resolution also does done by proxy. That means client nothing know about server information and proxy does everything on behalf of client. In that case it is clear to me that client only know about proxy IP and it create TCP+SSL with proxy only.

But when traffic follow routes and pass through firewall with NAT, that time client direct establish TCP+SSL with server. Query is here that if TCP+SSL establish directly between client server then how firewall certificate come in between.

I checked on wireshark also. TCP and SSL does happen between client IP and server IP but certificate come in browser from firewall.

[amojarra]

@Harmeet Singh 

Thanks for the reply 

what you say is 100% correct in Explicit Proxy mode, in Transparent Proxy the Client have no idea there is a Proxy server in the network.

in both cases, if SSL inspection OR https Decryption is enabled, Proxy server act as Man In The Middle. 

you can try to capture packets from Firewall, you will see 

Client  ----- TCP.stream 1  ---> Firewall ---- TCP.Stream 2 ---> Google

so there will be 2 separate sessions there.   

+++++++++++++++++++++++++++++++++++++++++++++++++++

++++   If you find this answer helpful, please rate it as such  ++++

+++++++++++++++++++++++++++++++++++++++++++++++++++