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
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
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, Jun 10, 2019 at 03:21:16PM +, 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
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
