TLS versions and NAT methods

[lincolnwebber]

Hi Guys,

I have noticed an issue with a particular Internet website depending on the NAT method used by the firewall when accessed by clients inside the network.

If I hide the traffic, the website will not load (timeout). However, if I static NAT, the website loads fine.

I took tcpdumps of both scenarios and noticed the following:

• When using hide NAT, the TLS version proposed by the gateway/hidden address is TLSv1 (site times out)
• When using static NAT, the TLS version proposed by the static NAT address is TLSv1.2 (site loads successfully)

Any idea what may cause this? Can I force the firewall to use TLSv1.2 as a client?

[PhoneBoy]

Version/JHF of the gateway?
What blades are enabled on the gateway?
Did you run a tcpdump to see what the actual clients are proposing?
The only time I'd think we'd mess with the TLS version is if HTTPS Inspection is on.
Not sure why the NAT type would make any difference.

[lincolnwebber]

The Blades the are enabled are:

• Firewall
• IPsec VPN
• Policy Server
• Dynamic Routing
• SecureXl
• QoS
• ClusterXL
• Monitoring

See attached tcpdumps  taken on the PC. Note the highlights

[PhoneBoy]

The only thing I can think of that might be affecting this somehow is…SecureXL?
Try doing an fwaccel off and repeat the test from a different system.
As this disables SecureXL templating, it is not recommend to run with this off for long.
It can be re-enabled with fwaccel on. 
Either way, I recommend engaging with the TAC. 

[lincolnwebber]

Thanks Dameon,

We'll try that and let you know. In addition, look at the attached that shows the expanded TLS info.

[Bob_Zimmerman]

TLSv1.2 is always proposed as an upgrade from TLSv1.0. If the negotiation times out, you won't ever see the TLSv1.2 upgrade message, so Wireshark will identify the negotiation as TLSv1.0. Meanwhile, when Wireshark sees the upgrade to TLSv1.2, it retroactively marks all packets as TLSv1.2. Ignore the TLS version stuff, as it's not actually part of the issue.

[Bob_Zimmerman]

To demonstrate what I'm talking about, I just captured my laptop connecting to ipchicken.com. Here's a segment of Wireshark's analysis of the Client Hello:

Note that the handshake's protocol version is TLSv1.0, then within the handshake (in the Client Hello), the version is TLSv1.2. That's my client specifying it can negotiate TLSv1.2. Then there's a supported_versions extension to the Client Hello where my client says it actually supports 1.0, 1.1, 1.2, or 1.3.

The handshake reply from the server then has its version set to TLSv1.2, the Client Hello specifies TLSv1.2, then the supported_versions extension contains only TLSv1.3. This is how we end up with a TLSv1.3 connection with no TLSv1.2 in use at all. Totally obvious, right?

TLS negotiations are incredibly junky. Until Wireshark sees the Server Hello's contents, it can't be sure which version is actually in use.

Fun side note: you see the 0x0301, 0x0302, 0x0303, 0x0304? Those are the version numbers in hexadecimal. SSLv3 was 0x0300. TLSv1.3 calls itself SSLv3.4 internally.