Closed Bug 1615208 Opened 4 years ago Closed 4 years ago

Firefox Nightly/Chrome interop issue due to DTLS 1.3


(NSS :: Libraries, defect, P1)



(Not tracked)



(Reporter: philipp.hancke, Assigned: kjacobs)



(3 files)

Attached file handshake.pcapng

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

originally noticed by our (whereby) CI servers but since is still the most vendor-neutral STR:

  1. join apprtc room in chrome (stable or canary), have webrtc-internals open
  2. join same room in Firefox Nightly (75.0a1)

Actual results:

It fails. In chrome's webrtc-internals the iceconnectionstate changes to connected but the connection state goes to failed which suggests a DTLS failure.

Firefox just enabled DTLS 1.3 and probably Chrome/ does not handle the supported version in the handshake and responds with an error. See the attached pcap. I suspect the problem is in the "supported versions" which lists 0x7f1e, 0x303 (TLS 1.2) and 0x302 (TLS 1.1). It should have 0x304 for DTLS 1.3 according to no?

Expected results:

bidirectional video

Flags: needinfo?(drno)

setting media.peerconnection.dtls.version.max to 771 (DTLS 1.2) fixes it. What is 0x7f1e even?!

Component: Untriaged → WebRTC: Networking
Ever confirmed: true
Flags: needinfo?(drno)
Product: Firefox → Core
Target Milestone: --- → mozilla75

This only happens with Chrome first, Firefox second. But works fine the other way around.

dump from
-- still works but Wireshark doesn't like the DTLS handshake at all there.

0x7f1e is the draft version indicator (see here). I haven't found a Wireshark bug tracking their level of DTLS 1.3 support, but it's not entirely surprising that it may not comprehend DTLS1.3 - encrypted messages are indicated in a totally different way as of draft-27.

Under manual inspection, the garbled pcap looks well-formed, but it does appear that we may have an issue negotiating lower versions after offering 1.3. I'm continuing to look into this.

that sounds like Chrome/boringssl isn't very forward compatible and does not ignore that. Maybe we should file a bug there (or in webrtc and let them shuffle it around)?

Priority: -- → P1

I see what's going on here. As you suggest, when Firefox constructs the supported_versions extension for the DTLS1.3 CH, the alternate versions (DTLS 1.2 and 1.0) do not have their encodings converted for DTLS. I.e., we advertise {0x7f1e, 0x0303, 0x0302} when we should instead advertise {0x7f1e, 0xfefd, 0xfeff}. BoringSSL doesn't find any known DTLS versions in the first list, and alerts. I've confirmed the handshake works as expected with this change.

Moving this bug into NSS.

Assignee: nobody → kjacobs.bugzilla
Component: WebRTC: Networking → Libraries
Product: Core → NSS
QA Contact: jjones
Target Milestone: mozilla75 → 3.51
Version: 75 Branch → trunk

This patch modifies supported_versions encodings to reflect DTLS versions when DTLS1.3 is use. Previously, a DTLS1.3 CH would include [0x7f1e, 0x303, 0x302] instead of the expected [0x7f1e, 0xfefd, 0xfeff], causing compatibility issues.

Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.