1584267 - TLS Downgrade 1.0 after receiving a RST packet, regardless of About:Config TLS settings

Status: RESOLVED INCOMPLETE

(Core :: Security: PSM, defect)

Description

[Lance]

** Note: a downgrade to TLS 1.0 still happens even if FF is configured:

• Security.tls.version.fallback-limit = 3
• Security.tls.version.max = 4
• Security.tls.version.min = 3

Setup:
• Users HTTPS/TLS browser requests pass through multiple firewalls to reach external website.

Sequence of events leading to one specific TLS downgrade event:
• User A establishes a TLS 1.2 connection with an external website
• A number of HTTP requests are sent through the connection
• The webserver reaches its keep alive idle timeout and sends a FIN packet, half-closing the connection
• An organization’s NAT device reaches its half-closed connection timeout and silently drops connection tracking for this connection
• User A’s machine sends FIN packet to Firewall A; Firewall A responds with an ACK, fully closing the connection on the client
• Firewall A sends multiple FIN packets and eventually a RST packet to the organization’s NAT device. However, the NAT device does not respond or forward the packets through because it is no longer tracking this connection and sees these as spurious FIN/RST packets and Firewall A drops connection tracking for this connection when the RST packet is sent
• The website reaches its half-closed connection timeouts and silently drop connection tracking for this connection
• At this point, only Firewall B thinks the connection is still alive
• User B establishes connection with Firewall A
• Firewall A completes the TLS handshake with the same website (->SYN, <-SYN/ACK, ->ACK) and starts the SSL handshake (->TLS 1.2 Client Hello, <-ACK) with the client before it attempts to begin an external TCP handshake (before it attempts to send SYN packets) through the NAT device
• Firewall A begins sending SYN packets toward the NAT device, and the NAT device
• Firewall B receives the SYN packets, but it still thinks there is an active (half-closed) connection associated with these IPs/ports, so it silently drops the SYN packets since it thinks they are out-of-order and associated with the existing connection
• Because it never received a response to any external SYN packets, Firewall A times out and sends an RST packet to the client
• The client received a RST after it sent a TLS 1.2 Client Hello but before it received a TLS 1.2 Server Hello, the browser assumes that it is talking to a buggy TLS 1.0 server, so it downgrades to TLS 1.0 and tries again (https://tools.ietf.org/html/rfc5246#appendix-E.1).
• User B establishes a TLS 1.0 connection to the webserver

** Note: this still happens even if FF is configured:

• Security.tls.version.fallback-limit = 3
• Security.tls.version.max = 4
• Security.tls.version.min = 3

Comment 1

[Dana Keeler (she/her) [:keeler]]

I don't suppose the about:config preference security.tls.insecure_fallback_hosts contains the host in question?

Comment 2

[Lance]

No, the setting only indicates it's a string and does not contain a value.

Comment 3

[Dana Keeler (she/her) [:keeler]]

Can you attach a packet trace of the handshake from user B's perspective?

Comment 4

[Lance]

Attachment: Shows TLS 1.0 connection even though FF min = TLS 1.2

See Packets 164 - 194

Comment 5

[Dana Keeler (she/her) [:keeler]]

Thanks! Unfortunately, without the actual bytes of the packets, I can't tell much from that. Is there any chance you could either attach to this bug or email me those? (Maybe with certificates/hostnames redacted if that's an issue?)
Also, just to check, the preferences you're setting are all in lowercase, right? (preferences are case-sensitive)

Comment 6

[Lance]

Unfortunately I can not provide you with a PCAP containing traffic from my customer's network. The only preferences I changed were to TLS settings listed in the initial bug and all those values are represented by numbers.

Comment 7

[Dana Keeler (she/her) [:keeler]]

The preferences as you listed them in comment 0 all start with a capital S, which means if that's how your customer's Firefox profiles are configured, TLS 1.0 has not been disabled.

Comment 8

[Lance]

Sorry, that's my fault, to be clear, in about:config all the settings are all in lower case.

Comment 9

[Dana Keeler (she/her) [:keeler]]

Did this used to work as expected? If so, can you use https://mozilla.github.io/mozregression/quickstart.html to determine when it stopped working? Thanks!