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

Status: RESOLVED WORKSFORME

(Core :: WebRTC, defect)

Description

[Anton Venema]

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

[ushunmugan]

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

[Matthias Schertler]

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

[ushunmugan]

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

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 5

[ushunmugan]

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.

Comment 6

[Eric Rescorla (:ekr)]

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

[ushunmugan]

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);

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

Thanks for digging in, and thanks to ekr for pointing out the likely cause

Comment 9

[ushunmugan]

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?