New to the list and one question ;-)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

New to the list and one question ;-)

OpenSSL - User mailing list
Hello all, 

Hello all, 

Presently writing a server/relay dealing with an h264 stream.

one of the threads' job is to establish a handshake with the browser requesting the stream in order to feed the libsrtp2 with keys and salts and start encrypting the h264 stream towards the browser.

all is well and good when the program works on the linux PC and the handshake is succesful using the 0xc02f cipher. and that is linked to version 3.0.0 of openssl.

on the embedded version, (linked with version  1.0.2s)  firefox fails the handshake with ssl_no_shared_cipher whereas chrome and safari do successfully handshake

chrome client hello contains 12 ciphers and the server hello seems to choose 0xc02f cipher

firefox client hello contains only 10 ciphers (including the above mentioned 0xc02f cipher) and fails.

any suggestion as to what could causes that failure would be appreciated.

Thanks





Reply | Threaded
Open this post in threaded view
|

Re: New to the list and one question ;-)

Viktor Dukhovni
On Mon, Jun 10, 2019 at 03:21:16PM +0000, Patrick Regnouf via openssl-users wrote:

> All is well and good when the program works on the linux PC and the
> handshake is succesful using the 0xc02f cipher. and that is linked to
> version 3.0.0 of openssl.  on the embedded version, (linked with version
> 1.0.2s) firefox fails the handshake with ssl_no_shared_cipher whereas
> chrome and safari do successfully handshake chrome client hello contains
> 12 ciphers and the server hello seems to choose 0xc02f cipher firefox
> client hello contains only 10 ciphers (including the above mentioned 0xc02f
> cipher) and fails.  any suggestion as to what could causes that failure
> would be appreciated.

In addition to the cipher algorithm, the two parties must also agree
on the signature algorithms, supported EC groups, ...

You've not provided much detail about the configuration of the
embedded (1.0.2s) server.  The cipher that works with the other
browsers is:

    0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD

this requires a shared ECDHE curve, are you using "auto", or an
explicit curve?  What are the signature algorithms on your certificate
chain?

It would also be useful to post PCAP files of a working handshake
with Chrome, and a failing handshake with Firefox.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: New to the list and one question ;-)

OpenSSL - User mailing list
In reply to this post by OpenSSL - User mailing list
As requested here are two captures attached: one successfully handshakes with the server (chrome)  and one fails the handshake (firefox).
I would be very grateful if anyone could shed some light on this.

the openssl version which is linked to my server/relay program is 1.0.2s

Thanks

/Patrick




On Mon, 2019-06-10 at 13:41 -0400, Viktor Dukhovni wrote:
On Mon, Jun 10, 2019 at 03:21:16PM +0000, Patrick Regnouf via openssl-users wrote:

>
> > All is well and good when the program works on the linux PC and the
> > handshake is succesful using the 0xc02f cipher. and that is linked to
> > version 3.0.0 of openssl.  on the embedded version, (linked with version
> > 1.0.2s) firefox fails the handshake with ssl_no_shared_cipher whereas
> > chrome and safari do successfully handshake chrome client hello contains
> > 12 ciphers and the server hello seems to choose 0xc02f cipher firefox
> > client hello contains only 10 ciphers (including the above mentioned 0xc02f
> > cipher) and fails.  any suggestion as to what could causes that failure
> > would be appreciated.
>
> In addition to the cipher algorithm, the two parties must also agree
> on the signature algorithms, supported EC groups, ...
>
> You've not provided much detail about the configuration of the
> embedded (1.0.2s) server.  The cipher that works with the other
> browsers is:
>
>     0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
>
> this requires a shared ECDHE curve, are you using "auto", or an
> explicit curve?  What are the signature algorithms on your certificate
> chain?
>
> It would also be useful to post PCAP files of a working handshake
> with Chrome, and a failing handshake with Firefox.

