Wireshark using Firewall ssl decryption private key to decrypt traffic

Question

Hi, WE have a cisco firewall that decrypts traffic by allowing us to install a server certificate on the firewall and also adding the client certificate to all the browsers keystore.

I know wireshark can decrypt SSL traffic if we provide it the private key of the server hosting a website. My question is can it decrypt the traffic going through the firewall using the firewalls private key that browsers in our office use? The problem I see is that the destination address is the external address not the firewall address and wireshark gives an error like the supplied private key is not for the correct server.

Is there a way to tell wireshark to use the gateway ip address and the address for decryption of the ssl traffic using the firewall certificates private key?

Thanks Al

Answer 1

1

Here is how SSL/TLS inspection works on a firewall. It will explain why you can't decrypt the traffic.

There is a CA cert (incl. private key) on the firewall, either generated on the Firewall or uploaded as PKCS#12 container.
The client tries to access an external HTTPS site
The firewall intercepts that request (explicit proxy or transparent proxy) and let's the client wait
The firewall itself opens a new SSL/TLS session to the target server S
As part of the handshake the firewall receives cert(S), which is the certificate of the server S
The Firewall on-the-fly generates a new certificate signed with it's own CA cert, with the whole content of the external cert, but with a different private key (obviously). So we have cert_fw(S) and privkey_fw(S), the cert + the private key created by the firewall to be used in the handshake for the client
The firewall completes the SSL/TLS handshake using cert_fw(S) AND privkey_fw(S).

After that, you will have two SSL/TLS connections

one: from Client -> Firewall with privkey_fw(S)
two: from Firewall -> Server with privkey(S)

This enables the firewalls to inspect the data, because it has access to the clear text payload 'between' the two SSL/TLS connections.

To be able to decrypt a SSL/TLS session with Wireshark, you need the private key of the 'remote' SSL/TLS endpoint.

As you don't know the real private key of the server (unless you are the server admin), you cannot decrypt the connection between Firewall -> Server.

Now, here is your problem: You also don't know the temp private keys generated by the firewall privkey_fw(S), as that's only stored on the firewall itself. I know only one or two firewalls that expose these temp keys via CLI. I don't know it for your Cisco firewall. So, unless you can access those keys, there is no way to decrypt the SSL/TLS connections between Client -> Firewall.

BTW: What you are installing on the clients is the CA cert of the firewall to prevent certificate warnings in the browser. But that's only the public key and won't help you.

So to answer your question: I'm sorry, I don't see any way to decrypt the connections between the client and the firewall, because you don't have access to the temp private keys generated by the firewall.

Regards
Kurt

answered 22 Oct '15, 13:04

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

Hi Kurt,

Thank you for the answer. As I mentioned I do have access to the private key of the self signed cert generated by the firewall. But I still wasn't able to decrypt the traffic between the firewall and the client.

I think the issue was that the destination ip address of the packet is the server (not the firewall). How do I go about decrypting the traffic from the client to the firewall if I do have access to the private key of the self signed cert that the firewall creates?

The fierewall IP address is the gateway ip address in our network.

Thank again for your help.

Al

