Decrypt-error with Inbound Decryption DHE or ECDHE on 8.1.3

[jsalmans]

Greetings all,

I feel like I'm probably missing something simple here, but I'm running into a decrypt-error issue on 8.1.3 in regards to a server that is negotiating DHE or ECDHE ciphers with the client.  On Chrome I get:

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

And on Firefox I get:

SSL_ERROR_NO_CYPHER_OVERLAP

If I turn off decryption for this or set it to RSA only, the traffic goes through (albeit not decrypted) so the client and server do indeed have shared ciphers they can negotiate to.  A packet capture from my machine and an SSL Labs scan of the server seems to back this up.

I know DHE and ECDHE wasn't supported on Inbound Decryption before but the warning is no longer on the configuration GUI and I see newer documentation that it has been supported since an 8.0 version.

Any ideas on what I might be doing wrong or how I should proceed with troubleshooting?

[gwesson]

The Firefox error is better in terms of what it's saying: no cipher overlap.

When your client sends the Client Hello, it will specify some number of cipher suites that it supports. When the server (your firewall in this case) gets that list, it tries to match with the highest security cipher in that list. But if the firewall doesn't have any that match the client's list, you will get the error that you got.

Check a few things:

1. Your decryption profile on the firewall should include at least one cipher that the client is sending. Go to Objects > Decryption > Decryption Profile and hit the SSL Protocol Settings on the profile you use in your decrypt rule for this traffic.

2. While you're there, make sure that the "Protocol Versions" is set with the max version of "Max". Chrome has recently stopped supporting TLS 1.0, and others (Firefox, Edge, Opera, Safari, etc.) may have as well or will be soon), so if you're maxing that out at TLS 1.0 or 1.1, you'll be out of luck for most browsers.

3. Make sure that your browsers are configured to send all the DHE and ECDHE ciphers it should, and that they haven't been artificially limited by some setting on your end.

4. Run a TLS check (Qualys has a popular one for free) to see what you're supporting if the site is publicly accessible.

[MP18]

Very good Explanation.

[jsalmans]

Thanks for the reply.

1. I believe I've done that. 
   
   
   
   
2. I've tried this as Max and also setting TLS 1.2 as the max.
3. As far as I know, Firefox and Chrome are both using whatever the defaults are.  If I turn off decryption, I can see it negotiating successfully with the server wiht an ECDHS cipher.  Here is what the packet capture is seeing my client offer.
   
   
   
   
4. Here is the SSL Labs results for TLS 1.2:
   
   

[LukeBullimore]

This is as far as I understand it:

For decrypting inbound connections whereby RSA is used, the firewall doesn't have to proxy the connection since it has the private key, it can decrypt the traffic on the fly.

For DHE and ECDHE traffic, since there is a new public/private key pair for each session the firewall cannot simply decrypt the traffic as it passes through, it instead needs to proxy with the server. Perhaps if you do a packet capture on the server side of things you should see traffic from there to the firewall with the SSL handshake failing?

Cheers,

Luke.