bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Firefox 37 uses DTLS 1.2 client, breaking any WebRTC implementations using DTLS 1.0.

RESOLVED WORKSFORME

Status

()

Core
WebRTC
RESOLVED WORKSFORME
3 years ago
3 years ago

People

(Reporter: Anton Venema, Unassigned, NeedInfo)

Tracking

37 Branch
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36

Steps to reproduce:

Perform a DTLS handshake from Firefox to a third-party WebRTC library (i.e. www.frozenmountain.com/icelink) that uses DTLS 1.0. Ensure Firefox takes on the active/client role.


Actual results:

If Firefox is in the passive/server role in the handshake, everything works fine (i.e. a DTLS 1.0 client can connect to a DTLS 1.2 server)

If Firefox is in the active/client role, the handshake fails (i.e. a DTLS 1.2 client cannot connect to a DTLS 1.0 server).


Expected results:

In the client role, Firefox should behave as a DTLS 1.0 client to allow connectivity with DTLS 1.0 peers. At the very least, this behaviour should be stubbed in for a period of time to prevent breakage.

Comment 1

3 years ago
I see DTLS not working any more with out WebRTC Gateway when Firefox (38 beta) is in active role as well.

Is there a workaround until we upgrade out gateway to support DTLS 1.2, which might not be too soon?

Comment 2

3 years ago
It's not a bug in Firefox. It's a bug in the remote DTLS endpoint, that doesn't implement the negotiation of the protocol version correctly. I just had the same problem against my DTLS implementation and had to fix it.

It is supposed to work like that: The client gives the highest supported version in the ClientHello (DTLS 1.2, like Firefox does). The server picks a protocol version that is less or equal and sends it in the ServerHello (DTLS 1.0). This negotiated version is then used by both the client and the server.

So the WebRTC gateway doen't need to be upgraded to TLS 1.2. It just needs to negotiate TLS 1.0, instead of rejecting the session.

Comment 3

3 years ago
OK, thanks for info.  We are using openssl 1.0.1g currently, and perhaps this version is not doing this correctly.

Updated

3 years ago
Component: Untriaged → WebRTC
Product: Firefox → Core
This was in the wrong component.  Can you (either of you) verify if you've resolved your problem? (Or rather has comment 2 helped you fix it?)  Thanks
Flags: needinfo?(ushunmugan)
Flags: needinfo?(anton.venema)

Comment 5

3 years ago
No, I haven't had a chance to resolve this yet, though I'd need to work on this soon.

Just to reiterate the problem - if the gateway takes on the active role, then the DTLS negotiation works fine, but not when Firefox is in active role.  Our platform uses openssl version 1.0.1g for DTLS implementation.  When I looked into this before, I couldn't find any fix in openssl for this. Any suggestions as to how this could be resolved would be appreciated.
Flags: needinfo?(ushunmugan)

Comment 6

3 years ago
Are you sure that this is a DTLS negotiation issue and not this issue:
https://hacks.mozilla.org/2015/02/webrtc-requires-perfect-forward-secrecy-pfs-starting-in-firefox-38/

IIRC that also exhibits this asymmetry.

Comment 7

3 years ago
It was, indeed - thanks! 

For those interested, based on the discussions in https://bugzilla.mozilla.org/show_bug.cgi?id=1052610, and https://code.google.com/p/chromium/issues/detail?id=406458, I tried the following (with error checks) in the gateway code, and now the gateway in server mode could establish DTLS with Firefox 41 beta.
  EC_KEY *eckey = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
  SSL_CTX_set_tmp_ecdh(sslCtx, eckey);
Thanks for digging in, and thanks to ekr for pointing out the likely cause
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME

Comment 9

3 years ago
Thanks.  I have a question on the article pointed out by ekr, though.  When the bug https://bugzilla.mozilla.org/show_bug.cgi?id=102794 is resolved, would I need to change the gateway code to add DHE ciphers also?
You need to log in before you can comment on or make changes to this bug.