Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
lincolnwebber
Participant

TLS versions and NAT methods

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?

0 Kudos
6 Replies
PhoneBoy
Admin
Admin

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.

0 Kudos
lincolnwebber
Participant

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

0 Kudos
PhoneBoy
Admin
Admin

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. 

0 Kudos
lincolnwebber
Participant

Thanks Dameon,

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

0 Kudos
Bob_Zimmerman
Authority
Authority

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.

0 Kudos
Bob_Zimmerman
Authority
Authority

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:

Screenshot 2023-02-01 at 18.02.47.png

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.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events