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
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
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,
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.?..
Just discovered the culprit. I had configured the server using
TLSv1_server_method(), going from
http://www.openssl.org/docs/ssl/SSL_CTX_new.html 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)
It would be nice to have these in the same way as
SSL_CTX_set_default_passwd_cb_userdata.
k
__
OpenSSL Project http://www.openssl.org
User Support Mailing List
You don't need to change OpenSSL; TLSv1_2_server_method() replaces
SSLv23_server_method() in your own code.
k
On Fri, Jun 7, 2013 at 10:17 AM, mehroz mehroz.ashra...@gmail.com wrote:
Hi,
Could you help where do i need to change the method from
TLSv1_2_server_method() to
