On Thursday, 2 February 2017 01:54:23 UTC+5:30, [email protected] wrote: > Hi Prerak, > > Thank you much for the info. When I made the client create an RSA P-256 > certificate and use it in PeerConnection (in fact, this is required with > Chrome 52 and later, when using OpenSSL 1.0.1g, for e.g.), it still didn't > work, but the cipher suite used was the same as in the working case. > However, I could see that the ECDH named curve used in Server Key Exchange > was ecdh_x25519 (0x001d) - as you have noted, compared to secp256r1 (0x0017) > in the working case. I also don't see any named curves specified in Client > Hello. Note that secp256r1 is one of the curves supported by Firefox, > according to the code diff you've pointed out. Also note that DTLS works > fine when Firefox receives a call, and acts as a client. > > It looks like that SSL_CTL_set1_curves() is only available from OpenSSL > 1.0.2. FYI, we are already using > EC_KEY_new_by_curve_name(NID_X9_62_prime256v1), followed by > SSL_CTX_set_tmp_ecdh() to set the curve name - this was required a while ago > after Firefox made some changes on this regard. Other than updating OpenSSL, > is there any other way to have the supported named curves listed in the > Client Hello? > > Thank, > Uma
I was using the same openssl API you mentioned EC_KEY_new_by_curve_name(NID_X9_62_prime256v1), it works only in case when your server is acting as DTLS server thats why it works when Firefox acts as the DTLS client. This API doesn't add named_curve field in Client Hello message, so had to upgrade openssl to 1.0.2 to unblock WebRTC Firefox calls. So either you can wait for the fix Martin has mentioned or upgrade openssl to at least 1.0.2. _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
