Re: Thread Safety of ssl_write()
Hi, It is unsafe to access SSL context from 2 different threads. When you call SSL_write function, the SSL context object state is changed. Probably you can end up in case that data is not delivered to the peer. Kris On Tue, 2014-09-30 at 13:46 +, S P, Swaroop (NSN - IN/Bangalore) wrote: Hi, We have a use-case where multiple threads are required to use the same SSL context [created using SSL_new()] and do a ssl_write(). So, there might be a scenario where two threads (or more) can be doing a ssl_write() on the same SSL context at exactly the same time. Is this safe? Is the data delivered properly to the peer? Regards, Swaroop __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Re[2]: Renegotiation workaround for TLS 1.2, 1.1 patch doesn't work (Check-in [22565])
What you could also consider doing is to look at list of cipher suites that you advertise during handshake and try to restrict it a bit. I had same problem with F5 BIG-IP after migration OpenSSL 1.0.0 - 1.0.1k (it seems there was many ciphers added between those to versions which makes). Then I've selected only strong, well-known ciphers that I want to use and since then (half a year) haven't seen any problem in this area. Regards, Kris On 2014-09-02 22:35, Artem Pylypchuk wrote: Yes, I did it (see my original message - it works with SSL_OP_NO_SSLv2 | SSL_OP_NO_TLSv1). I'm not having trouble in getting it to work. But, my server also supports SSLv3. And the problem I described is not in the connection being stuck (I only mentioned it as a related bug), but error messages like OpenSSL error 1: error:0001:lib(0):func(0):reason(1) error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number still being present for such a server when using TLSv1.1 and re-negotiating. They were supposed to get fixed by the patch http://cvs.openssl.org/chngview?cn=22565 Of course, the error messages themselves can be removed by choosing suitable methods and flags (all working combinations listed in original message). Did I pick the wrong list to report this? Cheers. 02.09.2014 23:13, Viktor Dukhovni openssl-us...@dukhovni.org On Tue, Sep 02, 2014 at 10:52:59PM +0300, Artem Pylypchuk wrote: Yes, the stuck connection bug I mentioned is the F5 BigIP needs padding bug or is very similar to it. Sorry for the confusing explanation. To disable TLSv1.2 with the associated ciphers and extensions (which increase the size of the client hello and trigger the padding extension) use SSLv23_client_method() with SSL_OP_NO_TLSv1_2 and if that's not enough also SSL_OP_NO_TLSv1_1. See SSL_set_options(3). -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org -- реклама --- Крутые телефоны! Низкие цены! Покупай тут! http://aukro.ua/?utm_source=i.uautm_medium=advert __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Problem with TLS 1.2 client
Hello, I'm having quite weird problem with openssl (head version). I'm doing following test: Step 1: ./openssl s_client -connect some.server.org:443 -cipher DEFAULT I'm getting following error: CONNECTED(0003) 140453250619072:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: In the tcpdump I see that ClientHello is sent and then server closes connection (FIN, FIN-ACK, ACK) Then I try ./openssl s_client -connect some.server.org:443 -cipher ALL This works perfectly, I get certificate following session details: Protocol : TLSv1.2 Cipher: DHE-RSA-AES256-GCM-SHA384 As you can see above, server accepts cipher DHE-RSA-AES256-GCM-SHA384. But when I try to specify this cipher on command line: ./openssl s_client -connect some.server.org:443 -cipher DHE-RSA-AES256-GCM-SHA384 ... again remote server closes remote connection. Unfortunately I don't know what kind of software is running on server side and it seems like problem is there. I've tried to reproduce such problem with few old versions of openssl but with no success. Also I've checked gnutls-cli and it works OK. Does anybody has any guess what could potentially cause this problem? PS: my version of openssl s_client has patch for PR#2771 (the one committed today) Kris __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: ssl handshake failure in 1.0.1 but not 1.0.0
Do you still see an error if you specify one cipher? f.e. AES256-SHA? On 2013-11-07 22:26, Dave Thompson wrote: From: owner-openssl-users On Behalf Of Viktor Dukhovni Sent: Thursday, November 07, 2013 11:02 On Thu, Nov 07, 2013 at 12:29:13PM +, Ben Arnold wrote: I am using SSL_CTX_set_client_cert_cb to provide the client certificate when needed. I have a problem in that OpenSSL 1.0.1e does not trigger this callback for all websites that I expect it to, only some. Instead on the failing sites there is an SSL handshake failure after the client verifies the server certificate: You can test with s_client(1) and compare results. Is your client certificate an RSA certificate? How many bits of public key? Is its signature SHA1 or SHA256? OP's log shows protocol hasn't reached the CertReq - ClientCert steps so at this point nothing about the client cert should matter. (And in any case the signature *on* the cert is by the CA key, unless it's self signed, in which case using it for client-auth would be really silly. From the log, unless OP fixed it, the server cert looks like a DIY CA, and if someone does that for the server I would expect it for clients also.) To OP: is the logged server cert info true? I note the log shows the client verification of the server failed; did this website give you a custom root to trust and did you simply not set that up (or perhaps not in the environment you're testing in)? SSL read: error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure, errno 0 Interestingly if I compile against 1.0.0k then there is no failure and the callback *is* triggered for all sites (that I have tried so far anyway). Sounds like a problem with TLSv1.2. If your client certificate is only 512-bits it may not be wide enough to sign a SHA384 digest, or some other TLSv1.2 parameter issue. Client hasn't even selected the cert yet. And although I agree a PCAP is better in general than a less-complete program log, just looking at the headers in the log you can see the client offered TLSv1.2 (0303) but the server only accepted TLSv1 (0301) so there definitely isn't any SHA-2 issue. But something else related to TLSv1.2 does seem likely. Possibly the new larger size (as OP observed), or the new extensions, although the initial negotiation apparently worked fine with both. Attaching a PCAP file of the traffic is much more useful than hex packet dumps. Capture the traffic with tcpdump -s0 -w file ... and look with wireshark -r file. If you don't understand the wireshark output, post the (binary) PCAP file containing just one failed TLS handshake, perhaps also a PCAP file with a succesful TLS handshake. I do notice the second ClientHello -- in response to server request -- using 1.0.1 re-offers TLSv1.2. I thought it was good practice when we know the server has previously rejected something not to re-offer it, but I don't recall where I saw this and I might well be wrong. Even so the server should negotiate down (as it did initially) or at minimum send an alert, not just close. To OP: If you can try to reproduce with s_client default (which is TLSv1.2 or less) and again specifying -tls1 (or -no_tls1_2 -no_tls1_1). That might narrow it down pretty close. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Interleaving SSL_write() and SSL_read()
Hi, I'm a bit confused about usage of SSL_write()/SSL_read() in non-blocking connectors. Let say I do SSL_write() and I get SSL_ERROR_WANT_WRITE. It means I have to do SSL_write() again. But does it mean that I can't do SSL_read() until SSL_write() returns with success? Any idea? Kris __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Allowing fullduplex in SSL
Hello, I've legacy application which handles full-duplex connections - many threads writing and reading from/to the same socket at the same time. Now I need to implement SSL communication over those sockets. According to this http://rt.openssl.org/Ticket/Display.html?id=2481user=guestpass=guest I understand that OpenSSL doesn't support full-duplex connections because session key renegotiation can be triggered at any time There are some questions I'm looking an answer to and I would appreciate any help provided - is renegotiation the only cause of OpenSSL being not able to handle full-duplex connections? - is it possible to disable session renegotiation, which would than enable possibility of implementing fullduplexed connections? I understand it is neither secure nor compliant with SSL protocol, but let say that I'm in some internal environment where I can assume that renegotiation will never be requested by any clientserver. Best regards, Kris __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Release policy
Hello, I want to use OpenSSL in one of my project. As the project will run on production servers I'm wondering which branch should I use. Could you tell me what's the difference between OpenSSL 1.0.0 and 1.0.1 ? I'm guessing that 1.0.1 contains some experimental code, so is less suitable for production, but need to confirm my guessing. Regards, Krzysztof Kwiatkowski C++ Software Engineer, Service Integrator image/gif
