936850 - TLS version fallback needs to be smarter about captive portals

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

1. When we detect TLS intolerance according to our existing heuristics, we need to try captive portal detection before trying to fall back.

2. Captive portals shouldn't cause us to keep on using degraded TLS after we've dealt with the captive portal. We should reset the TLS intolerance state after we've detected we've cleared the captive portal.

3. SSL_ERROR_RX_RECORD_TOO_LONG should trigger captive portal detection, but not version fallback. When a server responds to a TLS ClientHello with a plaintext HTTP response (instead of a SSL/TLS ServerHello), that will usually cause an SSL_ERROR_RX_RECORD_TOO_LONG error: "HTTP/1.1" at the start of the HTTP status line is : 0x48 0x54 0x54 0x50 0x2f 0x31 0x2e 0x31. In TLS, this is parsed as a record header:

Version 0x4854 (a version that will never exist)
Record Type 0x54 (invalid record type)
Record Length 0x502f (20,527)

Since the maximum record length is 16,384 (2^14) and libssl checks the record length before it checks the record type or version, libssl complains about the record length being too large.

Comment 1

[Jesse Ruderman]

Bug 445098 covers distinguishing "HTTP served on HTTPS port" in the UI. Having that case be distinguished might help here too.

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

No more version intolerance fallback -> INVALID.