=?UTF-8?b?Y2hyb21lX3N1Y2Nlc3MucGNhcA==?= (5K) Download Attachment
=?UTF-8?b?ZmlyZWZveF9mYWlsLnBjYXA=?= (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New to the list and one question ;-)

Matt Caswell-2


On 12/06/2019 10:27, Patrick Regnouf via openssl-users wrote:
> As requested here are two captures attached: one successfully handshakes with
> the server (chrome)  and one fails the handshake (firefox).
> I would be very grateful if anyone could shed some light on this.
>
> the openssl version which is linked to my server/relay program is 1.0.2s

Contrary to what you said in your original post the chrome session is NOT
selecting 0xc02f. Instead it is selecting 0x002f which is
TLS_RSA_WITH_AES_128_CBC_SHA (aka AES128-SHA in the OpenSSL naming scheme).

This cipher is not being offered by firefox but is by chrome. It is striking to
note that although chrome is offering a whole list of ciphersuites offering
forward secrecy (i.e. all those including ECDHE/DHE), the server is instead
selecting a very old ciphersuite that does not support forward secrecy.

In comparison firefox does not offer any ciphersuites that do not support
forward secrecy and the connection fails.

Have you called SSL_CTX_set_tmp_dh() or SSL_CTX_set_ecdh_auto() on the server?
I'd suggest trying those and see if it helps.

Matt


>
> Thanks
>
> /Patrick
>
>
>
>
> On Mon, 2019-06-10 at 13:41 -0400, Viktor Dukhovni wrote:
> On Mon, Jun 10, 2019 at 03:21:16PM +0000, Patrick Regnouf via openssl-users wrote:
>>
>> > All is well and good when the program works on the linux PC and the
>> > handshake is succesful using the 0xc02f cipher. and that is linked to
>> > version 3.0.0 of openssl.  on the embedded version, (linked with version
>> > 1.0.2s) firefox fails the handshake with ssl_no_shared_cipher whereas
>> > chrome and safari do successfully handshake chrome client hello contains
>> > 12 ciphers and the server hello seems to choose 0xc02f cipher firefox
>> > client hello contains only 10 ciphers (including the above mentioned 0xc02f
>> > cipher) and fails.  any suggestion as to what could causes that failure
>> > would be appreciated.
>>
>> In addition to the cipher algorithm, the two parties must also agree
>> on the signature algorithms, supported EC groups, ...
>>
>> You've not provided much detail about the configuration of the
>> embedded (1.0.2s) server.  The cipher that works with the other
>> browsers is:
>>
>>     0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA 
> Enc=AESGCM(128) Mac=AEAD
>>
>> this requires a shared ECDHE curve, are you using "auto", or an
>> explicit curve?  What are the signature algorithms on your certificate
>> chain?
>>
>> It would also be useful to post PCAP files of a working handshake
>> with Chrome, and a failing handshake with Firefox.
>
Reply | Threaded
Open this post in threaded view
|

Re: New to the list and one question ;-)

OpenSSL - User mailing list
In reply to this post by OpenSSL - User mailing list
Thanks Matt, adding a call to SSL_CTX_set_ecdh_auto()  on the server side actually did the trick. Problem solved!!!

/Patrick 




Contrary to what you said in your original post the chrome session is NOT
selecting 0xc02f. Instead it is selecting 0x002f which is
TLS_RSA_WITH_AES_128_CBC_SHA (aka AES128-SHA in the OpenSSL naming scheme).

This cipher is not being offered by firefox but is by chrome. It is striking to
note that although chrome is offering a whole list of ciphersuites offering
forward secrecy (i.e. all those including ECDHE/DHE), the server is instead
selecting a very old ciphersuite that does not support forward secrecy.

In comparison firefox does not offer any ciphersuites that do not support
forward secrecy and the connection fails.

Have you called SSL_CTX_set_tmp_dh() or SSL_CTX_set_ecdh_auto() on the server?
I'd suggest trying those and see if it helps.

Matt


Sent from Yahoo Mail for iPhone