(22 Oct '15, 14:22) aaghili

As I mentioned I do have access to the private key of the self signed cert generated by the firewall.

sure? Where did you get that from?

As I said, those keys are only generated within the firewall (on-the-fly) and you (usually) won't have access to those keys. If you somehow have access, you'll have to pick the right key, because the firewall will generate a new private key for every external server your clients are connecting to. It does this the first time while a client connects to the external server. So usually you will end up with a few hundreds of thes temp private keys (and certs) on the firewall, for all sorts of external servers. So, you need to load each and every of them into Wireshark to be able to decrypt the connections to those sites, OR pick a certain key to decrypt only the traffic to that particular server. So, there is no single RSA key to decrypt the whole communication between clients and firewall, because the firewall will use different keys for every external server. Maybe I was unclear about this in my explanation.

(22 Oct '15, 15:34) Kurt Knochner ♦

ok maybe I misunderstood.

But this still doesn't make sense. Why does the firewall need to create a private key for every external server? The ssl handshake is between the browser (client using FW self signed cert public key) and the firewall (using a single private key from the self signed cert) for the 1st step of decryption. And then between the firewall (in this case the client) which uses the public key of the external server to complete the handshake with the external server private key.

See below

STEP 1 decryption at firewall. browser (fw self signed cert public key) ---> firewall (self signed cert private key) ssl handshake and decryption

STEP 2 re-encryption at firewall. firewall (server public key) ---> server (server private key) ssl handshake and encryption.

The browser uses the public key from the self signed server cert created by the firewall to complete the handshake and there is only a single private key for the self signed server cert.

Can you please let me know what the tshark command would be if I had the private key of the firewall self signed cert?

tshark -o "ssl.keys_list: 127.0.0.1,443,http,/home/privkey.pem" -o "ssl.debug_file: /home/.wireshark-log" -i eth0 -R "tcp.port == 443"

Is the ip address in the keylist the firewall ip address or the server ip address.

Thanks, I'm just trying to get a clearer picture of this.

Al

(23 Oct '15, 07:11) aaghili

Why does the firewall need to create a private key for every external server?

It does not have to, but all firewalls I know (about 5-6) do that. I guess your Cisco firewall is no exception. Reason why: It's good security practice to do that.

Can you post a pcap file with sessions to https://www.apple.com, https://www.wireshark.org and https://www.goole.com. In the capture file we will see, if there are different public keys (in the intermediate certs) or if it's allways the same (which I doubt). Different public keys, implies different private keys as well! If it's a different key for every domain, your firewall behaves like all others I know and then there is no way to decrypt the communication between client and firewall, as described in my answer.

(23 Oct '15, 08:42) Kurt Knochner ♦

Sorry how do I attach a pcap file? Or did you want the tshark output of the pcap capture?

(23 Oct '15, 09:43) aaghili

You can't. Please upload it somewhere (dropbox, etc.) and post the link here.

(23 Oct '15, 10:44) Kurt Knochner ♦

ok here is a link to dropbox pcap file. And actually https://www.dropbox.com is the site I went to and got the capture. The firewall has a self signed certificate that we import the public key into the browser or dropbox can't be accessed inside our firewall. Basically I'd like to know if wireshark could use the private key of this self signed certificate to do the decryption for analysis. Please let me know if you need anything else. Thanks again. Al

https://www.dropbox.com/s/tkleshas3yrayzj/dropbox.pcap?dl=0

(23 Oct '15, 11:10) aaghili

O.K. there are several TLS conversations in that capture file, however only those to dropbox sites have been intercepted. You can see it, if you look at the certs in the handshake. The intercepted ones have been issued/signed by the "CA" 192.168.120.253.

All other TLS connections have not been intercepted. So, this file does not contain what I asked for: Intercepted TLS connections for different servers/domains (apple.com, google.com, wireshark.org, etc.). I wanted to check if the Firewall is going to use the same public/private key for all sites. If possible, please provide a pcap file for those sites (with interception) as well.

Let's look at the TLS connections to dropbox.

Apparently they are all using the same public key in the intermediate certs, so your firewall does NOT create a new private key for every domain, at least that's what I see for the dropbox domains: www.dropbox.com, marketing.dropbox.com and *.dropboxstatix.com.

openssl.exe x509 -inform DER -in www.dropbox.com.cer -noout -modulus Modulus=E8F1B13A6CC3AA83C1A285BABCCE43B831B9D9AEE04D63F9548BECFEFEEBF 0BEBFE075C08A16C761BBDABC7F9A80C4C1F724B4F7EA38FFEF7FF9A232A77304ABE2 500B2ED8DA5F699BE6B4CC2DF755E3DBDA5D11EFE78DCA9AED9CD0CCFDF92BC7B33F3 3842982270D99D77C190525D2DF0CF79BD963C80611BCEA5713A092C213C7195BF590 58860DCD8B2FAA48C41C002F204A5432E266F29FAA57650E7F356E15BEB2486779011 703BBC96E9113B318CEFA024B7C06B3E51CD0ED5881624E64753C7FF440EFED2C84A9 931A3FA022CCFEE89C5CED4146C8407466A9CC730E01CA2C209BDCFABA20D89C10B5B 9A8BCA18F4E6E3CD0F2BB29C5AC1594511D openssl.exe x509 -inform DER -in star.dropboxstatic.com.cer -noout -modulus Modulus=E8F1B13A6CC3AA83C1A285BABCCE43B831B9D9AEE04D63F9548BECFEFEEBF 0BEBFE075C08A16C761BBDABC7F9A80C4C1F724B4F7EA38FFEF7FF9A232A77304ABE2 500B2ED8DA5F699BE6B4CC2DF755E3DBDA5D11EFE78DCA9AED9CD0CCFDF92BC7B33F3 3842982270D99D77C190525D2DF0CF79BD963C80611BCEA5713A092C213C7195BF590 58860DCD8B2FAA48C41C002F204A5432E266F29FAA57650E7F356E15BEB2486779011 703BBC96E9113B318CEFA024B7C06B3E51CD0ED5881624E64753C7FF440EFED2C84A9 931A3FA022CCFEE89C5CED4146C8407466A9CC730E01CA2C209BDCFABA20D89C10B5B 9A8BCA18F4E6E3CD0F2BB29C5AC1594511D

openssl.exe x509 -inform DER -in marketing.dropbox.com.cer -noout -modulus Modulus=E8F1B13A6CC3AA83C1A285BABCCE43B831B9D9AEE04D63F9548BECFEFEEBF 0BEBFE075C08A16C761BBDABC7F9A80C4C1F724B4F7EA38FFEF7FF9A232A77304ABE2 500B2ED8DA5F699BE6B4CC2DF755E3DBDA5D11EFE78DCA9AED9CD0CCFDF92BC7B33F3 3842982270D99D77C190525D2DF0CF79BD963C80611BCEA5713A092C213C7195BF590 58860DCD8B2FAA48C41C002F204A5432E266F29FAA57650E7F356E15BEB2486779011 703BBC96E9113B318CEFA024B7C06B3E51CD0ED5881624E64753C7FF440EFED2C84A9 931A3FA022CCFEE89C5CED4146C8407466A9CC730E01CA2C209BDCFABA20D89C10B5B 9A8BCA18F4E6E3CD0F2BB29C5AC1594511D

Now, it would be interesting to see if you have the matching private key. So, either you run the following command and post the output here

openssl rsa -in key.txt -noout -modulus

Or you upload the key somewhere and post the link here (please consider security issues!).

If the Modulus is identical, you have the right private key and then you should be able to decrypt session, but only to those three domains!

In Wireshark, you’ll have to define the RSA key as follows.

IP, Port, Protocol, Key_File

IP: real IP address of the external server, as that where your clients are connecting to.
Port: 443
Protocol: http
Key_File: the key file

However, if the Modulus is different, you don’t have the temp private key, generated by the firewall and thus you cannot decrypt the traffic.

We’ll see ….

(23 Oct ‘15, 13:25) Kurt Knochner ♦

showing 5 of 8 show 3 more comments