Closed Bug 1520094 Opened Last year Closed Last year

WebRTC Data Channel fails to connect during SSL negotiation


(Core :: WebRTC: Networking, defect)

64 Branch
Not set



Tracking Status
firefox65 --- fixed
firefox66 --- fixed


(Reporter: scottjmaddox, Unassigned)




(Keywords: regression)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

Navigate to on Firefox 64.0.2 (64-bit).

Actual results:

ICE-lite negotiation completes successfully, as evidenced by about:webrtc, but the channel fails to open.

In my own, alternate minimal implementation of an ICE-lite WebRTC Data Channel server, I see the connection fail during SSL negotiation; SSL_read eventually returns SSL_ERROR_ZERO_RETURN, signifying that the remote end (Firefox) closed the SSL connection.

Expected results:

Compare the results to Chrome or Safari, or an older Firefox build to see how it should behave. Essentially, the data channel should open once the ICE-lite negotiation completes, and there should be data exchange.

(In reply to scottjmaddox from comment #0)

Compare the results to Chrome or Safari, or an older Firefox build to see how it should behave.

It would be very helpful if you could track down the exact regression range.

Has Regression Range: --- → no
Component: Untriaged → WebRTC: Networking
Product: Firefox → Core

3:15.11 INFO: No more inbound revisions, bisection finished.
3:15.11 INFO: Last good revision: 709a197ccc2e5959d14df8e049ce60da3c727f5a
3:15.11 INFO: First bad revision: 2f345fa70dc0556eff561511bd61be23f366113b
3:15.11 INFO: Pushlog:

Blocks: 1485883
Ever confirmed: true
Flags: needinfo?(martin.thomson)
Has Regression Range: no → yes

Correction: when trying to use Firefox to connect to my own server implementation, I see the DTLS handshake complete successfully, but then Firefox immediately closes the connection before sending the first encrypted SCTP packet.

I cannot, for the life of me, figure out how to get wireshark to decrypt the DTLS packets (I've tried providing the session ID and master key, as well as providing the server's private key, but neither appear to work, and the debug log is impenetrable---anyways, that's a separate issue), so I can't tell you what the DTLS error is, but I can tell you that Firefox appears to respond to the server's last "Change Cipher Spec, Encrypted Handshake Message" packet with an "Encrypted Alert" packet.

If there's any other troubleshooting I can do to help, let me know!

This is just a guess, but could Firefox be assuming any WebRTC Peer Connection must negotiate DTLS-SRTP, and when that doesn't happen it closes the connection? My understanding from the WebRTC Data Channel spec is that a data channel can be opened over DTLS/SCTP without a DTLS-SRTP connection being negotiated.

Yes, this is the problem. We even have a fix prepared.

Closed: Last year
Flags: needinfo?(martin.thomson)
Resolution: --- → DUPLICATE
Duplicate of bug: 1510487
You need to log in before you can comment on or make changes to this bug.