Re: Problem with cipher suite ECDHE-ECDSA-AES256-SHA384

Just discovered the culprit. I had configured the server using TLSv1_server_method(), going from and assuming TLSv1 encompasses v1.{1,2}. Stumbled on this by chance by experimenting with forcing TLSv1.2 (of which the desired cipher suite is a part)

Re: Problem with cipher suite ECDHE-ECDSA-AES256-SHA384

On Fri, Nov 09, 2012, Karel Sedl??ek wrote: > I was using secp521r1, but secp384r1 has the same behavior. Here is > the output with -state: > > SSL_connect:error in SSLv2/v3 read server hello A > 140735101956572:error:14077410:SSL > routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake > failure:

Re: Problem with cipher suite ECDHE-ECDSA-AES256-SHA384

I was using secp521r1, but secp384r1 has the same behavior. Here is the output with -state: CONNECTED(0003) SSL_connect:before/connect initialization write to 0x7fe008426dd0 [0x7fe008810800] (165 bytes => 165 (0xA5)) - 16 03 01 00 a0 01 00 00-9c 03 03 50 9d 3f 85 bf ...P.?.. 001

Re: Problem with cipher suite ECDHE-ECDSA-AES256-SHA384

On Fri, Nov 09, 2012, Karel Sedl??ek wrote: > I have; following is the relevant snippet: > > int nid = OBJ_sn2nid(ECDHE_CURVE); > if (NID_undef == nid) > goto err_obj_sn2nid; > > EC_KEY *ecdh = EC_KEY_new_by_curve_name(nid); > if (NULL == ecdh) > goto err_ec_key_new; > > SSL_C

Re: Problem with cipher suite ECDHE-ECDSA-AES256-SHA384

I have; following is the relevant snippet: int nid = OBJ_sn2nid(ECDHE_CURVE); if (NID_undef == nid) goto err_obj_sn2nid; EC_KEY *ecdh = EC_KEY_new_by_curve_name(nid); if (NULL == ecdh) goto err_ec_key_new; SSL_CTX_set_tmp_ecdh(tls_ctx, ecdh); On Fri, Nov 9, 2012 at 5:32 PM, Dr

Re: Problem with cipher suite ECDHE-ECDSA-AES256-SHA384

On Fri, Nov 09, 2012, Karel Sedl??ek wrote: > This problem is related to an issue I have been experiencing with a > piece of bespoke software I am writing that uses OpenSSL to terminate > SSL/TLS connections, using non-blocking I/O. > > Observations: > - My server's TLS handshake for cipher ECDHE

Problem with cipher suite ECDHE-ECDSA-AES256-SHA384

This problem is related to an issue I have been experiencing with a piece of bespoke software I am writing that uses OpenSSL to terminate SSL/TLS connections, using non-blocking I/O. Observations: - My server's TLS handshake for cipher ECDHE-ECDSA-AES256-GCM-SHA384 fails. - If I use ALL for my ser

Re: Use OpenSSL socket as a normal socket

Ok, I understand your point now. But it sounds strange to me accepting on the same port incoming SSL protected data and native TCP unprotected socket... I am curious what other can tell about that. Le 09/11/2012 14:19, Derek Cole a écrit : Well that would still require an SSL handshake right?

Re: Use OpenSSL socket as a normal socket

I'd say you're doing it the right way now; traditionally services that want to support SSL/TLS and not on the same port use the STARTTLS methodology, starting with a plain connection. Since you can't modify your client, you're stuck buffering a bit of data at the beginning to sniff it it looks like

Re: Use OpenSSL socket as a normal socket

Well that would still require an SSL handshake right? My client that sends the unencrypted traffic knows nothing of SSL at all, and I can't modify it, so it is just coming in a normal TCP stream. On Fri, Nov 9, 2012 at 6:44 AM, Michel wrote: > Hi, > > Perhaps I misunderstand you, but wouldn't i

Re: Use OpenSSL socket as a normal socket

Hi, Perhaps I misunderstand you, but wouldn't it be easier to just choose eNULL cipher when no encryption is needed ? Le 09/11/2012 06:08, Derek Cole a écrit : Hello, I have a server running that I am accepting both SSL and non SSL traffic. Currently I check the traffic first and if the firs