topic Re: TLS versions and NAT methods in Firewall and Security Management

TLS versions and NAT methods

lincolnwebber — Tue, 24 Jan 2023 17:33:04 GMT

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?

Re: TLS versions and NAT methods

PhoneBoy — Wed, 25 Jan 2023 05:06:45 GMT

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.

Re: TLS versions and NAT methods

lincolnwebber — Wed, 01 Feb 2023 14:54:48 GMT

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

Re: TLS versions and NAT methods

PhoneBoy — Wed, 01 Feb 2023 18:06:32 GMT

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.

Re: TLS versions and NAT methods

lincolnwebber — Wed, 01 Feb 2023 19:11:08 GMT

Thanks Dameon,

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

Re: TLS versions and NAT methods

Bob_Zimmerman — Wed, 01 Feb 2023 20:23:20 GMT

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.

Re: TLS versions and NAT methods

Bob_Zimmerman — Thu, 02 Feb 2023 00:13:35 GMT

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.