1781075 - Firefox does not correctly use ALPN data from HTTPS RR records

Status: RESOLVED FIXED

(Core :: Networking: DNS, defect, P1)

Description

[Dennis Jackson]

draft-ietf-dnsop-svcb-https-10 specifies how the ALPN protocols should be set in section 7.1.2:

To establish a connection to the endpoint, clients MUST

1. Let SVCB-ALPN-Intersection be the set of protocols in the SVCB
   ALPN set that the client supports.

2. Let Intersection-Transports be the set of transports (e.g. TLS,
   DTLS, QUIC) implied by the protocols in SVCB-ALPN-Intersection.

3. For each transport in Intersection-Transports, construct a
   ProtocolNameList containing the Identification Sequences of all
   the client's supported ALPN protocols for that transport, without
   regard to the SVCB ALPN set.

For example, if the SVCB ALPN set is ["http/1.1", "h3"], and the
client supports HTTP/1.1, HTTP/2, and HTTP/3, the client could
attempt to connect using TLS over TCP with a ProtocolNameList of
["http/1.1", "h2"], and could also attempt a connection using QUIC,
with a ProtocolNameList of ["h3"].

When Firefox is making a TLS connection without a HTTPS RR it sets ALPN list (code) to include http/1.1 and also h2 if enabled and not excluded for this connection.

However, If a HTTPS RR is available, then Firefox uses its own logic to select the best single ALPN value and send that (see GetServiceModeRecordInternal and GetAllRecordsWithEchConfigInternal).

The correct behaviour is for Firefox to include the ALPN entries for any protocol it is willing to negotiate on that transport.

Comment 1

[Dennis Jackson]

Attachment: Bug 1781075: Always offer http/1.1 in ALPN extension for TLS over TCP. r=dragana.

This change ensures that when Firefox is connecting over TCP, its ALPN extension always includes
http/1.1 and (if suitable) h2. Previously Firefox was overly restrictive and only included a
single ALPN value if the connection was informed by a HTTPS DNS resource record.

Comment 2

[Dennis Jackson]

Attachment: Bug 1781075 - Add test cases for ECH connections with incorrect ALPN advertisements. r=dragana

These tests set up an ECH server which will only negotiate http/1.1 in the TLS ALPN extension.
If the client doesn't send an ALPN offering at least http/1.1 the connection will fail with
SSL_ERROR_NEXT_PROTOCOL_NO_PROTOCOL.

Depends on D153367

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f0c3bba6383d
Always offer http/1.1 in ALPN extension for TLS over TCP. r=necko-reviewers,kershaw.
https://hg.mozilla.org/integration/autoland/rev/8badf082001c
Add test cases for ECH connections with incorrect ALPN advertisements. r=necko-reviewers,kershaw

Comment 4

[Cristina Cozmuta (:CrissCozmuta)]

https://hg.mozilla.org/mozilla-central/rev/f0c3bba6383d
https://hg.mozilla.org/mozilla-central/rev/8badf082001c