Re: [External] Re: SSL_connect() failing on SSL3_MT_NEWSESSION_TICKET on Raspberry Pi
On 23/03/2022 18:08, Helde, Paavo wrote: Great! That does suggest an unknown bug exists in master though... If you can manage it would be useful for us if you tried the latest master version of OpenSSL with the "no-asm" config option. My guess is new assembler code might be the cause of this. If turning off assembler resolves the issue then that would confirm my guess. You are right, I ran through the builds and it appears indeed no-asm fixes the problem with the current github master on raspberry pi (aarch64, little-endian). Let me know if you need any more info! Thanks for this. I have raised this issue to track the problem: https://github.com/openssl/openssl/issues/17958 Matt
RE: [External] Re: SSL_connect() failing on SSL3_MT_NEWSESSION_TICKET on Raspberry Pi
> Great! That does suggest an unknown bug exists in master though... > >If you can manage it would be useful for us if you tried the latest master >version of OpenSSL with the "no-asm" config option. My guess is new assembler >code might be the cause of this. If turning off assembler resolves the issue >then that would confirm my guess. You are right, I ran through the builds and it appears indeed no-asm fixes the problem with the current github master on raspberry pi (aarch64, little-endian). Let me know if you need any more info! Paavo
Re: [External] Re: SSL_connect() failing on SSL3_MT_NEWSESSION_TICKET on Raspberry Pi
On 23/03/2022 14:00, Helde, Paavo wrote: - I notice that you are using the latest master version 3.1.0-dev. The master branch is where all dev work goes on and consequently may be unstable. You might be better off using the latest 3.0 stable version, i.e. 3.0.2 Thanks Matt, downgrading to 3.0.2 indeed did the trick, now everything is working fine! It appears indeed I had accidentally used the latest dev version from github, usually I try to go with last stable instead. Great! That does suggest an unknown bug exists in master though... If you can manage it would be useful for us if you tried the latest master version of OpenSSL with the "no-asm" config option. My guess is new assembler code might be the cause of this. If turning off assembler resolves the issue then that would confirm my guess. Matt
RE: [External] Re: SSL_connect() failing on SSL3_MT_NEWSESSION_TICKET on Raspberry Pi
> Some things you could try: > - Do you have an alternative compiler you could use? If its a compiler bug > then swapping to a different compiler might resolve it Compiler is regular gcc 10.2.1. > - I notice that you are using the latest master version 3.1.0-dev. The master > branch is where all dev work goes on and consequently may be unstable. You > might be better off using the latest 3.0 stable version, i.e. 3.0.2 Thanks Matt, downgrading to 3.0.2 indeed did the trick, now everything is working fine! It appears indeed I had accidentally used the latest dev version from github, usually I try to go with last stable instead. Best regards Paavo
Re: [External] Re: SSL_connect() failing on SSL3_MT_NEWSESSION_TICKET on Raspberry Pi
On 23/03/2022 12:39, Helde, Paavo via openssl-users wrote: It would be interesting to see what output you get from s_client when you use the "-trace" argument. Also, is this TLSv1.3 specific? If you add the argument "-no_tls1_3" to s_client does it start working? Thanks for looking into this! I paste the outputs here. With -no_tls1_3 it goes further, but there is another error in the end. The error you see with "-no_tls1_3" is: 40E0A6A87F00:error:0A000126:SSL routines:ssl3_read_n:unexpected eof while reading:ssl/record/rec_layer_s3.c:308: This is actually normally behaviour with the google server. What is happening is that you are succesfully creating a connection and the google server is waiting for you to send it an HTTP request. After a short while, having not received one, the server is aborting the connection abruptly, i.e. it's doing a non-clean shutdown without sending a close_notify alert. This results in the "unexpected eof" message. So TLSv1.2 appears to be working correctly. Received Record Header: Version = TLS 1.2 (0x303) Content Type = ApplicationData (23) Length = 4156 Inner Content Type = Handshake (22) This is actually interesting. If I do the same thing from my machine what I see at this point in the communication is this: Received Record Header: Version = TLS 1.2 (0x303) Content Type = ApplicationData (23) Length = 4156 Inner Content Type = Handshake (22) EncryptedExtensions, Length=2 No extensions Certificate, Length=3998 context (len=0): certificate_list, length=3994 ASN.1Cert, length=1163 --details- Certificate: Data: Version: 3 (0x2) Serial Number: 8d:0d:f9:1d:bc:de:87:69:12:00:00:00:00:05:a8:0f Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = Google Trust Services LLC, CN = GTS CA 1C3 Validity Not Before: Mar 17 11:49:13 2022 GMT Not After : Jun 9 11:49:12 2022 GMT Subject: CN = www.google.com ...snip... So we both receive a TLSv1.3 record of length 4156. For me this contains the EncryptedExtensions, Certificate, CertificateVerify and Finished messages. Given that the length is identical for you this suggests to me that this is also what you are intended to receive. Something somewhere has corrupted the contents. Possible causes that spring to mind: - OpenSSL bug - Compiler bug Some things you could try: - Do you have an alternative compiler you could use? If its a compiler bug then swapping to a different compiler might resolve it - I notice that you are using the latest master version 3.1.0-dev. The master branch is where all dev work goes on and consequently may be unstable. You might be better off using the latest 3.0 stable version, i.e. 3.0.2 Matt
RE: [External] Re: SSL_connect() failing on SSL3_MT_NEWSESSION_TICKET on Raspberry Pi
n: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher: ECDHE-ECDSA-CHACHA20-POLY1305
Session-ID: E352271D58FE8A55E15D2203A2961B488E83D3A9B1B2A2D04CCC59ADF1154D1F
Session-ID-ctx:
Master-Key:
86BA2A3C64BA60572597C57E7ABBECB96158B54E4B2BC7D507C5DE1803A88080147B77B584AA0393C80F12BDA4E561C2
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
- 01 22 f3 90 27 e0 7b 22-14 13 b4 43 ad 16 02 55 ."..'.{"...C...U
0010 - 2d f5 b2 94 ba 77 21 2e-a8 e0 79 91 89 64 41 f1 -w!...y..dA.
0020 - 14 5f aa 3d 1c 4f c7 1f-a7 93 71 6c e1 15 68 10 ._.=.Oql..h.
0030 - 8d 9d 53 6f 71 42 24 85-1d c3 42 44 3f 68 4d fd ..SoqB$...BD?hM.
0040 - 9e d1 57 c5 5a 8b 9c 54-46 05 36 be 98 4c 09 cd ..W.Z..TF.6..L..
0050 - 9d 12 c3 9f f6 81 1e 64-e7 0e 7d 6c 16 6b 8e 70 ...d..}l.k.p
0060 - 7f 06 e3 c0 1f 0a 96 81-06 e9 40 19 70 1d 56 ed ..@.p.V.
0070 - 5d f3 e9 94 62 ae bd 8b-0a c1 a9 a5 f1 35 b2 3f ]...b5.?
0080 - 95 43 45 59 6e 52 f9 09-5b 67 bb 76 b4 17 ab b7 .CEYnR..[g.v
0090 - 13 77 bc 25 ec 22 6d 04-cc 96 2e eb 23 3c c4 60 .w.%."m.#<.`
00a0 - 28 f5 75 5d 79 85 74 f0-c3 9c a1 51 ce f1 4d b3 (.u]y.tQ..M.
00b0 - b2 c8 9d 7a 09 61 3e 62-c8 d4 e2 d1 b0 8e 78 54 ...z.a>b..xT
00c0 - 90 4d 0b c1 08 a3 fe b1-92 51 71 71 d4 55 6d d4 .M...Qqq.Um.
00d0 - 9c 1a cc aa 38 70 f9 24-2b b7 42 57 59 ee 71 b6 8p.$+.BWY.q.
00e0 - 79 0e y.
Start Time: 1648038678
Timeout : 7200 (sec)
Verify return code: 20 (unable to get local issuer certificate)
Extended master secret: yes
---
40E0A6A87F00:error:0A000126:SSL routines:ssl3_read_n:unexpected eof while
reading:ssl/record/rec_layer_s3.c:308:
-Original Message-
From: Matt Caswell
Sent: kolmapäev, 23. märts 2022 13:55
To: Helde, Paavo ; openssl-users@openssl.org
Subject: [External] Re: SSL_connect() failing on SSL3_MT_NEWSESSION_TICKET on
Raspberry Pi
Use caution when opening links or attachments.
On 23/03/2022 07:39, Helde, Paavo via openssl-users wrote:
> Hi,
>
> We are in a process of porting our software to aarch64 (Raspberry Pi).
> One problem what we have is with openssl, it appears that our build of
> it always fails in SSL_connect(). I have debugged it a bit and it
> seems the problem appears in the function
> ossl_statem_client13_read_transition(), where after receiving
> SSL3_MT_SERVER_HELLO and SSL3_MT_ENCRYPTED_EXTENSIONS it receives
> SSL3_MT_NEWSESSION_TICKET, but there is no handling of
> SSL3_MT_NEWSESSION_TICKET in ’case TLS_ST_CR_ENCRYPTED_EXTENSIONS’
> in statem_clnt.c around line 121.
That is quite odd. It appears you are in a TLSv1.3 handshake and have received
a NewSessionTicket message. But NewSessionTicket messages should only be sent
post handshake in TLSv1.3. So, if that's really what has been received, then
that is a protocol violation.
It would be interesting to see what output you get from s_client when you use
the "-trace" argument.
Also, is this TLSv1.3 specific? If you add the argument "-no_tls1_3" to
s_client does it start working?
Matt
>
> I am no expert in SSL, so not sure where the problem might be, most
> probably we build the openssl somehow in the wrong way. We also have
> corporate firewall protected by ZScaler, but other tools like wget
> work fine with external URL-s, so it ought to be possible to get it working.
>
> We build openssl like that:
>
> # EGD needed for libIce
>
> ./config -d no-shared enable-egd --prefix=$INSTALL_ROOT/$PROJECT
>
> # Hide the symbols to avoid that undesired .so-s will find them
> (there is a zoo of binary incompatible openssl versions out there).
>
> make CFLAGS="-g -O0 -fvisibility=hidden" CXXFLAGS="-g -O0
> -fvisibility=hidden"
>
> make install
>
> bin> ./openssl version
>
> OpenSSL 3.1.0-dev (Library: OpenSSL 3.1.0-dev )
>
> The error (unexpected message) is visible also with the openssl
> command line. In our code SSL_connect() fails.
>
> bin> ./openssl s_client
> bin> https://urldefense.com/v3/__http://www.google.com__;!!GdTGuAHWOn0
> bin> L!fHTPt_L3vv-TUqwVGqbCIQlS64qPNKWVU7nd4Z-9cBpGSGuZxRdLn_z-PnFYN5M
> bin> 6Juthxg$ :443
> bin> <https://urldefense.com/v3/__http://www.google.com:443__;!!GdTGuA
> bin> HWOn0L!fHTPt_L3vv-TUqwVGqbCIQlS64qPNKWVU7nd4Z-9cBpGSGuZxRdLn_z-Pn
> bin> FYN5Pdf0LOhw$ >
>
> Connecting to 172.217.169.36
>
> CONNECTED(0003)
>
> 4080C5B57F00:error:0AF4:SSL
> routines:ossl_statem_client_read_transition:unexpected
> message:s
Re: SSL_connect() failing on SSL3_MT_NEWSESSION_TICKET on Raspberry Pi
On 23/03/2022 07:39, Helde, Paavo via openssl-users wrote: Hi, We are in a process of porting our software to aarch64 (Raspberry Pi). One problem what we have is with openssl, it appears that our build of it always fails in SSL_connect(). I have debugged it a bit and it seems the problem appears in the function ossl_statem_client13_read_transition(), where after receiving SSL3_MT_SERVER_HELLO and SSL3_MT_ENCRYPTED_EXTENSIONS it receives SSL3_MT_NEWSESSION_TICKET, but there is no handling of SSL3_MT_NEWSESSION_TICKET in ’case TLS_ST_CR_ENCRYPTED_EXTENSIONS’ in statem_clnt.c around line 121. That is quite odd. It appears you are in a TLSv1.3 handshake and have received a NewSessionTicket message. But NewSessionTicket messages should only be sent post handshake in TLSv1.3. So, if that's really what has been received, then that is a protocol violation. It would be interesting to see what output you get from s_client when you use the "-trace" argument. Also, is this TLSv1.3 specific? If you add the argument "-no_tls1_3" to s_client does it start working? Matt I am no expert in SSL, so not sure where the problem might be, most probably we build the openssl somehow in the wrong way. We also have corporate firewall protected by ZScaler, but other tools like wget work fine with external URL-s, so it ought to be possible to get it working. We build openssl like that: # EGD needed for libIce ./config -d no-shared enable-egd --prefix=$INSTALL_ROOT/$PROJECT # Hide the symbols to avoid that undesired .so-s will find them (there is a zoo of binary incompatible openssl versions out there). make CFLAGS="-g -O0 -fvisibility=hidden" CXXFLAGS="-g -O0 -fvisibility=hidden" make install bin> ./openssl version OpenSSL 3.1.0-dev (Library: OpenSSL 3.1.0-dev ) The error (unexpected message) is visible also with the openssl command line. In our code SSL_connect() fails. bin> ./openssl s_client www.google.com:443 <http://www.google.com:443> Connecting to 172.217.169.36 CONNECTED(0003) 4080C5B57F00:error:0AF4:SSL routines:ossl_statem_client_read_transition:unexpected message:ssl/statem/statem_clnt.c:399: --- no peer certificate available --- No client certificate CA names sent Server Temp Key: X25519, 253 bits --- SSL handshake has read 4296 bytes and written 333 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- Any advice appreciated TIA Paavo
SSL_connect() failing on SSL3_MT_NEWSESSION_TICKET on Raspberry Pi
Hi, We are in a process of porting our software to aarch64 (Raspberry Pi). One problem what we have is with openssl, it appears that our build of it always fails in SSL_connect(). I have debugged it a bit and it seems the problem appears in the function ossl_statem_client13_read_transition(), where after receiving SSL3_MT_SERVER_HELLO and SSL3_MT_ENCRYPTED_EXTENSIONS it receives SSL3_MT_NEWSESSION_TICKET, but there is no handling of SSL3_MT_NEWSESSION_TICKET in ' case TLS_ST_CR_ENCRYPTED_EXTENSIONS' in statem_clnt.c around line 121. I am no expert in SSL, so not sure where the problem might be, most probably we build the openssl somehow in the wrong way. We also have corporate firewall protected by ZScaler, but other tools like wget work fine with external URL-s, so it ought to be possible to get it working. We build openssl like that: # EGD needed for libIce ./config -d no-shared enable-egd --prefix=$INSTALL_ROOT/$PROJECT # Hide the symbols to avoid that undesired .so-s will find them (there is a zoo of binary incompatible openssl versions out there). make CFLAGS="-g -O0 -fvisibility=hidden" CXXFLAGS="-g -O0 -fvisibility=hidden" make install bin> ./openssl version OpenSSL 3.1.0-dev (Library: OpenSSL 3.1.0-dev ) The error (unexpected message) is visible also with the openssl command line. In our code SSL_connect() fails. bin> ./openssl s_client www.google.com:443<http://www.google.com:443> Connecting to 172.217.169.36 CONNECTED(0003) 4080C5B57F00:error:0AF4:SSL routines:ossl_statem_client_read_transition:unexpected message:ssl/statem/statem_clnt.c:399: --- no peer certificate available --- No client certificate CA names sent Server Temp Key: X25519, 253 bits --- SSL handshake has read 4296 bytes and written 333 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- Any advice appreciated TIA Paavo
SSL_Connect always returrns SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE and stuck in infinite loop
Hi All,
I am using below code for creating SSL connection over a non-blocking
socket:
-
ssl_error = SSL_connect(ssl_ctxt);
if (ssl_error <= 0) {
ssl_error = SSL_get_error(ssl_ctxt, ssl_error);
switch (ssl_error) {
case SSL_ERROR_WANT_READ:
case SSL_ERROR_WANT_WRITE:
return RETRY;
default:
ERR_load_crypto_strings();
printf("SSL_connect failed %s:%d",
ERR_error_string(ERR_get_error(), NULL),
ssl_error);
ERR_free_strings();
return FAIL;
}
}
As per Openssl doc, when above function returns RETRY, I am again
polling on my 'fd' with epoll_wait(), and retrying SSL_conn, below is the
pseudo code for it.
--
event.events = EPOLLOUT;
event.data.fd = fd;
epoll_ctl(epoll_fd, EPOLL_CTL_ADD, fd, )
event_count = epoll_wait(epoll_fd, events, MAX_EVENTS, 1000);
if(event_count > 0) {
//Call SSL_connect again.
}
---
Most of the time it's working fine, but sometimes I am observing that
connection is not getting established and SSL_connect always returns
SSL_ERROR_WANT_READ/SSL_ERROR_WANT_READ, which is resulting into an
infinite loop.
Can you please help me if there is something wrong in my code while
handling these errors? or How I can gracefully come out of this situation
and avoid infinite loop ?
Thanks in advance.
Regards,
Amit
OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to imap.gmail.com:993
I'm on Ubuntu 20.04.2 LTS, and test Gmail using the IMAP protocol as follows: ``` $ curl -vx socks5h://127.0.0.1:18889 --ssl imaps://imap.gmail.com:993 --user "hszhao.cn:passwd" * Trying 127.0.0.1:18889... * TCP_NODELAY set * SOCKS5 communication to imap.gmail.com:993 * SOCKS5 connect to imap.gmail.com:993 (remotely resolved) * SOCKS5 request granted. * Connected to 127.0.0.1 (127.0.0.1) port 18889 (#0) * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to imap.gmail.com:993 * Closing connection 0 curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to imap.gmail.com:993 ``` While the other testing will succeed: ``` $ curl -vx socks5h://127.0.0.1:7891 --ssl imaps://imap.gmail.com:993 --user "hszhao.cn:passwd" * Trying 127.0.0.1:7891... * TCP_NODELAY set * SOCKS5 communication to imap.gmail.com:993 * SOCKS5 connect to imap.gmail.com:993 (remotely resolved) * SOCKS5 request granted. * Connected to 127.0.0.1 (127.0.0.1) port 7891 (#0) * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * Server certificate: * subject: CN=imap.gmail.com * start date: Aug 16 03:04:33 2021 GMT * expire date: Nov 8 03:04:32 2021 GMT * subjectAltName: host "imap.gmail.com" matched cert's "imap.gmail.com" * issuer: C=US; O=Google Trust Services LLC; CN=GTS CA 1C3 * SSL certificate verify ok. * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing < * OK Gimap ready for requests from 103.138.53.176 q24mb12571169jar > A001 CAPABILITY < * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 XYZZY SASL-IR AUTH=XOAUTH2 AUTH=PLAIN AUTH=PLAIN-CLIENTTOKEN AUTH=OAUTHBEARER AUTH=XOAUTH < A001 OK Thats all she wrote! q24mb12571169jar > A002 AUTHENTICATE PLAIN AGhzemhhby5jbgBHblVUZVgyNjUxMDM5 < * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA ID XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE ENABLE MOVE CONDSTORE ESEARCH UTF8=ACCEPT LIST-EXTENDED LIST-STATUS LITERAL- SPECIAL-USE APPENDLIMIT=35651584 < A002 OK hszhao...@gmail.com authenticated (Success) > A003 LIST "" * < * LIST (\HasNoChildren) "/" "INBOX" * LIST (\HasNoChildren) "/" "INBOX" < * LIST (\HasNoChildren) "/" "Junk" * LIST (\HasNoChildren) "/" "Junk" < * LIST (\HasChildren \Noselect) "/" "[Gmail]" * LIST (\HasChildren \Noselect) "/" "[Gmail]" < * LIST (\All \HasNoChildren) "/" "[Gmail]/All Mail" * LIST (\All \HasNoChildren) "/" "[Gmail]/All Mail" < * LIST (\Drafts \HasNoChildren) "/" "[Gmail]/Drafts" * LIST (\Drafts \HasNoChildren) "/" "[Gmail]/Drafts" < * LIST (\HasNoChildren \Important) "/" "[Gmail]/Important" * LIST (\HasNoChildren \Important) "/" "[Gmail]/Important" < * LIST (\HasNoChildren \Sent) "/" "[Gmail]/Sent Mail" * LIST (\HasNoChildren \Sent) "/" "[Gmail]/Sent Mail" < * LIST (\HasNoChildren \Junk) "/" "[Gmail]/Spam" * LIST (\HasNoChildren \Junk) "/" "[Gmail]/Spam" < * LIST (\Flagged \HasNoChildren) "/" "[Gmail]/Starred" * LIST (\Flagged \HasNoChildren) "/" "[Gmail]/Starred" < * LIST (\HasNoChildren \Trash) "/" "[Gmail]/Trash" * LIST (\HasNoChildren \Trash) "/" "[Gmail]/Trash" < * LIST (\HasNoChildren) "/" "" * LIST (\HasNoChildren) "/" "" < * LIST (\HasNoChildren) "/" "" * LIST (\HasNoChildren) "/" "" < * LIST (\HasNoChildren) "/" "" * LIST (\HasNoChildren) "/" "" < * LIST (\HasNoChildren) "/" "" * LIST (\HasNoChildren) "/" "" < A003 OK Success * Connection #0 to host 127.0.0.1 left intact ``` Any hints for this problem? Regards, HY -- Assoc. Prof. Hongyi Zhao Theory and Simulation of Materials Hebei Vocational University of Technology and Engineering No. 473, Quannan West Street, Xindu District, Xingtai, Hebei province
Re: SSL_connect with TLS 1.3 and client Certificates
On 14/07/2021 13:31, Matt Caswell wrote: > > > On 13/07/2021 19:44, Christian Schmidt wrote: >> Hello all, >> >> I am currently trying to build both client and server of an application >> that uses TLS 1.3 and mutual authentication using certificates. The >> application works so far - I can establish connections, certificates are >> verified, data is successfully transmitted, etc. >> >> However, I have an issue, or maybe two. >> >> 1. SSL_connect returns successfully before the client certificate is >> sent from the client to the server. The client certificate is only sent >> on the first SSL_write_ex with > 0 bytes, and as such, at this point the >> server can generate SSL alerts like access denied, etc. > > TLSv1.3 supports two types of certificate request. It can occur during > the initial handshake, or it can occur as a post-handshake request. It > sounds like you are doing the latter, but you want the former. Is that > correct? > > What are you doing in your code to request the certificate from the client? I may have interpreted what I was seeing wrong. I was assuming that openssl was sending the client certificate together with the first data frame, but it seems that some coalescing happens on the kernel side, causing the server to retrieve both SSL records at once. The asynchronous nature of TLS implies that after sending the client certificate, SSL_connect() does not have to wait for a positive confirmation. Adding a sufficiently large usleep() between SSL_connect() and the first data record makes this visible. Please ignore my question. Best regards, Christian
Re: SSL_connect with TLS 1.3 and client Certificates
On 13/07/2021 19:44, Christian Schmidt wrote: Hello all, I am currently trying to build both client and server of an application that uses TLS 1.3 and mutual authentication using certificates. The application works so far - I can establish connections, certificates are verified, data is successfully transmitted, etc. However, I have an issue, or maybe two. 1. SSL_connect returns successfully before the client certificate is sent from the client to the server. The client certificate is only sent on the first SSL_write_ex with > 0 bytes, and as such, at this point the server can generate SSL alerts like access denied, etc. TLSv1.3 supports two types of certificate request. It can occur during the initial handshake, or it can occur as a post-handshake request. It sounds like you are doing the latter, but you want the former. Is that correct? What are you doing in your code to request the certificate from the client? Matt
SSL_connect with TLS 1.3 and client Certificates
Hello all, I am currently trying to build both client and server of an application that uses TLS 1.3 and mutual authentication using certificates. The application works so far - I can establish connections, certificates are verified, data is successfully transmitted, etc. However, I have an issue, or maybe two. 1. SSL_connect returns successfully before the client certificate is sent from the client to the server. The client certificate is only sent on the first SSL_write_ex with > 0 bytes, and as such, at this point the server can generate SSL alerts like access denied, etc. 2. When trying to benchmark latency on the application, the first roundtrip is extended by the client certificate verification. Is there any way I can complete the handshake, and thus validate the full connection, without sending data? I must say that even after reading RFC8446 I am not sure if there is a positive confirmation after the client certificate is sent, so I am not sure if what I am asking for is even possible. Best regards, Chris
Re: SSL_ERROR_WANT_TIME: Pause SSL_connect to fetch intermediate certificates
On 19/08/2020 20:35, Alex Rousskov wrote: > Does this clarify what I meant? Do you agree that OpenSSL async API is > not suitable for callbacks that _require_ ASYNC_pause_job() to return > control to the application? Yes, it clarifies what you meant. And, yes, its true that strictly speaking that *could* happen. ASYNC_block_pause() was introduced to handle the problem where we are holding a lock and therefore must not return control to the user without releasing that lock. As a general rule we want to keep the sections of code that perform work under a lock to an absolute minimum. It would not seem like a great idea to me to call user callbacks from libssl while holding such a lock. We have no idea what those callbacks are going to do, and which APIs they will call. The chances of a deadlock occurring seem very high under those circumstances, unless restrictions are placed on what the callback can do, and those restrictions are very clearly documented. So, yes you are right. But in practice I'm not sure how much I'd really worry about this theoretical restriction. That's of course for you to decide. > If you think that fears about something inside OpenSSL/engines > preventing our callback from returning control to the application are > unfounded, then using async API may be the best long-term solution for > Squid. Short-term, it does not work "as is" because OpenSSL STACKSIZE > appears to be too small (leading to weird crashes that disappear if we > increase STACKSIZE from 32768 to 524288 bytes), but perhaps we can > somehow hack around that. Hmm. Yes this is a problem with the current implementation. The selection of STACKSIZE is somewhat arbitrary. It would be nice if the stack size grew as required, but I'm not sure if that's even technically possible. A workaround might be for us to expose some API to set it - but exposing such internal details is also quite horrible. > > >> One possibility that springs to mind (which is also an ugly hack) is to >> defer the validation of the certificates. So, you have a verify callback >> that always says "ok". But any further reads on the underlying BIO >> always return with "retry" until such time as any intermediate >> certificates have been fetched and the chain has been verified "for >> real". The main problem I can see with this approach is there is no easy >> way to send the right alert back to the server in the event of failure. > > We were also concerned that X509_verify_cert() is not enough to fully > mimic the existing OpenSSL certificate validation procedure because the > internal OpenSSL ssl_verify_cert_chain() does not just call > X509_verify_cert(). It also does some DANE-related manipulations, for > example. Are those fears unfounded? In other words, is calling > X509_verify_cert() directly always enough to make the right certificate > validation decision? > Does squid use the DANE APIs? If not I'm not sure it makes much difference. In any case the "manipulation" seems limited to setting DANE information in the X509_STORE_CTX which presumably could be replicated by: X509_STORE_CTX_set0_dane(ctx, SSL_get0_dane()); However, I'm not really the person to ask about the DANE implementation. Maybe Viktor Dukhovni will chip in with his thoughts. Matt
Re: SSL_ERROR_WANT_TIME: Pause SSL_connect to fetch intermediate certificates
On 8/19/20 5:29 AM, Matt Caswell wrote:
> We should really have a proper callback for this purpose. PRs welcome!
> (Doesn't help you right now though).
Thank you for a prompt, thoughtful, and useful response. I believe that
we are on the same page as far as async API overall intentions, and I am
also very glad to hear that the OpenSSL team may welcome an addition of
a proper callback to address Squid's use case. I know Squid needs are
not unique. I do not yet know whether I can contribute (or facilitate
contribution of) such an enhancement, but this green light is meaningful
progress already!
>> "Somewhat counter-intuitively, the OpenSSL async API is meant for
>> activities that can work correctly _without_ becoming asynchronous (i.e.
>> without being paused to temporary give way to other activities)"
> I have no idea what you mean by this.
Sorry for not detailing this accusation. I was worried that my email was
already too long/verbose... I will detail it below.
> The whole point of ASYNC_pause_job() is to temporarily give way to
> other activities.
Yes, giving way to other activities is the whole point of the async API
optimization. Unfortunately, being only an optimization, the API is not
enough when the callback MUST "give way to other activities". AFAICT,
OpenSSL does not guarantee that ASYNC_pause_job() in a callback will
actually "give way to other activities" because OpenSSL does guarantee
that some engine or OpenSSL native code does not hold a
ASYNC_block_pause() "lock" while calling the callback.
The engine code that async API supports well may look like this[1]:
myengine()
{
while (!something_happened())
ASYNC_pause_job(); // application MAY get control here
... use something ...
}
The callback code that async API does not support looks like this:
mycallback()
{
if (!something_happened())
ASYNC_pause_job(); // application MUST get control here
assert(something_happened());
... use something ...
}
Please note that replacing "if" with "while" in mycallback() would make
the compiled code identical with myengine() but would not solve the
problem: Instead of the failed assertion, the callback would get into an
infinite loop...
The callback _relies_ on the application making progress (e.g., fetching
the missing intermediate certificates or declaring a fetch failure
before resuming SSL_connect()). This callback cannot work correctly
without the application actually getting control. That is why the
pausing call comments are different: MAY vs. MUST.
Does this clarify what I meant? Do you agree that OpenSSL async API is
not suitable for callbacks that _require_ ASYNC_pause_job() to return
control to the application?
[1] This myengine() example is inspired by your explanation at
https://mta.openssl.org/pipermail/openssl-dev/2015-October/003031.html
> ASYNC_block_pause() ... does not appear in the library code
True, but it did appear there in the past, right? I am looking at commit
625146d as an example. Those calls were removed more than a year later
in 75e2c87 AFAICT, but I see no guarantee that they will not reappear again.
And even if OpenSSL now has a policy against using ASYNC_block_pause()
internally, or a policy against holding an ASYNC_block_pause() "lock"
while calling any callback, some custom engine might do that at the
"wrong" for the above mycallback() moment, right?
If you think that fears about something inside OpenSSL/engines
preventing our callback from returning control to the application are
unfounded, then using async API may be the best long-term solution for
Squid. Short-term, it does not work "as is" because OpenSSL STACKSIZE
appears to be too small (leading to weird crashes that disappear if we
increase STACKSIZE from 32768 to 524288 bytes), but perhaps we can
somehow hack around that.
> One possibility that springs to mind (which is also an ugly hack) is to
> defer the validation of the certificates. So, you have a verify callback
> that always says "ok". But any further reads on the underlying BIO
> always return with "retry" until such time as any intermediate
> certificates have been fetched and the chain has been verified "for
> real". The main problem I can see with this approach is there is no easy
> way to send the right alert back to the server in the event of failure.
We were also concerned that X509_verify_cert() is not enough to fully
mimic the existing OpenSSL certificate validation procedure because the
internal OpenSSL ssl_verify_cert_chain() does not just call
X509_verify_cert(). It also does some DANE-related manipulations, for
example. Are those fears unfounded? In other words, is calling
X509_verify_cert() directly always enough to make the right certificate
validation decision?
Thanks a lot,
Alex.
Re: SSL_ERROR_WANT_TIME: Pause SSL_connect to fetch intermediate certificates
On 18/08/2020 22:31, Alex Rousskov wrote: > As you know, OpenSSL provides the certificate verification callback that > can discover that the origin certificate chain is incomplete. An > application using threads or blocking I/O can probably "pause" its > verification callback execution, fetch the intermediate certificates, > and then complete validation before happily returning to the > SSL_connect() caller. Life is easy when you can use threads or block > thousands of concurrent transactions! I suspect this is the way most people do it. > What can we do? How can we pause the SSL_connect() progress after the > origin certificate is fetched but before it is validated? We should really have a proper callback for this purpose. PRs welcome! (Doesn't help you right now though). > I am aware of the ASYNC_pause_job() and related async APIs in OpenSSL. > If I interpret related documentation, discussions, and our test results > correctly, that API is not meant as the correct answer for our problem. > Today, abusing that API will probably work. Tomorrow, > internal/unpredictable OpenSSL changes might break our Squid > enhancements beyond repair as detailed below. > > Somewhat counter-intuitively, the OpenSSL async API is meant for > activities that can work correctly _without_ becoming asynchronous (i.e. > without being paused to temporary give way to other activities). Squid > cannot fetch the missing intermediate certificates without pausing TLS > negotiations with the server... > > The async API was added to support custom OpenSSL engines, not > application callbacks. The API does not guarantee that an > ASYNC_pause_job() will actually pause processing and return to the > SSL_connect() caller! That will only happen if OpenSSL internal code > does not call ASYNC_block_pause(), effectively converting all subsequent > ASYNC_pause_job() calls into a no-op. That pause-nullification was added > to work around deadlocks, but it effectively places the API off limits > to user-level code that cannot control the timing of those > ASYNC_block_pause() calls. The async API is meant for any scenario where user code may want to perform async processing. Its design is NOT restricted to engines - although that is certainly where it is normally used. However there are no assumptions made anywhere that it will be exclusively restricted to engines. ASYNC_block_pause() is intended as a user level API, and a quick search of the codebase reveals that the only place we use it internally is in our tests - it does not appear in the library code. The intention is that you should be able to rely on being inside a job in any callbacks, if you've started the connection inside one. "Somewhat counter-intuitively, the OpenSSL async API is meant for activities that can work correctly _without_ becoming asynchronous (i.e. without being paused to temporary give way to other activities)" I have no idea what you mean by this. The whole point of ASYNC_pause_job() is to temporarily give way to other activities. One issue you might encounter with the ASYNC APIs is that they are not available on some less-common platforms. Basically anything without setcontext/swapcontext support (e.g. IIRC I think android may fall into this category). > Can you think of another trick? One possibility that springs to mind (which is also an ugly hack) is to defer the validation of the certificates. So, you have a verify callback that always says "ok". But any further reads on the underlying BIO always return with "retry" until such time as any intermediate certificates have been fetched and the chain has been verified "for real". The main problem I can see with this approach is there is no easy way to send the right alert back to the server in the event of failure. > P.S. Squid does not support BoringSSL, but BoringSSL's > SSL_ERROR_WANT_CERTIFICATE_VERIFY result of the certificate validation > callback seemingly addresses our use case. I do not know whether OpenSSL > decision makers would be open to adding something along those lines and > decided to ask for existing solutions here before proposing adding > SSL_ERROR_WANT_TIME :-). I'd definitely be open to adding it - although it wouldn't be backported to a stable branch. Matt
SSL_ERROR_WANT_TIME: Pause SSL_connect to fetch intermediate certificates
Hello, TLDR: How can we pause the SSL_connect() progress and return to its caller after the origin certificate is fetched/decrypted, but before OpenSSL starts validating it (so that we can fetch the missing intermediate certificates without threads or blocking I/O)? ASYNC_pause_job() does not seem to be the right answer. My team is working on an HTTP proxy Squid. Squid does not have the luxury of knowing what secure servers it will be talking to (on behalf of its clients). Thus, it cannot simply preload _intermediate_ certificates for servers that do not supply them in their TLS handshakes (e.g. https://incomplete-chain.badssl.com/ ) The standard solution for the missing intermediate certificate problem is to fetch the missing intermediate certificates upon their discovery. AIA (RFC 5280) is a mechanism that applications can use to learn about the location of the missing intermediate certificates. Popular browsers fetch what they miss: If you go to the above URL, your browser will probably be happy! As you know, OpenSSL provides the certificate verification callback that can discover that the origin certificate chain is incomplete. An application using threads or blocking I/O can probably "pause" its verification callback execution, fetch the intermediate certificates, and then complete validation before happily returning to the SSL_connect() caller. Life is easy when you can use threads or block thousands of concurrent transactions! Unfortunately, Squid can use neither threads nor blocking I/O. Upon discovery of the missing intermediate certificates, Squid has to return to the SSL_connect() caller, fetch the certificates, and then resume SSL_connect() with the fetched certificates available to OpenSSL. However, the certificate verification callback does not have a "please call me later" return code. We can only return "yes, valid" or "no, invalid" results. We found an ugly workaround for the above problem. Here is a simplified description: Using OpenSSL BIO API, Squid parses the server certificate during the TLS handshake, discovers the missing intermediate certificates, pauses TLS I/O (this results in SSL_connect() returning back to the caller with SSL_ERROR_WANT_READ), fetches the missing certificates, supplies them to OpenSSL, and then resumes SSL_connect(). This hack has worked for many years. Now comes TLS v1.3. Squid code can no longer parse the certificates before OpenSSL because they are contained in the _encrypted_ part of the server handshake. Thus, Squid cannot discover what is missing and fetch that for OpenSSL before certificate validation starts. What can we do? How can we pause the SSL_connect() progress after the origin certificate is fetched but before it is validated? I am aware of the ASYNC_pause_job() and related async APIs in OpenSSL. If I interpret related documentation, discussions, and our test results correctly, that API is not meant as the correct answer for our problem. Today, abusing that API will probably work. Tomorrow, internal/unpredictable OpenSSL changes might break our Squid enhancements beyond repair as detailed below. Somewhat counter-intuitively, the OpenSSL async API is meant for activities that can work correctly _without_ becoming asynchronous (i.e. without being paused to temporary give way to other activities). Squid cannot fetch the missing intermediate certificates without pausing TLS negotiations with the server... The async API was added to support custom OpenSSL engines, not application callbacks. The API does not guarantee that an ASYNC_pause_job() will actually pause processing and return to the SSL_connect() caller! That will only happen if OpenSSL internal code does not call ASYNC_block_pause(), effectively converting all subsequent ASYNC_pause_job() calls into a no-op. That pause-nullification was added to work around deadlocks, but it effectively places the API off limits to user-level code that cannot control the timing of those ASYNC_block_pause() calls. Squid could kill the current TLS session (and its TCP connection), fetch the missing certificates, and then retry from scratch, but that is a very ugly (unreliable, wasteful, and noisy) solution. Can you think of another trick? Thank you, Alex. P.S. Squid does not support BoringSSL, but BoringSSL's SSL_ERROR_WANT_CERTIFICATE_VERIFY result of the certificate validation callback seemingly addresses our use case. I do not know whether OpenSSL decision makers would be open to adding something along those lines and decided to ask for existing solutions here before proposing adding SSL_ERROR_WANT_TIME :-).
RE: SSL_connect fails on systemd socket
Hi Matt, I got it working through systemd. My server program needed some modifications to properly respond to SSL_connect. Thanks for your assistance. Regards, Hari. -Original Message- From: Matt Caswell [mailto:m...@openssl.org] Sent: Wednesday, January 29, 2020 11:14 PM To: Tiwari, Hari Sahaya ; openssl-users@openssl.org Subject: Re: SSL_connect fails on systemd socket On 29/01/2020 17:28, Tiwari, Hari Sahaya wrote: > Yes, client is also on same version 1.0.2 In this case SSL > handshake(SSL_connect & SSL_accept) is done through systemd socket/service, > which is failing. > Any references around it will be very helpful. What kind of BIO are you using for reading the data in the server? Is it possible to get a wireshark trace of the failing handshake? Matt > > Regards, > Hari. > > -Original Message- > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On > Behalf Of Matt Caswell > Sent: Tuesday, January 28, 2020 8:27 PM > To: openssl-users@openssl.org > Subject: Re: SSL_connect fails on systemd socket > > > > On 28/01/2020 14:03, Tiwari, Hari Sahaya wrote: >> 140691172779952:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong >> version number:s3_pkt.c:365: > > You don't say, but from the reference to s3_pkt.c above I assume you > are using OpenSSL 1.0.2 > > This error means that the server has received a record that has the wrong > protocol version number in it. It has progressed far enough along the line > that it has already processed the initial ClientHello from the client and is > now trying to read some later record from the client. > Because it has already processed the initial ClientHello we have already > determined which protocol version is in use, so all records should use that > protocol version in their headers. In the case of this error we've received > something other than that version. > > This usually occurs because of some corruption of the data. > > Are you also using OpenSSL 1.0.2 on the client? > > Matt > >> >> Here client is able to do normal connect, post that SSL_connect fails. >> >> >> >> This client server program works well outside of systemd. >> >> >> >> Do I need to add some extra steps to get this working? >> >> Any help or reference would be appreciated. >> >> >> >> Thanks & Regards, >> >> >> >> >> >
Re: SSL_connect fails on systemd socket
On 29/01/2020 17:28, Tiwari, Hari Sahaya wrote: > Yes, client is also on same version 1.0.2 > In this case SSL handshake(SSL_connect & SSL_accept) is done through systemd > socket/service, which is failing. > Any references around it will be very helpful. What kind of BIO are you using for reading the data in the server? Is it possible to get a wireshark trace of the failing handshake? Matt > > Regards, > Hari. > > -Original Message- > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Matt Caswell > Sent: Tuesday, January 28, 2020 8:27 PM > To: openssl-users@openssl.org > Subject: Re: SSL_connect fails on systemd socket > > > > On 28/01/2020 14:03, Tiwari, Hari Sahaya wrote: >> 140691172779952:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong >> version number:s3_pkt.c:365: > > You don't say, but from the reference to s3_pkt.c above I assume you are > using OpenSSL 1.0.2 > > This error means that the server has received a record that has the wrong > protocol version number in it. It has progressed far enough along the line > that it has already processed the initial ClientHello from the client and is > now trying to read some later record from the client. > Because it has already processed the initial ClientHello we have already > determined which protocol version is in use, so all records should use that > protocol version in their headers. In the case of this error we've received > something other than that version. > > This usually occurs because of some corruption of the data. > > Are you also using OpenSSL 1.0.2 on the client? > > Matt > >> >> Here client is able to do normal connect, post that SSL_connect fails. >> >> >> >> This client server program works well outside of systemd. >> >> >> >> Do I need to add some extra steps to get this working? >> >> Any help or reference would be appreciated. >> >> >> >> Thanks & Regards, >> >> >> >> >> >
Re: SSL_connect fails on systemd socket
On 28/01/2020 14:03, Tiwari, Hari Sahaya wrote: > 140691172779952:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong > version number:s3_pkt.c:365: You don't say, but from the reference to s3_pkt.c above I assume you are using OpenSSL 1.0.2 This error means that the server has received a record that has the wrong protocol version number in it. It has progressed far enough along the line that it has already processed the initial ClientHello from the client and is now trying to read some later record from the client. Because it has already processed the initial ClientHello we have already determined which protocol version is in use, so all records should use that protocol version in their headers. In the case of this error we've received something other than that version. This usually occurs because of some corruption of the data. Are you also using OpenSSL 1.0.2 on the client? Matt > > Here client is able to do normal connect, post that SSL_connect fails. > > > > This client server program works well outside of systemd. > > > > Do I need to add some extra steps to get this working? > > Any help or reference would be appreciated. > > > > Thanks & Regards, > > > > >
SSL_connect fails on systemd socket
Hi, I am trying to implement a client server program over SSL through systemd. Here I have a TCP systemd socket (listening on a predefined port) and its associated service. systemd socket file:- # cat /usr/lib/systemd/system/test_ssl.socket [Unit] Description=Test socket [Socket] ListenStream=2000 Accept=true MaxConnections=900 [Install] WantedBy=sockets.target systemd service file:- # cat /usr/lib/systemd/system/test_ssl@.service [Unit] Description= Test Service Requires=test_ssl.socket [Service] ExecStart=/home/SSL/server StandardInput=socket KillMode=process [Install] WantedBy=multi-user.target The service file invoke the binary /home/SSL/server. Here is it a very simple client server program, where 1. Server binds and listens on a port number. 2. Client first connects to server with normal connect (server will do accept) 3. Once it gets the fd, client does the SSL_connect over same connection. (server will do SSL_accept) 4. After that it will be SSL_read & SSL_write. Once, I start the systemd socket I can see the systemd starts listening on port 2000. # systemctl start test_ssl.socket # netstat -an | grep 2000 tcp6 0 0 :::2000 :::*LISTEN Post than when executing client, SSL_conect fails. # ./client localhost 2000 OpenConnection succedeed. << normal connect succeeds. SSL_connect failed. 140691172779952:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:365: Here client is able to do normal connect, post that SSL_connect fails. This client server program works well outside of systemd. Do I need to add some extra steps to get this working? Any help or reference would be appreciated. Thanks & Regards,
Re: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small
On 29/08/2019 17:05, Hubert Kario wrote: On Wednesday, 28 August 2019 23:20:49 CEST Marcelo Lauxen wrote: ... that server is willing to negotiate ECDHE_RSA ciphers, you'd be better off disabling ciphers that use DHE and RSA key exchange and using ECDHE_RSA instead of trying to make 1024 bit work – it really is weak and should not be used (see also: LOGJAM) Where in the LOGJAM papers does it say that 1024 bit DH is too little, provided the group is not shared among millions of servers? Where, does it reliably say that ECDH with a choice of very few published groups is more secure than DH with random group parameters shared among a much smaller number of connections and servers? Also note that the following factors make it necessary to support traditional DHE for compatibility: 1. Red Hat OpenSSL builds until a few years ago disabled EC support. 2. Microsoft (and the TLS protocol specs themselves) until fairly recently allowed ECDHE only with (EC)DSA server certificates, which are not as easily available as RSA certs. 3. The "supported groups" TLS extension cannot be used without jamming the TLS clients into a short list of fixed DH groups. Thus servers have to ignore that extension and use heuristic guesses to choose the DH strength. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small
* I've another question, based on your suggestion Salz Rich, this config @SECLEVEL can be set per host/domain, or is it impossible? It totally depends on which webserver you are running and what it’s configuration allows. I’m not able to answer webserver config questions BTW.
Re: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small
Thank you guys for the answers! I've another question, based on your suggestion Salz Rich, this config @SECLEVEL can be set per host/domain, or is it impossible? On Thu, Aug 29, 2019 at 12:38 PM Salz, Rich wrote: > >- We haven't control of the server who are using DH key size of 1048 >bits. > > In order to work with this kind of server (terribly poor security > characteristics), you need to add “@SECLEVEL=0” to your OpenSSL > configuration. > > >
Re: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small
On Wednesday, 28 August 2019 23:20:49 CEST Marcelo Lauxen wrote: > Our server runs with DH key size of 2048 bits and we are trying to make > requests with httparty(https://github.com/jnunemaker/httparty) to a server > that uses DH key size of 1024 bits, i want to now for what reason we are > getting this error SSL_connect returned=1 errno=0 state=error: dh key too > small, it's because different DH key sizes? 樂 > > We haven't control of the server who are using DH key size of 1048 bits. > > I've opened the same issue on httparty > https://github.com/jnunemaker/httparty/issues/664, but seems not a problem > with httparty and something with OpenSSL. > > Currently our server is using *OpenSSL 1.1.1c*, but before we was > using *OpenSSL > 1.1.0j* and this error doesn't happen. Is OpenSSL blocking the > communication between our server who uses DH 2048 bits and the other server > who uses DH 1024 bits (weak Diffie-Hellman)? If yes, is it reported in > somewhere? > > Our server SSL Labs results: > https://www.ssllabs.com/ssltest/analyze.html?d=web.monde.com.br > > Server who we are trying make requests: > https://www.ssllabs.com/ssltest/analyze.html?d=webservices.voeazul.com.br > test that server is willing to negotiate ECDHE_RSA ciphers, you'd be better off disabling ciphers that use DHE and RSA key exchange and using ECDHE_RSA instead of trying to make 1024 bit work – it really is weak and should not be used (see also: LOGJAM) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part.
Re: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small
* We haven't control of the server who are using DH key size of 1048 bits. In order to work with this kind of server (terribly poor security characteristics), you need to add “@SECLEVEL=0” to your OpenSSL configuration.
Subject: SSL_connect returned=1 errno=0 state=error: dh key too small
Our server runs with DH key size of 2048 bits and we are trying to make requests with httparty(https://github.com/jnunemaker/httparty) to a server that uses DH key size of 1024 bits, i want to now for what reason we are getting this error SSL_connect returned=1 errno=0 state=error: dh key too small, it's because different DH key sizes? 樂 We haven't control of the server who are using DH key size of 1048 bits. I've opened the same issue on httparty https://github.com/jnunemaker/httparty/issues/664, but seems not a problem with httparty and something with OpenSSL. Currently our server is using *OpenSSL 1.1.1c*, but before we was using *OpenSSL 1.1.0j* and this error doesn't happen. Is OpenSSL blocking the communication between our server who uses DH 2048 bits and the other server who uses DH 1024 bits (weak Diffie-Hellman)? If yes, is it reported in somewhere? Our server SSL Labs results: https://www.ssllabs.com/ssltest/analyze.html?d=web.monde.com.br Server who we are trying make requests: https://www.ssllabs.com/ssltest/analyze.html?d=webservices.voeazul.com.br How we can handle with this? I would be happy if anyone can help me with this. :( Att, Marcelo.
Re: [openssl-users] SSL_connect returns SSL_ERROR_SYSCALL and errno == EWOULDBLOCK
On 10/09/18 09:05, Jahn, Gerhard wrote: > Ad: The "correct" answer is that if you get SSL_ERROR_SYSCALL then the > connection has failed and you shouldn't use that connection any more. > > This somehow contradicts the description of returncode <0 on SSL_connect > which says that > > <0 > > The TLS/SSL handshake was not successful, because a fatal error > occurred either at the protocol level or a connection failure occurred. > The shutdown was not clean. It can also occur of *_action is need to > continue the operation for non-blocking BIOs_*. > Call SSL_get_error() with the return value ret to find out the reason. I don't see any contradiction in the OpenSSL docs. All this says is that if you get <=0 return code then you need to call SSL_get_error() to find out what to do. If you get SSL_ERROR_SYSCALL then a *non-recoverable* I/O error has occurred. So, in my mind, the OpenSSL documentation is clear - you've got a non-recoverable error and therefore you shouldn't continue. If there is a contradiction it is between the OpenSSL docs which tell you you have a non-recoverable error and the value of errno - which suggests a recoverable error. This is probably down to one of two things: 1) Something has caused the value of errno to change between when the non-recoverable error occurred and when you're checking it or 2) A bug in OpenSSL is incorrectly interpreting a recoverable error as a non-recoverable one. Matt > > If SSL_ERROR_SYSCAL would always mean connection failure, why then any > action to continue the operation….. > So we’re getting SSL_connect() = -1 and we call SSL_get_error() > returning 5 as advised > Then as SSL_get_error() says > > SSL_ERROR_SYSCALL > Some non-recoverable I/O error occurred. The OpenSSL error queue may > contain more information on the error. > For socket I/O on Unix systems, consult *errno* for details > We call ERR_print_errors_fp(stderr)which gives no output. > We inspect errno which indicates EWOULDBLOCK or EAGAIN > This seems to happen rarely (once per hundreds of SSL_Connect) and as > we’re currently treating any SSL_ERROR_SYSCALL > as bogus and terminate the connection (SSL_shutdown+Socketclose) > As our server runs “forever” and has high load we see a lot of such > “SSL_Connect errors in our Logs” > Additionally it seems to happen more frequently when connecting to a > remote host rather than when connecting to a server co-located…. > I have experienced the same behavior with SSL_read/SSL_write where we > also get SSL_ERROR_SYSCALL and find that errno is EWOULDBLOCK > But in these cases we “know” what to do (wait for readable when it > appears in SSL_read and wait for writeable when in SSL_write) > Therefore we have the feeling that same blocking happens during > SSL_connect……..? > GJ > > -Original Message- > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Matt Caswell > Sent: Friday, September 07, 2018 11:24 AM > To: openssl-users@openssl.org > Subject: Re: [openssl-users] SSL_connect returns SSL_ERROR_SYSCALL and > errno == EWOULDBLOCK > > > > On 07/09/18 09:16, Jahn, Gerhard wrote: >> Hi, >> >> We are using OpenSSl 1.0.2n in our server running on LINUX. >> We call SSL_connect() on async socket (after TCP connect completion) >> to establish a secure connection. >> According to DOC SSL_get_error(() has to be called if SSL_connect() >> returns <=0 >> >> We do not understand what to do if SSL_get_error(() returns >> SSL_ERROR_SYSCALLand errno is EWOULDBLOCK If SSL_get_error returns >> SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE it pretty clear what to >> do… (we set the socket descriptor either in the readfds or writefds >> and call select to wait until the socket becomes readable or writeable >> (or times-out) But when EWOULDBLOCK is indicated, we do not know >> whether to wait for readable/writeable…… (setting both might be an >> idea but could easily lead to a live-loop as we suppose that the >> handshake either waits for a read or for a write but not both… > > That's quite a surprising result. Possibly intervening code somewhere > between the sys call and where you check errno has changed its value? > > The "correct" answer is that if you get SSL_ERROR_SYSCALL then the > connection has failed and you shouldn't use that connection any more. > Have you checked the openssl error stack for any reported issues? > > Matt > > > >> >> Any ideas? >> Thanks >> >> Mit freundlichen Grüßen/Best regards, >> * >> **Gerhard Jahn* >> >> Identity and Access Management >> >> Phone:
Re: [openssl-users] SSL_connect returns SSL_ERROR_SYSCALL and errno == EWOULDBLOCK
Ad: The "correct" answer is that if you get SSL_ERROR_SYSCALL then the connection has failed and you shouldn't use that connection any more. This somehow contradicts the description of returncode <0 on SSL_connect which says that <0 The TLS/SSL handshake was not successful, because a fatal error occurred either at the protocol level or a connection failure occurred. The shutdown was not clean. It can also occur of action is need to continue the operation for non-blocking BIOs. Call SSL_get_error() with the return value ret to find out the reason. If SSL_ERROR_SYSCAL would always mean connection failure, why then any action to continue the operation. So we're getting SSL_connect() = -1 and we call SSL_get_error() returning 5 as advised Then as SSL_get_error() says SSL_ERROR_SYSCALL Some non-recoverable I/O error occurred. The OpenSSL error queue may contain more information on the error. For socket I/O on Unix systems, consult errno for details We call ERR_print_errors_fp(stderr) which gives no output. We inspect errno which indicates EWOULDBLOCK or EAGAIN This seems to happen rarely (once per hundreds of SSL_Connect) and as we're currently treating any SSL_ERROR_SYSCALL as bogus and terminate the connection (SSL_shutdown+Socketclose) As our server runs "forever" and has high load we see a lot of such "SSL_Connect errors in our Logs" Additionally it seems to happen more frequently when connecting to a remote host rather than when connecting to a server co-located I have experienced the same behavior with SSL_read/SSL_write where we also get SSL_ERROR_SYSCALL and find that errno is EWOULDBLOCK But in these cases we "know" what to do (wait for readable when it appears in SSL_read and wait for writeable when in SSL_write) Therefore we have the feeling that same blocking happens during SSL_connect? GJ -Original Message- From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Matt Caswell Sent: Friday, September 07, 2018 11:24 AM To: openssl-users@openssl.org Subject: Re: [openssl-users] SSL_connect returns SSL_ERROR_SYSCALL and errno == EWOULDBLOCK On 07/09/18 09:16, Jahn, Gerhard wrote: > Hi, > > We are using OpenSSl 1.0.2n in our server running on LINUX. > We call SSL_connect() on async socket (after TCP connect completion) > to establish a secure connection. > According to DOC SSL_get_error(() has to be called if SSL_connect() > returns <=0 > > We do not understand what to do if SSL_get_error(() returns > SSL_ERROR_SYSCALLand errno is EWOULDBLOCK If SSL_get_error returns > SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE it pretty clear what to > do... (we set the socket descriptor either in the readfds or writefds > and call select to wait until the socket becomes readable or writeable > (or times-out) But when EWOULDBLOCK is indicated, we do not know > whether to wait for readable/writeable.. (setting both might be an > idea but could easily lead to a live-loop as we suppose that the > handshake either waits for a read or for a write but not both... That's quite a surprising result. Possibly intervening code somewhere between the sys call and where you check errno has changed its value? The "correct" answer is that if you get SSL_ERROR_SYSCALL then the connection has failed and you shouldn't use that connection any more. Have you checked the openssl error stack for any reported issues? Matt > > Any ideas? > Thanks > > Mit freundlichen Grüßen/Best regards, > * > **Gerhard Jahn* > > Identity and Access Management > > Phone: +49 (211) 399-33276 > Phone: +49 (211) 399-22891 > Email: _gerhard.jahn@atos.net_ <mailto:gerhard.j...@atos.net> > Otto-Hahn-Ring 6 > 81739 München, Germany > de.atos.net > > Atos Information Technology GmbH; Geschäftsführung: Winfried Holz, Udo > Littke; Vorsitzender des Aufsichtsrats: N.N.; Sitz der Gesellschaft: > München; Registergericht: München, HRB 235509. > > Diese E-Mail und etwaige Anlagen enthalten firmenvertrauliche > Informationen, die ausschließlich für den Empfänger bestimmt sind. > Sollten Sie diese E-Mail irrtümlich erhalten haben, benachrichtigen > Sie bitte unverzüglich den Absender per Antwort-Mail und löschen Sie > diese E-Mail nebst Anlagen von Ihrem System. Da die Integrität > innerhalb des Internets nicht zu gewährleisten ist, kann die Atos > Gruppe für die Inhalteder Nachricht kein Haftung übernehmen. Obwohl > der Absender anstrebt ein virusfreies Computernetzwerk > sicherzustellen, kann der Absender nicht gewährleisten, dass diese > E-Mail virusfrei ist und wird damit keine Haftung bei Schäden auf > Grund einer Virusübermittlung übernehmen. > > This e-mail and the documents attached are confidential and intended > solely for
[openssl-users] SSL_connect returns SSL_ERROR_SYSCALL and errno == EWOULDBLOCK
Hi, We are using OpenSSl 1.0.2n in our server running on LINUX. We call SSL_connect() on async socket (after TCP connect completion) to establish a secure connection. According to DOC SSL_get_error(() has to be called if SSL_connect() returns <=0 We do not understand what to do if SSL_get_error(() returns SSL_ERROR_SYSCALL and errno is EWOULDBLOCK If SSL_get_error returns SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE it pretty clear what to do... (we set the socket descriptor either in the readfds or writefds and call select to wait until the socket becomes readable or writeable (or times-out) But when EWOULDBLOCK is indicated, we do not know whether to wait for readable/writeable.. (setting both might be an idea but could easily lead to a live-loop as we suppose that the handshake either waits for a read or for a write but not both... Any ideas? Thanks Mit freundlichen Grüßen/Best regards, Gerhard Jahn Identity and Access Management Phone: +49 (211) 399-33276 Phone: +49 (211) 399-22891 Email: gerhard.j...@atos.net<mailto:gerhard.j...@atos.net> Otto-Hahn-Ring 6 81739 München, Germany de.atos.net [cid:231545806@16122011-2476] Atos Information Technology GmbH; Geschäftsführung: Winfried Holz, Udo Littke; Vorsitzender des Aufsichtsrats: N.N.; Sitz der Gesellschaft: München; Registergericht: München, HRB 235509. Diese E-Mail und etwaige Anlagen enthalten firmenvertrauliche Informationen, die ausschließlich für den Empfänger bestimmt sind. Sollten Sie diese E-Mail irrtümlich erhalten haben, benachrichtigen Sie bitte unverzüglich den Absender per Antwort-Mail und löschen Sie diese E-Mail nebst Anlagen von Ihrem System. Da die Integrität innerhalb des Internets nicht zu gewährleisten ist, kann die Atos Gruppe für die Inhalte der Nachricht kein Haftung übernehmen. Obwohl der Absender anstrebt ein virusfreies Computernetzwerk sicherzustellen, kann der Absender nicht gewährleisten, dass diese E-Mail virusfrei ist und wird damit keine Haftung bei Schäden auf Grund einer Virusübermittlung übernehmen. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SSL_connect returns SSL_ERROR_SYSCALL and errno == EWOULDBLOCK
On 07/09/18 09:16, Jahn, Gerhard wrote: > Hi, > > We are using OpenSSl 1.0.2n in our server running on LINUX. > We call SSL_connect() on async socket (after TCP connect completion) to > establish a secure connection. > According to DOC SSL_get_error(() has to be called if SSL_connect() > returns <=0 > > We do not understand what to do if SSL_get_error(() returns > SSL_ERROR_SYSCALLand errno is EWOULDBLOCK > If SSL_get_error returns SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE it > pretty clear what to do… > (we set the socket descriptor either in the readfds or writefds and call > select to wait until the socket becomes readable or writeable (or times-out) > But when EWOULDBLOCK is indicated, we do not know whether to wait for > readable/writeable…… > (setting both might be an idea but could easily lead to a live-loop as > we suppose that the handshake either waits for a read or for a write but > not both… That's quite a surprising result. Possibly intervening code somewhere between the sys call and where you check errno has changed its value? The "correct" answer is that if you get SSL_ERROR_SYSCALL then the connection has failed and you shouldn't use that connection any more. Have you checked the openssl error stack for any reported issues? Matt > > Any ideas? > Thanks > > Mit freundlichen Grüßen/Best regards, > * > **Gerhard Jahn* > > Identity and Access Management > > Phone: +49 (211) 399-33276 > Phone: +49 (211) 399-22891 > Email: _gerhard.jahn@atos.net_ <mailto:gerhard.j...@atos.net> > Otto-Hahn-Ring 6 > 81739 München, Germany > de.atos.net > > Atos Information Technology GmbH; Geschäftsführung: Winfried Holz, Udo > Littke; Vorsitzender des Aufsichtsrats: N.N.; Sitz der Gesellschaft: > München; Registergericht: München, HRB 235509. > > Diese E-Mail und etwaige Anlagen enthalten firmenvertrauliche > Informationen, die ausschließlich für den Empfänger bestimmt sind. > Sollten Sie diese E-Mail irrtümlich erhalten haben, benachrichtigen Sie > bitte unverzüglich den Absender per Antwort-Mail und löschen Sie diese > E-Mail nebst Anlagen von Ihrem System. Da die Integrität innerhalb des > Internets nicht zu gewährleisten ist, kann die Atos Gruppe für die > Inhalteder Nachricht kein Haftung übernehmen. Obwohl der Absender > anstrebt ein virusfreies Computernetzwerk sicherzustellen, kann der > Absender nicht gewährleisten, dass diese E-Mail virusfrei ist und wird > damit keine Haftung bei Schäden auf Grund einer Virusübermittlung > übernehmen. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Atos group > liability cannot be triggered for the message content. Although the > sender endeavors to maintain a computer virus-free network, the sender > does not warrant that this transmission is virus-free and will not be > liable for any damages resulting from any virus transmitted. > > > > > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application
Hi Matt, I have raised bug. https://github.com/openssl/openssl/issues/4763 Thanks, Mahesh G S On Tue, Nov 21, 2017 at 3:26 PM, Matt Caswell <m...@openssl.org> wrote: > Sounds like a bug. Can you raise this as an issue on github? > > https://github.com/openssl/openssl/issues > > Thanks > > Matt > > > On 21/11/17 08:53, mahesh gs wrote: > > Hi, > > > > We were able to further localize this problem and found the problem is > > with the function "BIO_dgram_sctp_wait_for_dry". In this function after > > enabling the "sctp_sender_dry_event" we are trying to do MSG_PEEK to > > peek to the message at SCTP layer, in this case the size of the message > > waiting in the lower layer is 15 which size is exactly the size of > > "Handshake Alert" that is received from the server and waiting to be > > read. Dry event is never read from the lower layer that causes the > > SUB_STATE_ERROR and intern causes the SSL_Connect to loop in application. > > > > Current version of openssl we are using is 01.01.00g. > > > > We have tested and able to reproduce this issue with the OPENSSL > > 01.00.02k version that is packaged with RHEL 7.4 as well. > > > > > > Thanks, > > Mahesh G S > > > > On Mon, Nov 20, 2017 at 4:42 PM, mahesh gs <mahesh...@gmail.com > > <mailto:mahesh...@gmail.com>> wrote: > > > > Hi Matt, > > > > Thanks for the response. > > > > We debugged through openssl code to get to know the reason why > > client is not reading "SSL Alert". > > > > Once the "ClientKeyExchange" is sent openssl trying to send out the > > "ChangeCipherSpec" message which is creating the problem. > > > > The pre-work function for "ChangeCipherSpec" enables SCTP dry event > > and wait for dry event notification. > > > > Inline image 1 > > > > > > In this scenario, dry notification is never sent from SCTP. > > "dtls_wait_for_dry" always returns "WORK_MORE_A". Hereafter flow > > never enters "read_state_machine" where alert is to be red.This > > causes SSL_Connect to be in infinite loop. > > > > > > Thanks, > > Mahesh G S > > > > On Fri, Nov 17, 2017 at 3:36 PM, Matt Caswell <m...@openssl.org > > <mailto:m...@openssl.org>> wrote: > > > > > > > > On 17/11/17 06:42, mahesh gs wrote: > > > Why > > > does client respond with "Client key exchange" even if the the > handshake > > > failure alert is sent from server? > > > > The client will send its entire flight of messages before it > > attempts to > > read anything from the server. So, in this case, the > > ClientKeyExchange > > message is still sent because the client hasn't read the alert > yet. > > > > Matt > > > > -- > > openssl-users mailing list > > To unsubscribe: > > https://mta.openssl.org/mailman/listinfo/openssl-users > > <https://mta.openssl.org/mailman/listinfo/openssl-users> > > > > > > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application
Sounds like a bug. Can you raise this as an issue on github? https://github.com/openssl/openssl/issues Thanks Matt On 21/11/17 08:53, mahesh gs wrote: > Hi, > > We were able to further localize this problem and found the problem is > with the function "BIO_dgram_sctp_wait_for_dry". In this function after > enabling the "sctp_sender_dry_event" we are trying to do MSG_PEEK to > peek to the message at SCTP layer, in this case the size of the message > waiting in the lower layer is 15 which size is exactly the size of > "Handshake Alert" that is received from the server and waiting to be > read. Dry event is never read from the lower layer that causes the > SUB_STATE_ERROR and intern causes the SSL_Connect to loop in application. > > Current version of openssl we are using is 01.01.00g. > > We have tested and able to reproduce this issue with the OPENSSL > 01.00.02k version that is packaged with RHEL 7.4 as well. > > > Thanks, > Mahesh G S > > On Mon, Nov 20, 2017 at 4:42 PM, mahesh gs <mahesh...@gmail.com > <mailto:mahesh...@gmail.com>> wrote: > > Hi Matt, > > Thanks for the response. > > We debugged through openssl code to get to know the reason why > client is not reading "SSL Alert". > > Once the "ClientKeyExchange" is sent openssl trying to send out the > "ChangeCipherSpec" message which is creating the problem. > > The pre-work function for "ChangeCipherSpec" enables SCTP dry event > and wait for dry event notification. > > Inline image 1 > > > In this scenario, dry notification is never sent from SCTP. > "dtls_wait_for_dry" always returns "WORK_MORE_A". Hereafter flow > never enters "read_state_machine" where alert is to be red.This > causes SSL_Connect to be in infinite loop. > > > Thanks, > Mahesh G S > > On Fri, Nov 17, 2017 at 3:36 PM, Matt Caswell <m...@openssl.org > <mailto:m...@openssl.org>> wrote: > > > > On 17/11/17 06:42, mahesh gs wrote: > > Why > > does client respond with "Client key exchange" even if the the > handshake > > failure alert is sent from server? > > The client will send its entire flight of messages before it > attempts to > read anything from the server. So, in this case, the > ClientKeyExchange > message is still sent because the client hasn't read the alert yet. > > Matt > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > <https://mta.openssl.org/mailman/listinfo/openssl-users> > > > > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application
Hi, We were able to further localize this problem and found the problem is with the function "BIO_dgram_sctp_wait_for_dry". In this function after enabling the "sctp_sender_dry_event" we are trying to do MSG_PEEK to peek to the message at SCTP layer, in this case the size of the message waiting in the lower layer is 15 which size is exactly the size of "Handshake Alert" that is received from the server and waiting to be read. Dry event is never read from the lower layer that causes the SUB_STATE_ERROR and intern causes the SSL_Connect to loop in application. Current version of openssl we are using is 01.01.00g. We have tested and able to reproduce this issue with the OPENSSL 01.00.02k version that is packaged with RHEL 7.4 as well. Thanks, Mahesh G S On Mon, Nov 20, 2017 at 4:42 PM, mahesh gs <mahesh...@gmail.com> wrote: > Hi Matt, > > Thanks for the response. > > We debugged through openssl code to get to know the reason why client is > not reading "SSL Alert". > > Once the "ClientKeyExchange" is sent openssl trying to send out the > "ChangeCipherSpec" message which is creating the problem. > > The pre-work function for "ChangeCipherSpec" enables SCTP dry event and > wait for dry event notification. > > [image: Inline image 1] > > > In this scenario, dry notification is never sent from SCTP. > "dtls_wait_for_dry" always returns "WORK_MORE_A". Hereafter flow never > enters "read_state_machine" where alert is to be red.This causes > SSL_Connect to be in infinite loop. > > > Thanks, > Mahesh G S > > On Fri, Nov 17, 2017 at 3:36 PM, Matt Caswell <m...@openssl.org> wrote: > >> >> >> On 17/11/17 06:42, mahesh gs wrote: >> > Why >> > does client respond with "Client key exchange" even if the the handshake >> > failure alert is sent from server? >> >> The client will send its entire flight of messages before it attempts to >> read anything from the server. So, in this case, the ClientKeyExchange >> message is still sent because the client hasn't read the alert yet. >> >> Matt >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application
Hi Matt, Thanks for the response. We debugged through openssl code to get to know the reason why client is not reading "SSL Alert". Once the "ClientKeyExchange" is sent openssl trying to send out the "ChangeCipherSpec" message which is creating the problem. The pre-work function for "ChangeCipherSpec" enables SCTP dry event and wait for dry event notification. [image: Inline image 1] In this scenario, dry notification is never sent from SCTP. "dtls_wait_for_dry" always returns "WORK_MORE_A". Hereafter flow never enters "read_state_machine" where alert is to be red.This causes SSL_Connect to be in infinite loop. Thanks, Mahesh G S On Fri, Nov 17, 2017 at 3:36 PM, Matt Caswell <m...@openssl.org> wrote: > > > On 17/11/17 06:42, mahesh gs wrote: > > Why > > does client respond with "Client key exchange" even if the the handshake > > failure alert is sent from server? > > The client will send its entire flight of messages before it attempts to > read anything from the server. So, in this case, the ClientKeyExchange > message is still sent because the client hasn't read the alert yet. > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application
On 17/11/17 06:42, mahesh gs wrote: > Why > does client respond with "Client key exchange" even if the the handshake > failure alert is sent from server? The client will send its entire flight of messages before it attempts to read anything from the server. So, in this case, the ClientKeyExchange message is still sent because the client hasn't read the alert yet. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application
Hi Matt,
Thanks for the response,
I added a log as suggested by you. I don't see the call entering the above
mentioned code block.
Logs on server side:
[10/15/0117 10:34:43] 803F1700 Link-2 (SSL_accept) Failed to accept
new connection, Socket Id 65, Return Value 1
[10/15/0117 10:34:43] 803F1700 Link-2 SSL File :
ssl/statem/statem_srvr.c , Line number : 2882 , Linux Error Code 0
Logs on client side:
[10/15/0117 10:34:43] 7DDE1700 Link-1 SSL_connect() fails to
connect need to retry, returned error code 2 , retry ? true
[10/15/0117 10:34:43] 7DDE1700 Link-1 SSL_connect() fails to
connect need to retry, returned error code 2 , retry ? true
[10/15/0117 10:34:43] 7DDE1700 Link-1 SSL_connect() fails to
connect need to retry, returned error code 2 , retry ? true
[10/15/0117 10:34:43] 7DDE1700 Link-1 SSL_connect() fails to
connect need to retry, returned error code 2 , retry ? true
[10/15/0117 10:34:43] 7DDE1700 Link-1 SSL_connect() fails to
connect need to retry, returned error code 2 , retry ? true
[10/15/0117 10:34:43] 7DDE1700 Link-1 SSL_connect() fails to
connect need to retry, returned error code 2 , retry ? true
We observe from wireshark capture, client sending out the certificate with
length = 0 (because we have not configured the public key on client side)
and also server sends handshake failure "Alert" to client. Why does client
respond with "Client key exchange" even if the the handshake failure alert
is sent from server?
Openssl version used is 01.01.00g. I am also attaching the latest pcap file
for your reference.
On Tue, Nov 14, 2017 at 4:35 PM, Matt Caswell <m...@openssl.org> wrote:
>
>
> On 14/11/17 10:44, mahesh gs wrote:
>
> > case SSL_ERROR_SYSCALL:
> >
> > if (EWOULDBLOCK == errno || EAGAIN == errno)
> > {
> > /* Nothing to do, retry to connect again */
> > }
>
> This doesn't look right. If SSL_connect() fails due to an NBIO event
> then you should get SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE back. If
> you get SSL_ERROR_SYSCALL then something bad happened and you should not
> retry. Could you add some logging here? I'm wondering whether you are
> ending up here but missing it and looping around again.
>
> Matt
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
4.pcap
Description: Binary data
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application
On 14/11/17 10:44, mahesh gs wrote:
> case SSL_ERROR_SYSCALL:
>
> if (EWOULDBLOCK == errno || EAGAIN == errno)
> {
> /* Nothing to do, retry to connect again */
> }
This doesn't look right. If SSL_connect() fails due to an NBIO event
then you should get SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE back. If
you get SSL_ERROR_SYSCALL then something bad happened and you should not
retry. Could you add some logging here? I'm wondering whether you are
ending up here but missing it and looping around again.
Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application
Hi,
As per the suggestion from openssl documentation whenever the SSL API
returns SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE, The calling process
then must repeat the call after taking appropriate action to satisfy the
needs of SSL_connect().
I am copying the code bits here,
do
{
/* Clear openssl error queue */
ERR_clear_error();
/* Initiate SSL Handshake */
aRetValue = SSL_connect(ivSSL);
if (aRetValue <= 0)
{
aTlsError = SSL_get_error(ivSSL, aRetValue);
switch(aTlsError)
{
case SSL_ERROR_WANT_READ:
case SSL_ERROR_WANT_WRITE:
{
/* Select on the socket for read/write events */
* retry = pollSocketForEvents(aTlsError);-->
Function is copied below*
/* Nothing to do, retry to connect again*/
LOGG_DBUG(Logger::M3UA_LOG,"Link-%d SSL_connect() fails to connect "
"need to retry, returned error code %d , retry ? %s",
ivLink->getLinkId(), aTlsError, retry?"true":"false");
}
break;
case SSL_ERROR_SYSCALL:
if (EWOULDBLOCK == errno || EAGAIN == errno)
{
/* Nothing to do, retry to connect again */
}
else
{
int aRet = ERR_get_error_line(, );
LOGG_DBUG(Logger::M3UA_LOG,"Link-%d SSL File : %s , Line number : %d , "
"Socket Id %d, Linux Error Code %d",ivLink->getLinkId(), aFile, aLine,
getFd(), errno);
LOGG_DBUG(Logger::M3UA_LOG,"Link-%d SSL_connect () :: Result Code : %d
",ivLink->getLinkId(), aTlsError);
retry = false;
}
break;
default:
{
int aRet = ERR_get_error_line(, );
LOGG_DBUG(Logger::M3UA_LOG,"Link-%d (SSL_connect) Failed to connect to
server, "
" Socket Id %d, Return Value %d ", ivLink->getLinkId(), getFd(), aTlsError);
LOGG_DBUG(Logger::M3UA_LOG,"Link-%d SSL File : %s , Line number : %d ,
Linux Error Code %d",ivLink->getLinkId(), aFile, aLine, errno);
retry = false;
}
break;
}
}
}while (aRetValue != 1 && retry != false);
bool TlsAssociation::pollSocketForEvents(long aTlsError)
{
/* This function is to implement the SSL Socket call behaviour
http://jmarshall.com/stuff/handling-nbio-errors-in-openssl.html */
fd_set readFds, writeFds;
struct timeval timeout;
int retValue;
int nfds = getFd();
FD_ZERO ();
FD_ZERO ();
FD_SET(nfds, );
FD_SET(nfds, );
/* Wait for 5 Seconds */
timeout.tv_usec = 0;
timeout.tv_sec = 5;
if (SSL_ERROR_WANT_READ == aTlsError)
{
retValue = select(nfds + 1, , NULL, NULL, );
if (retValue <= 0)
{
// Timeout or error just return failure
return false;
}
}
if (SSL_ERROR_WANT_WRITE == aTlsError)
{
retValue = select(nfds + 1, NULL, , NULL, );
if (retValue <= 0)
{
// Timeout or error just return failure
return false;
}
}
return true;
}
Thanks,
Mahesh G S
On Tue, Nov 14, 2017 at 4:01 PM, Graham Leggett <minf...@sharp.fm> wrote:
> On 14 Nov 2017, at 12:00 PM, mahesh gs <mahesh...@gmail.com> wrote:
>
> We have application that provide DTLS security for SCTP connections.
> During our testing we found that API "*SSL_connect* " fail and always
> returns SSL_ERROR_WANT_READ which causes infinite loop in the application.
>
>
> Are you properly handling that SSL_ERROR_WANT_READ, or are you ignoring it?
>
> The message isn’t an error (the symbol was misnamed), it just means
> openssl is asking you permission to read. If your code is saying "yes
> openssl you may read" when you actually aren’t ready you’ll end up in an
> infinite loop.
>
> Regards,
> Graham
> —
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application
On 14 Nov 2017, at 12:00 PM, mahesh gs <mahesh...@gmail.com> wrote: > We have application that provide DTLS security for SCTP connections. During > our testing we found that API "SSL_connect " fail and always returns > SSL_ERROR_WANT_READ which causes infinite loop in the application. Are you properly handling that SSL_ERROR_WANT_READ, or are you ignoring it? The message isn’t an error (the symbol was misnamed), it just means openssl is asking you permission to read. If your code is saying "yes openssl you may read" when you actually aren’t ready you’ll end up in an infinite loop. Regards, Graham — smime.p7s Description: S/MIME cryptographic signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] API SSL_Connect fails and always returns SSL_ERROR_WANT_READ causes infinite loop in application
Hi All, We have application that provide DTLS security for SCTP connections. During our testing we found that API "*SSL_connect* " fail and always returns SSL_ERROR_WANT_READ which causes infinite loop in the application. Scenario: 1) On Server side "Client Certificate Request" is enabled by setting the SSL context as shown below SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL); 2) On client side we have not configured the public certificate. *Logs:* [10/14/0117 15:05:06] F42C2700 Link-2 (SSL_accept) Failed to accept new connection, Socket Id 65, Return Value 1 [10/14/0117 15:05:06] F42C2700 Link-2 SSL File :* ssl/statem/statem_srvr.c *, Line number : *2882 *, Linux Error Code 0 [10/14/0117 15:05:06] F26B7700 Link-1 SSL_connect() fails to connect need to retry, returned error code 2 , retry ? true [10/14/0117 15:05:06] F26B7700 Link-1 SSL_connect() fails to connect need to retry, returned error code 2 , retry ? true [10/14/0117 15:05:06] F26B7700 Link-1 SSL_connect() fails to connect need to retry, returned error code 2 , retry ? true *<<< SSL_connect() always returns error code 2 that leeds to infinite loop in application >>>* Attaching PCAP file for your reference. *Thanks,* *Mahesh G S* connect.pcap Description: Binary data -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Encryption/decryption using parameters obtained via handshake (SSL_accept/SSL_connect)
Hello, all :) I need to link OpenSSL to a library which makes reads/writes itself and permits only to encrypt data before sending (and decrypt after receiving). Is it possible to initialize connection as follows SSL_load_error_strings(); SSL_library_init(); context = SSL_CTX_new(SSLv23_method()); if(!SSL_CTX_use_certificate_file(context, certFile, SSL_FILETYPE_PEM)) ... if(SSL_CTX_use_PrivateKey_file(context, keyFile, SSL_FILETYPE_PEM)<0 ) ... ssl = SSL_new(context); SSL_set_fd(ssl,fd); /// fd is an open socket descriptor SSL_accept(ssl); // or SSL_connect(ssl); in client and then use encryption/decryption using parameters obtained by the initialization stage above? Thank you in advance, Vladimir P.S. SSL_read/SSL_write then works well, but as I mentioned, the library does reads/writes itself... ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function
On Tue, Sep 29, 2015 at 01:56:06PM +, Tiantian Liu via RT wrote: > Hi Matt & Vi > > I tried the SSLv23_method(), and precluded/excluded all SSLv2, SSLv3, TLSv1. > I only enabled the TLSv1.2 by SSL_CTX_set_option(). > You can see my previous code: Why are you disabling TLSv1, there's little reason to do that at present. If the server supports TLS 1.2 you'll use that, otherwise you'll at least get TLS 1.0 > /*Only allow TLSv1.2 protocol*/ > SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | > SSL_OP_NO_TLSv1); I would not disable TLSv1 at this time, just SSLv2 and SSLv3. > While the above code didn't work. I couldn't reach the server. Though the > SSL_connect() didn't crash, it returned as: > > 17:49:12.939 [5499]- SSL_connect res : -1 And did you print the error stack? Look at a PCAP trace with wireshark? Connect to the server with "openssl s_client" and examine the negotiated protocol parameters? > I will continue to investigate, and keep updating the ticket. I > will adopt your idea to see if I can obtain more information during > crash. This thread does not belong on openssl-dev, cross-posting and redirecting to openssl-users. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
SSL_ERROR_WANT_READ on SSL_connect()
Hi All, I have a DTLS implementation where I am trying to connect to a server using SSL_connect(). I am checking for the error codes using the SSL_get_error. My underlying BIO is non-blocking. Is there a way to figure out if the remote peer exists or not? As of now, I get SSL_ERROR_WANT_READ for both the cases where the server is genuinely in the handshake process and the case where the server is unreachable. I can have a maximum retry and abort the connection in the case of an unreachable server. Is there a better way than this? Thanks, Shreyas
SSL_Connect() invalid write
Hi, I'm getting the following error when using SSL_Connect on a non-blocking socket. I've included some debug output that shows POLLOUT was set after the socket successfully connected. SSL_Connect then returns SSL_ERROR_WANT_READ, so the program waits for a POLLIN to be set at which point it calls SSL_Connect again and then the error occurs. It would appear OpenSSL is writing past the 100 Bytes allocated for work with an HMAC: _thread: POLLOUT (src/thread.c, line 1005) _sock_connected: attempting ssl connect... (src/sock.c, line 603) _sock_connected: SSL_ERROR_WANT_READ (src/sock.c, line 619) _thread: POLLIN (src/thread.c, line 375) _sock_connected: attempting ssl connect... (src/sock.c, line 603) ==21614== Thread 14: ==21614== Invalid write of size 4 ==21614==at 0x4C2B4FF: memset (mc_replace_strmem.c:966) ==21614==by 0x589E372: MD5_Final (md5.c:293) ==21614==by 0x72BEEED: EVP_DigestFinal_ex (digest.c:272) ==21614==by 0x723F879: HMAC_Final (hmac.c:174) ==21614==by 0x723FF56: hmac_signctx (hm_pmeth.c:172) ==21614==by 0x72CDBF7: EVP_DigestSignFinal (m_sigver.c:147) ==21614==by 0x67595BE: tls1_PRF.constprop.0 (t1_enc.c:193) ==21614==by 0x675AFDA: tls1_generate_master_secret (t1_enc.c:1099) ==21614==by 0x674A155: ssl3_send_client_key_exchange (s3_clnt.c:2300) ==21614==by 0x674BB82: ssl3_connect (s3_clnt.c:416) ==21614==by 0x67552A8: ssl23_connect (s23_clnt.c:776) ==21614==by 0x5888028: _sock_connected (sock.c:604) ==21614== Address 0x78c8554 is 0 bytes after a block of size 100 alloc'd ==21614==at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==21614==by 0x723177F: CRYPTO_malloc (mem.c:308) ==21614==by 0x72BF340: EVP_MD_CTX_copy_ex (digest.c:323) ==21614==by 0x723F9CD: HMAC_CTX_copy (hmac.c:200) ==21614==by 0x7240251: pkey_hmac_copy (hm_pmeth.c:103) ==21614==by 0x72CC3CE: EVP_PKEY_CTX_dup (pmeth_lib.c:343) ==21614==by 0x72BF26B: EVP_MD_CTX_copy_ex (digest.c:337) ==21614==by 0x72CDBD1: EVP_DigestSignFinal (m_sigver.c:144) ==21614==by 0x67595BE: tls1_PRF.constprop.0 (t1_enc.c:193) ==21614==by 0x675AFDA: tls1_generate_master_secret (t1_enc.c:1099) ==21614==by 0x674A155: ssl3_send_client_key_exchange (s3_clnt.c:2300) ==21614==by 0x674BB82: ssl3_connect (s3_clnt.c:416) ==21614== ==21614== Invalid write of size 4 ==21614==at 0x4C2B4FF: memset (mc_replace_strmem.c:966) ==21614==by 0x589E372: MD5_Final (md5.c:293) ==21614==by 0x72BEEED: EVP_DigestFinal_ex (digest.c:272) ==21614==by 0x723F8E2: HMAC_Final (hmac.c:180) ==21614==by 0x723FF56: hmac_signctx (hm_pmeth.c:172) ==21614==by 0x72CDBF7: EVP_DigestSignFinal (m_sigver.c:147) ==21614==by 0x67595BE: tls1_PRF.constprop.0 (t1_enc.c:193) ==21614==by 0x675AFDA: tls1_generate_master_secret (t1_enc.c:1099) ==21614==by 0x674A155: ssl3_send_client_key_exchange (s3_clnt.c:2300) ==21614==by 0x674BB82: ssl3_connect (s3_clnt.c:416) ==21614==by 0x67552A8: ssl23_connect (s23_clnt.c:776) ==21614==by 0x5888028: _sock_connected (sock.c:604) ==21614== Address 0x78c8554 is 0 bytes after a block of size 100 alloc'd ==21614==at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==21614==by 0x723177F: CRYPTO_malloc (mem.c:308) ==21614==by 0x72BF340: EVP_MD_CTX_copy_ex (digest.c:323) ==21614==by 0x723F9CD: HMAC_CTX_copy (hmac.c:200) ==21614==by 0x7240251: pkey_hmac_copy (hm_pmeth.c:103) ==21614==by 0x72CC3CE: EVP_PKEY_CTX_dup (pmeth_lib.c:343) ==21614==by 0x72BF26B: EVP_MD_CTX_copy_ex (digest.c:337) ==21614==by 0x72CDBD1: EVP_DigestSignFinal (m_sigver.c:144) ==21614==by 0x67595BE: tls1_PRF.constprop.0 (t1_enc.c:193) ==21614==by 0x675AFDA: tls1_generate_master_secret (t1_enc.c:1099) ==21614==by 0x674A155: ssl3_send_client_key_exchange (s3_clnt.c:2300) ==21614==by 0x674BB82: ssl3_connect (s3_clnt.c:416) ==21614== Here's the openssl version I'm running: OpenSSL 1.0.1e 11 Feb 2013 built on: Mon May 12 20:22:52 UTC 2014 platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: /usr/lib/ssl Thanks for your help, Brandon __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_Connect() invalid write
Please ignore. Turned out another library I was linking against had a function called MD5_Final and the linker was using this one instead of OpenSSL's. On 6/4/2014 4:12 PM, Brandon W Yuille wrote: Hi, I'm getting the following error when using SSL_Connect on a non-blocking socket. I've included some debug output that shows POLLOUT was set after the socket successfully connected. SSL_Connect then returns SSL_ERROR_WANT_READ, so the program waits for a POLLIN to be set at which point it calls SSL_Connect again and then the error occurs. It would appear OpenSSL is writing past the 100 Bytes allocated for work with an HMAC: _thread: POLLOUT (src/thread.c, line 1005) _sock_connected: attempting ssl connect... (src/sock.c, line 603) _sock_connected: SSL_ERROR_WANT_READ (src/sock.c, line 619) _thread: POLLIN (src/thread.c, line 375) _sock_connected: attempting ssl connect... (src/sock.c, line 603) ==21614== Thread 14: ==21614== Invalid write of size 4 ==21614==at 0x4C2B4FF: memset (mc_replace_strmem.c:966) ==21614==by 0x589E372: MD5_Final (md5.c:293) ==21614==by 0x72BEEED: EVP_DigestFinal_ex (digest.c:272) ==21614==by 0x723F879: HMAC_Final (hmac.c:174) ==21614==by 0x723FF56: hmac_signctx (hm_pmeth.c:172) ==21614==by 0x72CDBF7: EVP_DigestSignFinal (m_sigver.c:147) ==21614==by 0x67595BE: tls1_PRF.constprop.0 (t1_enc.c:193) ==21614==by 0x675AFDA: tls1_generate_master_secret (t1_enc.c:1099) ==21614==by 0x674A155: ssl3_send_client_key_exchange (s3_clnt.c:2300) ==21614==by 0x674BB82: ssl3_connect (s3_clnt.c:416) ==21614==by 0x67552A8: ssl23_connect (s23_clnt.c:776) ==21614==by 0x5888028: _sock_connected (sock.c:604) ==21614== Address 0x78c8554 is 0 bytes after a block of size 100 alloc'd ==21614==at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==21614==by 0x723177F: CRYPTO_malloc (mem.c:308) ==21614==by 0x72BF340: EVP_MD_CTX_copy_ex (digest.c:323) ==21614==by 0x723F9CD: HMAC_CTX_copy (hmac.c:200) ==21614==by 0x7240251: pkey_hmac_copy (hm_pmeth.c:103) ==21614==by 0x72CC3CE: EVP_PKEY_CTX_dup (pmeth_lib.c:343) ==21614==by 0x72BF26B: EVP_MD_CTX_copy_ex (digest.c:337) ==21614==by 0x72CDBD1: EVP_DigestSignFinal (m_sigver.c:144) ==21614==by 0x67595BE: tls1_PRF.constprop.0 (t1_enc.c:193) ==21614==by 0x675AFDA: tls1_generate_master_secret (t1_enc.c:1099) ==21614==by 0x674A155: ssl3_send_client_key_exchange (s3_clnt.c:2300) ==21614==by 0x674BB82: ssl3_connect (s3_clnt.c:416) ==21614== ==21614== Invalid write of size 4 ==21614==at 0x4C2B4FF: memset (mc_replace_strmem.c:966) ==21614==by 0x589E372: MD5_Final (md5.c:293) ==21614==by 0x72BEEED: EVP_DigestFinal_ex (digest.c:272) ==21614==by 0x723F8E2: HMAC_Final (hmac.c:180) ==21614==by 0x723FF56: hmac_signctx (hm_pmeth.c:172) ==21614==by 0x72CDBF7: EVP_DigestSignFinal (m_sigver.c:147) ==21614==by 0x67595BE: tls1_PRF.constprop.0 (t1_enc.c:193) ==21614==by 0x675AFDA: tls1_generate_master_secret (t1_enc.c:1099) ==21614==by 0x674A155: ssl3_send_client_key_exchange (s3_clnt.c:2300) ==21614==by 0x674BB82: ssl3_connect (s3_clnt.c:416) ==21614==by 0x67552A8: ssl23_connect (s23_clnt.c:776) ==21614==by 0x5888028: _sock_connected (sock.c:604) ==21614== Address 0x78c8554 is 0 bytes after a block of size 100 alloc'd ==21614==at 0x4C28BED: malloc (vg_replace_malloc.c:263) ==21614==by 0x723177F: CRYPTO_malloc (mem.c:308) ==21614==by 0x72BF340: EVP_MD_CTX_copy_ex (digest.c:323) ==21614==by 0x723F9CD: HMAC_CTX_copy (hmac.c:200) ==21614==by 0x7240251: pkey_hmac_copy (hm_pmeth.c:103) ==21614==by 0x72CC3CE: EVP_PKEY_CTX_dup (pmeth_lib.c:343) ==21614==by 0x72BF26B: EVP_MD_CTX_copy_ex (digest.c:337) ==21614==by 0x72CDBD1: EVP_DigestSignFinal (m_sigver.c:144) ==21614==by 0x67595BE: tls1_PRF.constprop.0 (t1_enc.c:193) ==21614==by 0x675AFDA: tls1_generate_master_secret (t1_enc.c:1099) ==21614==by 0x674A155: ssl3_send_client_key_exchange (s3_clnt.c:2300) ==21614==by 0x674BB82: ssl3_connect (s3_clnt.c:416) ==21614== Here's the openssl version I'm running: OpenSSL 1.0.1e 11 Feb 2013 built on: Mon May 12 20:22:52 UTC 2014 platform: debian-amd64 options: bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: /usr/lib/ssl Thanks for your help, Brandon __ OpenSSL Project http://www.openssl.org User Support Mailing List
RE: SSL_Connect return 0 with error 5
If SSL_get_error returns 5 after most SSL_* returns =0, that is SSL_ERROR_SYSCALL. An error occurred on a socket I/O call. Look at errno on Unix or [WSA]GetLastError() on Windows. For Unix you can just use strerror() or perror() to get an explanation; for Windows the MS CRT doesn't know about socket error codes and you need to use FormatError (or look up manually). In some cases the openssl error queue, most easily displayed with ERR_print_errors[_fp], may contain additional information, but for SSL_connect in my experience usually not. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Afroz Jahan Sent: Tuesday, February 25, 2014 23:52 To: openssl-users@openssl.org Subject: *** Spam *** SSL_Connect return 0 with error 5 Hi, We could not able to trace out where exactly the problem is as SSL_connect() returned 0 with ErrorNo:5 Error:error:0005:lib(0):func(0):DH lib Thanks Regards Afroz Jahan | Software Engineer EiQ NetworksR, Inc. | http://www.eiqnetworks.com/ www.eiqnetworks.com e: mailto:afr...@eiqnetworks.com afr...@eiqnetworks.com | p: +91 9550819662 t: https://twitter.com/EIQNetworks https://twitter.com/EIQNetworks | b: http://blog.eiqnetworks.com/ http://blog.eiqnetworks.com eiqlogo image001.jpg
SSL_Connect return 0 with error 5
Hi, We could not able to trace out where exactly the problem is as SSL_connect() returned 0 with ErrorNo:5 Error:error:0005:lib(0):func(0):DH lib Thanks Regards Afroz Jahan | Software Engineer EiQ Networks(r), Inc. | www.eiqnetworks.comhttp://www.eiqnetworks.com/ e: afr...@eiqnetworks.commailto:afr...@eiqnetworks.com | p: +91 9550819662 t: https://twitter.com/EIQNetworks | b: http://blog.eiqnetworks.comhttp://blog.eiqnetworks.com/ [eiqlogo] inline: image001.jpg
Re: SSL_Connect return 0 with error 5
On Wed, Feb 26, 2014 at 04:52:11AM +, Afroz Jahan wrote: We could not able to trace out where exactly the problem is as SSL_connect() returned 0 with ErrorNo:5 Error:error:0005:lib(0):func(0):DH lib $ perl -le 'print $!=5;' Input/output error The problem is at the socket layer. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SNI and NPN timing in relation to SSL_accept(), SSL_connect()
It is safe to assume that both the SNI and NPN callbacks would have been called _before either call returns success notification ? In other words, an app would be in consistent state - having decided on both the protocol (say SPDY/HTTP2.0) and possible certificate switch, before performing any of the SSL_read()/write(), as long as it makes sure to receive success from SSL_accept() or SSL_connect() beforehand ?
Re: SSL_connect blocks for almost 1 minute
Dorin others, Has this got resolved? we have been experiencing exactly the same behaviour in our Client Simulor. any clue why we only see for first connect only? however, we see varying blockage (from 3 to 40s) based on number of user simulated. Does it depend on client simulator's memory utilization? -- View this message in context: http://openssl.6102.n7.nabble.com/SSL-connect-blocks-for-almost-1-minute-tp12478p47066.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SSL_Connect blocking for 25 sec for the first connection
I have a situation where my application is trying to open 5000 SSL connections with server, one after another, I see the very first ssl connect is blocking nearly 25seconds and times out. (Interestingly this blocking time is in proportion to the number of connections im intending to open. For eg, if im trying to open 1 connections the delay is proportionately increases approx to 40 sec for the first ssl connect that is happening) However Subsequent connections (4999 out of 5000) succeeds without any blockage and seems normal... There was a post on this long time back, however I could not able to find the resolution if any exists for the same... (http://openssl.6102.n7.nabble.com/SSL-connect-blocks-for-almost-1-minute-td12478.html) Im using version 1.0.1c of open ssl on windows 7 OS. Any clue on the above behavior? Is there any fix or workaround available to avoid the blockage Regards Arun
SSL_connect failure if key size is less than 1024 bits in fips mode
Hi All, I am trying to find whether there is minimum key length restriction when operating SSL/TLS in fips mode. Documents say that if key length is 1024 bits, fips 140-2 compliant openssl-fips-1.2p1 ssl library will not allow the SSL connection. I know that SSL_connect() should fail if this is the case.Not able to find the same check in code. Can somebody point me to code where in this check is made ? Thanks Anil
RE: possible SSL_connect/accept bug?
-Original Message-
From: Roger Miller
Using OpenSSL libraries to provide basic encryption between client and
server.
Using non-blocking sockets, and client can connect to multiple servers.
I have an intermittent issue where server reports
'SSL3_GET_RECORD:wrong version number' during client hello.
I have added trace statements to the SSL code on both client and
server.
On the client, I am displaying the value of s-version down into
do_ssl3_write, and it is correct (0x0301).
On the server, error shows up here:
if ((version8) != SSL3_VERSION_MAJOR)
{
SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_WRONG_VERSION_NUMBER);
fp=fopen(ssl_err.log,a+);
fprintf(fp,WRONG_VERSION:ssl_major-%04x:packet-
%04x\n,ssl_major,version);
fclose(fp);
goto err;
}
(I added the logging). Both ssl_major and version are 0x when the
error happens.
This appears to be the first packet of client hello.
This only happens occasionally - I can run the test many times
sequentially with success, and then it will fail, then work again on
the next try.
Have tested with both v1.0.0k and v1.0.1e with same results.
Any advice or debugging tips would be appreciated.
Thanks,
Roger
Update on above: this was a client-side problem, and may be specific to Windows
- the 'wrong version number' message from the server was a red herring.
(Unfortunately, my application was sending the data in clear text after the
SSL_connect call failed.)
My initial call to 'connect' was returning 'WSAEWOULDBLOCK' (to be expected on
a non-blocking socket). Then the call to SSL_connect was *sometimes* returning
'WSAENOTCONN'. However, I found that simply retrying the SSL_connect call (in
the same manner as if I had gotten SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE)
corrected the issue.
Do anyone know if this is expected behavior for Windows sockets?
Thanks,
Roger
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: possible SSL_connect/accept bug?
On Fri, Sep 27, 2013 at 07:49:06AM -0700, Roger Miller wrote: My initial call to 'connect' was returning 'WSAEWOULDBLOCK' (to be expected on a non-blocking socket). At that point the appropriate thing to do is to select the socket for write in your event loop. Once the socket reports ready (connected or connection failed), you should query the connection status with: int error; socklen_t len = sizeof(error); getsockopt(SOL_SOCKET, SO_ERROR, error, len); or if that does not work on Windows, call getpeername() to see whether you're connected. Only once the connection is complete, should you attempt to call SSL_connect(). -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: possible SSL_connect/accept bug?
I have a similar problem and have found a fix for it. Please see the
thread below to see if your problem is the same:
http://www.mail-archive.com/openssl-dev@openssl.org/msg33010.html
Benson Kwok
Development
Www.air-watch.com
On 9/25/13 6:35 PM, Roger Miller roger.mil...@oracle.com wrote:
Using OpenSSL libraries to provide basic encryption between client and
server.
Using non-blocking sockets, and client can connect to multiple servers.
I have an intermittent issue where server reports 'SSL3_GET_RECORD:wrong
version number' during client hello.
I have added trace statements to the SSL code on both client and server.
On the client, I am displaying the value of s-version down into
do_ssl3_write, and it is correct (0x0301).
On the server, error shows up here:
if ((version8) != SSL3_VERSION_MAJOR)
{
SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_WRONG_VERSION_NUMBER);
fp=fopen(ssl_err.log,a+);
fprintf(fp,WRONG_VERSION:ssl_major-%04x:packet-%04x\n,ssl_major,versi
on);
fclose(fp);
goto err;
}
(I added the logging). Both ssl_major and version are 0x when the
error happens.
This appears to be the first packet of client hello.
This only happens occasionally - I can run the test many times
sequentially with success, and then it will fail, then work again on the
next try.
Have tested with both v1.0.0k and v1.0.1e with same results.
Any advice or debugging tips would be appreciated.
Thanks,
Roger
__
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
RE: possible SSL_connect/accept bug?
-Original Message- From: bensonkwok...@air-watch.com [mailto:bensonkwok...@air-watch.com] I have a similar problem and have found a fix for it. Please see the thread below to see if your problem is the same: http://www.mail-archive.com/openssl-dev@openssl.org/msg33010.html Benson Kwok Development Www.air-watch.com Benson, Thank you for the tip, but this does not appear to be my issue. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
possible SSL_connect/accept bug?
Using OpenSSL libraries to provide basic encryption between client and server.
Using non-blocking sockets, and client can connect to multiple servers.
I have an intermittent issue where server reports 'SSL3_GET_RECORD:wrong
version number' during client hello.
I have added trace statements to the SSL code on both client and server.
On the client, I am displaying the value of s-version down into do_ssl3_write,
and it is correct (0x0301).
On the server, error shows up here:
if ((version8) != SSL3_VERSION_MAJOR)
{
SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_WRONG_VERSION_NUMBER);
fp=fopen(ssl_err.log,a+);
fprintf(fp,WRONG_VERSION:ssl_major-%04x:packet-%04x\n,ssl_major,version);
fclose(fp);
goto err;
}
(I added the logging). Both ssl_major and version are 0x when the error
happens.
This appears to be the first packet of client hello.
This only happens occasionally - I can run the test many times sequentially
with success, and then it will fail, then work again on the next try.
Have tested with both v1.0.0k and v1.0.1e with same results.
Any advice or debugging tips would be appreciated.
Thanks,
Roger
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: ssl_connect fails Windows Non-blocking
Hi Stephan, I didn't handle properly fd_write and fd_read events after ssl_accept returning WANT_READ or WANT_WRITE. So sometimes SSL handshake didn't complete succesfully. I use plain socket descriptors with some WSA functions for selecting events, instead of MFC-Windows AsyncSocket classes. -- View this message in context: http://openssl.6102.n7.nabble.com/ssl-connect-fails-Windows-Non-blocking-tp45348p45482.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ssl_connect fails Windows Non-blocking
Solved! -- View this message in context: http://openssl.6102.n7.nabble.com/ssl-connect-fails-Windows-Non-blocking-tp45348p45480.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ssl_connect fails Windows Non-blocking
Hi Titonus, would you care to share the solution? I am interested too. Cheers, Stephan On Tue, Jun 11, 2013 at 12:07 PM, titonus tito...@gmail.com wrote: Solved! -- View this message in context: http://openssl.6102.n7.nabble.com/ssl-connect-fails-Windows-Non-blocking-tp45348p45480.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: ssl_connect fails Windows Non-blocking
More info: Client SSL log: [SSL_connect:before/connect initialization] [SSL_connect:SSLv2/v3 write client hello A] [SSL_connect:Error en SSLv2/v3 read server hello A] [SSL_connect:SSLv3 read server hello A] [SSL_connect:SSLv3 read server certificate A] [SSL_connect:SSLv3 read server key exchange A] [SSL_connect:SSLv3 read server done A] [SSL_connect:SSLv3 write client key exchange A] [SSL_connect:SSLv3 write change cipher spec A] [SSL_connect:SSLv3 write finished A] [SSL_connect:SSLv3 flush data] [SSL_connect:Error en SSLv3 read finished A] [SSL_connect:Error en SSLv3 read finished A] ***ERROR: ssl_connect - error 5 - here it's the problem Server SSL log: [SSL_accept:before/accept initialization] [SSL_accept:SSLv3 read client hello A] [SSL_accept:SSLv3 write server hello A] [SSL_accept:SSLv3 write certificate A] [SSL_accept:SSLv3 write key exchange A] [SSL_accept:SSLv3 write server done A] [SSL_accept:SSLv3 flush data] [SSL_accept:Error en SSLv3 read client certificate A] Client SSL works with same certificate in another server, and Server SSL works with same certificate being attacked by another client. -- View this message in context: http://openssl.6102.n7.nabble.com/ssl-connect-fails-Windows-Non-blocking-tp45348p45463.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
ssl_connect fails Windows Non-blocking
OpenSSL latest version I use. This is the bad sequence, client and server are already connected at TCP level: Client -- ssl_connect returns WANT_READ, so I've wait for next select/WSAEventSelect --- SSLv2/v3 read server hello A Server -- ssl_accept returns WANT_READ, same wait --- SSLv3 read client certificate A Client -- READ event arrives, call again ssl_connect which now returns -1 (error:0005:lib(0):func(0):DH lib) Server -- WRITE event arrives and must wait READ event, however Client disconnects Sometimes it connects well, with this sequence: Client -- ssl_connect returns WANT_READ, so I've wait for next select/WSAEventSelect --- SSLv2/v3 read server hello A Server -- ssl_accept returns WANT_READ, same wait --- SSLv3 read client certificate A Client -- READ event arrives Client -- call again ssl_connect returns -1 (error:0002:lib(0):func(0):system lib) == wants more READ --- SSLv3 read server session ticket A Server -- WRITE event arrives Server -- READ event arrives Server -- call again ssl_accept returns succesfully Client -- READ event arrives Client -- call ssl_connect returns succesfully Any ideas? Thanks in advance. -- View this message in context: http://openssl.6102.n7.nabble.com/ssl-connect-fails-Windows-Non-blocking-tp45348.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SSL_Connect sys call taking more time
Hi all,
I have a daemon where I am trying to retrieve the common name from the
certificate during an HTTPS connection. What i am observing is that ,
SSL_Connect() function is taking more time to connect on some of the
websites.
I am trying on Mac OS X 10.8.3. Below is the code I have been using and I
am using non-blocking sockets
#include SSLUtil.h
#include sys/socket.h
#include sys/types.h
#include netinet/in.h
#include arpa/inet.h
#include strings.h
#include openssl/ssl.h
#include openssl/x509.h
#include openssl/crypto.h
#include errno.h
#include fcntl.h
#include string
#include Logging.h
bool SSLUtil::GetSSLServerNameFromIP(std::string ipAddress, std::string
serverName)
{
bool bRet = false;
int sock=-1;
MCLOG(SSLUtil::GetSSLServerNameFromIP Call for IP,ipAddress.c_str());
if(ConnectToServerAsync(ipAddress,443,sock))
{
if(RetrieveNameUsingSSL(sock,serverName))
{
bRet = true;
MCLOG(SSLUtil::GetSSLServerNameFromIP Call
return,ipAddress.c_str(),serverName.c_str());
}
else
{
MCLOG(SSLUtil::GetSSLServerNameFromIP RetrieveNameUsingSSL
call failed,ipAddress.c_str());
}
close(sock);
}else
{
MCLOG(SSLUtil::GetSSLServerNameFromIP connect asycn
failed,ipAddress.c_str());
}
return bRet;
}
#define TIMEOUT_SERVER 3 //seconds
bool SSLUtil::ConnectToServerAsync(std::string ipaddress, int port , int
sock)
{
//create the socket
sock=socket(AF_INET,SOCK_STREAM,IPPROTO_TCP);
if(sock0)
{
//creating socket failed
MCLOG(SSLUtil::ConnectToServerAsync soceket creation failed );
return false;
}
//change socket options
int opts = fcntl(sock,F_GETFL);
if (opts 0) {
//pFailed F_GETFL
MCLOG(SSLUtil::ConnectToServerAsync F_GETFL failed );
return false;
}
opts = (opts | O_NONBLOCK);
if (fcntl(sock,F_SETFL,opts) 0) {
//Failed F_SETFL
MCLOG(SSLUtil::ConnectToServerAsync F_SETFL failed);
return false;
}
//make sure there is no error pending
int err = errno;
if (err 0)
{
MCLOG(SSLUtil::ConnectToServerAsync can't create non blocking
socket );
//printf(MakeConnectAttempt = can't set non-blocking socket);
if(sock)
{
close(sock);
}
return false;
}
struct sockaddr_in server_addr;
memset (server_addr, '\0', sizeof(server_addr));
server_addr.sin_family = AF_INET;
server_addr.sin_port= htons(port); /* Server Port number
*/
server_addr.sin_addr.s_addr = inet_addr(ipaddress.c_str()); /* Server
IP */
int status = connect(sock, (struct sockaddr*) server_addr,
sizeof(server_addr));
//wait for connection to succeed
if(status0)
{
status = errno;
if(status == EINPROGRESS)
{
MCLOG(SSLUtil::ConnectToServerAsync in progress ,
ipaddress.c_str());
if(!WaitOnSocket(sock,TIMEOUT_SERVER))
{
//printf(connect to %s failed\n,argv[1]);
MCLOG(SSLUtil::ConnectToServerAsync wait failed ,
ipaddress.c_str());
return false;
}
}else
{
//printf(connect to %s failed\n,argv[1]);
MCLOG(SSLUtil::ConnectToServerAsync connect failed , status);
return false;
}
}
MCLOG(SSLUtil::ConnectToServerAsync connect success , status);
return true;
}
bool SSLUtil::WaitOnSocket(int sockfd,int timeOutInSeconds)
{
fd_set readFDs;
fd_set writeFDs;
intselectResult;
// booltimeOut = false;
FD_ZERO(readFDs);
FD_ZERO(writeFDs);
FD_SET(sockfd, readFDs);
FD_SET(sockfd, writeFDs);
bool continueSelect ;
struct timeval waitd;
time_t seconds;
time_t future;
time_t now;
seconds = time(NULL);
future = seconds + timeOutInSeconds;
// waitd.tv_sec = timeOutInSeconds; // Make select wait up to 10
seconds for data
// waitd.tv_usec = 0; // and 0 milliseconds.
int err = 0;
continueSelect = true;
do
{
waitd.tv_sec = timeOutInSeconds; // Make select wait up to 5
seconds for data
waitd.tv_usec = 0; // and 0 milliseconds.
selectResult = select(sockfd+1, readFDs, writeFDs, NULL, waitd);
//printf(after select %d\n, selectResult);
err = errno;
if (selectResult 0)
{
for(int i=0;isockfd+1;i++)
{
if (FD_ISSET(i,readFDs))
{
continueSelect = false;
break;
}
if (FD_ISSET(i,writeFDs))
{
continueSelect = false;
break;
}
}
}
else
{
now = time(NULL);
if (now future
SSL_connect with pselect failing
Hello, I am trying to use SSL_connect. I have bound a socket to my interface, set up the context, and call SSL_connect(). This is returning a -1, which I catch, and call SSL_get_error() to fall through a switch statement. It is retuning a SSL_ERROR_WANT_WRITE So I am trying to use pselect in a while loop here to get the return. I call SSL_get_fd() to get the file descriptor, FD_SET() to add to my fd_set, and then pselect(ssl_fd+1, 0, fds, 0, timeout, NULL) This reaches my timeout every time. Is there a reason to see why it is not connecting, even though the intiial SSL_connect returned WANT_WRITE? Just to complete the model of what I was doing - assuming there was a succesful pselect(), I was going to call SSL_connect() again, and either go through the loop again, or exitand continue.
Re: SSL_connect with pselect failing
Nevermind. I didn't realize that I did have the call in there for my socket connect() (which was in another part of the code for non-ssl connections...it is needed for both). I had though SSL_connect took care of that too. On Sun, Oct 14, 2012 at 5:35 PM, Derek Cole derek.c...@gmail.com wrote: Hello, I am trying to use SSL_connect. I have bound a socket to my interface, set up the context, and call SSL_connect(). This is returning a -1, which I catch, and call SSL_get_error() to fall through a switch statement. It is retuning a SSL_ERROR_WANT_WRITE So I am trying to use pselect in a while loop here to get the return. I call SSL_get_fd() to get the file descriptor, FD_SET() to add to my fd_set, and then pselect(ssl_fd+1, 0, fds, 0, timeout, NULL) This reaches my timeout every time. Is there a reason to see why it is not connecting, even though the intiial SSL_connect returned WANT_WRITE? Just to complete the model of what I was doing - assuming there was a succesful pselect(), I was going to call SSL_connect() again, and either go through the loop again, or exitand continue.
RE: SSL_connect with pselect failing
From: owner-openssl-us...@openssl.org On Behalf Of Derek Cole Sent: Sunday, 14 October, 2012 17:36 I am trying to use SSL_connect. I have bound a socket to my interface, set up the context, and call SSL_connect(). This is returning a -1, which I catch, and call SSL_get_error() to fall through a switch statement. It is retuning a SSL_ERROR_WANT_WRITE Presumably on a nonblocking socket, or you shouldn't get WANT_WRITE. And presumably you mean an SSL object created from an SSL_CTX object. Although both of these can be called context in a generic sense, openssl uses that term for SSL_CTX. So I am trying to use pselect in a while loop here to get the return. I call SSL_get_fd() to get the file descriptor, FD_SET() to add to my fd_set, and then pselect(ssl_fd+1, 0, fds, 0, timeout, NULL) This reaches my timeout every time. Is there a reason to see why it is not connecting, even though the intiial SSL_connect returned WANT_WRITE? You say you bound the socket (which isn't usually needed on an outgoing connection) but you don't say you TCP-connected it. Only after it's connected -- and I believe fully-connected for nonblocking, but I'm not positive of that -- can it show either writable or readable to pselect et amici. SSL_connect only does the SSL part, not the TCP part. If you use connect_BIO to create the socket, *it* does the TCP-connect, but in that case you wouldn't directly manipulate the socket as you describe. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
[FWD] About SSL_connect error
Forwarded to openssl-users for discussion
Best regards,
Lutz
--
Lutz Jaenicke jaeni...@openssl.org
OpenSSL Project http://www.openssl.org/~jaenicke/
---BeginMessage---
Dear OpenSSL developers
About the following source,I have 2 questions:
1.In OpenSSL library 0.9.8d, when executing more than 2 threads at the
same time, the following error sometimes appears:
SSL_connect error, ip=192.168.1.xxx,err:error:0001:lib(0):func(0):reason(1)
why?
2. But in OpenSSL OpenSSL1.0.1c, the error never happened.I want know the
diference
between the two version OpenSSL lib,Can you help me?
--
main（）
{
SSL_library_init();
SSL_load_error_strings();
m_ctx = SSL_CTX_new(TLSv1_method());
SSL_CTX_set_options(m_ctx, SSL_OP_ALL);
mutex_buf = (MUTEX_TYPE *)malloc(CRYPTO_num_locks( ) * sizeof(MUTEX_TYPE));
if (!mutex_buf) {
return 0;
}
for (i = 0; i CRYPTO_num_locks( ); i++) {
MUTEX_SETUP(mutex_buf[i]);
}
CRYPTO_set_id_callback(id_function);
CRYPTO_set_locking_callback(locking_function);
CRYPTO_set_dynlock_create_callback(dyn_create_function);
CRYPTO_set_dynlock_lock_callback(dyn_lock_function);
CRYPTO_set_dynlock_destroy_callback(dyn_destroy_function);
for(nIndex = 0; nIndex nThreadNum; nIndex++)
{
nErrorNo = pthread_create(thread_id[nIndex], NULL, ThreadProcess,
diskArray[nIndex] );
..
}
}
ThreadProcess（）
{
call socket();
set non-block;
call connect();
call select();
call BIO_new_socket();
call SSL_new();
call SSL_set_bio();
while( TRUE != nEndFlag )
{
nStatus = SSL_connect(pstSocketInfo-m_ssl);
if(nStatus = 0)
{
nErrorNo = SSL_get_error(pstSocketInfo-m_ssl, nStatus);
if((SSL_ERROR_WANT_WRITE == nErrorNo)||(SSL_ERROR_WANT_READ ==
nErrorNo))
{
Sleep(1000);
nTrySSLConTimes++;
if ( MAX_SSL_CON_TRY_TIMES nTrySSLConTimes )
{
CleanSocket( pstSocketInfo );
return ERR;
}
continue;
}
else
{
★★★
printf([ID:%04lx]SSL_connect error, ip=%s, err:
%s\n,id_function(),szIPStr,
ERR_error_string(nErrorNo, NULL));
CleanSocket( pstSocketInfo );
return ERR;
★★★
}
}
else
{
nEndFlag = TRUE;
}
}
}
best regards
liuyb
---End Message---
SSL_connect() in 0.9.8h - memory leak, or user error?
Ahoy the list. I'm seeing a memory leak using openssl 0.9.8h (0x0090808f 28
May 2008) on Solaris 5.10 from calling SSL_connect() and am trying to nail
down the cause. I'm sure it's a PEBKAC error, but can't spot it.
The leak was identified by watching the process memory use rise during
multiple reconnects to a server, then trussing and (programatically)
matching all allocations - including CRYPTO_ - to their associated frees.
Everything is just peachy unless and until I call SSL_connect(), then I get
86372 bytes leaked per call, and can't find the combination of calls to make
to get it freed. Anything up to SSL_connect() is fine, and nothing is
required after calling it in order to see the leak.
I've isolated the behaviour in a sample client, represented by the following
code fragment. I run round a couple of times to get a steady state, then
truss one iteration of the loop and analyse the truss output. Error
checking has been elided (here) for brevity: everything works as expected
and returns the expected results. The SSL-references == 1 all the way from
SSL_new() to SSL_free() then goes to 0 after SSL_free(). I'll stress again
that with the call to SSL_connect() removed, the process is leak free, with
it added (and nothing else changed), it leaks the same amount every time.
CODE:
SSL_load_error_strings();
SSL_library_init();
RAND_load_file(/dev/urandom, 1024);
ssl_context = SSL_CTX_new(TLSv1_client_method());
SSL_CTX_set_verify(ssl_context, SSL_VERIFY_PEER, NULL);
SSL_CTX_set_verify_depth(ssl_context, 2);
SSL_CTX_set_options(ssl_context, SSL_OP_ALL|SSL_OP_NO_SSLv2);
SSL_CTX_load_verify_locations(ssl_context, ca_certificate, NULL);
while(1)
{
theSSL = SSL_new(ssl_context);
int s = socket(PF_INET, SOCK_STREAM, 0);
int on = 1; /* Turn off Nagle */
setsockopt(s, IPPROTO_TCP, TCP_NODELAY, (void *)on, sizeof(on));
connect(s, (struct sockaddr *)sin, sizeof sin);
theBIO = BIO_new_socket(s, 0);
SSL_set_bio(theSSL, theBIO, theBIO);
/* This line causes the leak. With it commented out, everything is
fine. */
SSL_connect(theSSL);
/* Here's what I've tried to persuade the memory to free. The same
* behaviour is seen with all, some or none of these calls present.
*/
/* If I make this a while(0 == shutdown) loop, SSL_shutdown() returns
* 0 indefinitely - is this my problem? */
int shutdown = SSL_shutdown(theSSL);
if(0 == shutdown) /* as recommended, call again */
shutdown = SSL_shutdown(theSSL);
/* Tried this, didn't help */
SSL_set_shutdown(theSSL, SSL_SENT_SHUTDOWN);
/* ...neither did this */
SSL_set_shutdown(theSSL, SSL_RECEIVED_SHUTDOWN);
/* ... still no luck... */
SSL_clear(theSSL);
BIO_free(theBIO);
close(s);
/* Frees everything except 86372 bytes */
SSL_free(theSSL);
printf(** Run complete - hit a key to continue
**\n);
(void)fgetc(stdin);
} // while(1)
A representation of the story from truss. Some interesting stuff is at the
start -
note that calling SSL_connect() appears to cause the SSL and BIO structures
to
leak, even though the SSL reference count goes to 0 after SSL_free().
Address 0x143f60 (1326944) of size 0x108 (264) at truss line 8, call stack:
SSL_new(0x134c10, 0x0, 0x92cec, 0xff131298)
Address 0x143650 (1324624) of size 0x20 (32) at truss line 21, call stack:
SSL_new(0x134c10, 0x0, 0x92cec, 0xff131298)
X509_VERIFY_PARAM_new(0x143ffc, 0x0, 0x0, 0x0)
Address 0x1447b8 (1329080) of size 0x40 (64) at truss line 122, call stack:
BIO_new_socket(0x4, 0x0, 0x0, 0x1326de)
BIO_new(0x12c294, 0x0, 0x0, 0x0)
Address 0x153670 (1390192) of size 0x490a (18698) at truss line 314, call
stack:
ssl3_connect(0x143f60, 0x5000, 0x122354, 0x122354)
ssl3_setup_buffers(0x143f60, 0x4000, 0x4000, 0x0)
Address 0x144ce8 (1330408) of size 0xc (12) at truss line 295, call stack:
ssl3_connect(0x143f60, 0x5000, 0x122354, 0x122354)
BUF_MEM_new(0x1, 0x4000, 0xfc00, 0x1445b4)
Address 0x15b630 (1422896) of size 0xc8 (200) at truss line 411, call stack:
ssl3_connect(0x143f60, 0x5000, 0x122354, 0x122354)
ssl3_client_hello(0x143f60, 0x15b5c0, 0x1100, 0x1110)
ssl_get_new_session(0x143f60, 0x0, 0x0, 0x0)
SSL_SESSION_new(0x0, 0x0, 0x0, 0x0)
Address 0x15a040 (1417280) of size 0x8 (8) at truss line 1203, call stack:
ssl3_connect(0x143f60, 0x5000, 0x122354, 0x122354)
ssl3_get_server_certificate(0x143f60, 0x123880, 0x1100, 0x0)
ASN1_item_d2i(0x0, 0xffbffa60, 0x3cd, 0xf2c74)
ASN1_item_ex_d2i(0xffbff9f4, 0xffbffa60, 0x3cd, 0xf2c74)
asn1_item_ex_combine_new(0xffbff9f4, 0xf2c74, 0x0, 0xffbff966)
asn1_item_ex_combine_new(0x15b704, 0xf87b8, 0x0, 0x4)
Address 0x15b168
Deadlock - SSL_Connect()
Just seeking advice/things to consider for deadlock (or 'wait') on a SSL_Connect(). Unfortunately it stalls here, so there's no return code. The project establishes a number of SSL conns between various application instances. It's in C++, where standard socket libs are used to establish the connection, SSL added via SSL_Set_Fd and then SSL_connect()/accept(). Normal sockets (i.e. without SSL) are used for local inter-proc comms - maybe this is relevant? I've been stuck for a while - and advice as to common areas/mistakes/considerations are most appreciated. Thanks! __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Deadlock - SSL_Connect()
did you try making use of non blocking fd? it cannot deadlock in if you use that. Thanks --Gayathri On Mon, Jan 16, 2012 at 10:17 AM, Nathan Smyth naf...@ymail.com wrote: Just seeking advice/things to consider for deadlock (or 'wait') on a SSL_Connect(). Unfortunately it stalls here, so there's no return code. The project establishes a number of SSL conns between various application instances. It's in C++, where standard socket libs are used to establish the connection, SSL added via SSL_Set_Fd and then SSL_connect()/accept(). Normal sockets (i.e. without SSL) are used for local inter-proc comms - maybe this is relevant? I've been stuck for a while - and advice as to common areas/mistakes/considerations are most appreciated. Thanks! __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Deadlock - SSL_Connect()
Yes, strangely this doesn't help. Actually, what I do is set the socket to non-blocking AFTER the SSL handshake, which I thought should work... Could there be some issue with numerous SSL connections between the same parties? Or maybe it's some threading issue - perhaps SSL has some special considerations? From: Gayathri Sundar suraj...@gmail.com To: openssl-users@openssl.org Sent: Monday, 16 January 2012, 16:21 Subject: Re: Deadlock - SSL_Connect() did you try making use of non blocking fd? it cannot deadlock in if you use that. Thanks --Gayathri On Mon, Jan 16, 2012 at 10:17 AM, Nathan Smyth naf...@ymail.com wrote: Just seeking advice/things to consider for deadlock (or 'wait') on a SSL_Connect(). Unfortunately it stalls here, so there's no return code. The project establishes a number of SSL conns between various application instances. It's in C++, where standard socket libs are used to establish the connection, SSL added via SSL_Set_Fd and then SSL_connect()/accept(). Normal sockets (i.e. without SSL) are used for local inter-proc comms - maybe this is relevant? I've been stuck for a while - and advice as to common areas/mistakes/considerations are most appreciated. Thanks! __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Deadlock - SSL_Connect()
you should be setting the non blocking thing before the ssl connect is called, which is part of the SSL handshake. SSL_connect will internally do socket read/write, so if its blocking then it will not come out until the underlying operation is completed. setting it after the SSL connect is done, will help only on application data read/write. Thanks --Gayathri On Mon, Jan 16, 2012 at 10:47 AM, Nathan Smyth naf...@ymail.com wrote: Yes, strangely this doesn't help. Actually, what I do is set the socket to non-blocking AFTER the SSL handshake, which I thought should work... Could there be some issue with numerous SSL connections between the same parties? Or maybe it's some threading issue - perhaps SSL has some special considerations? -- *From:* Gayathri Sundar suraj...@gmail.com *To:* openssl-users@openssl.org *Sent:* Monday, 16 January 2012, 16:21 *Subject:* Re: Deadlock - SSL_Connect() did you try making use of non blocking fd? it cannot deadlock in if you use that. Thanks --Gayathri On Mon, Jan 16, 2012 at 10:17 AM, Nathan Smyth naf...@ymail.com wrote: Just seeking advice/things to consider for deadlock (or 'wait') on a SSL_Connect(). Unfortunately it stalls here, so there's no return code. The project establishes a number of SSL conns between various application instances. It's in C++, where standard socket libs are used to establish the connection, SSL added via SSL_Set_Fd and then SSL_connect()/accept(). Normal sockets (i.e. without SSL) are used for local inter-proc comms - maybe this is relevant? I've been stuck for a while - and advice as to common areas/mistakes/considerations are most appreciated. Thanks! __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Deadlock - SSL_Connect()
On Mon January 16 2012, Nathan Smyth wrote: Yes, strangely this doesn't help. Actually, what I do is set the socket to non-blocking AFTER the SSL handshake, which I thought should work... Could there be some issue with numerous SSL connections between the same parties? Or maybe it's some threading issue - perhaps SSL has some special considerations? Like in defining the locking call backs maybe? See the OpenSSL docs for details. Mike From: Gayathri Sundar suraj...@gmail.com To: openssl-users@openssl.org Sent: Monday, 16 January 2012, 16:21 Subject: Re: Deadlock - SSL_Connect() did you try making use of non blocking fd? it cannot deadlock in if you use that. Thanks --Gayathri On Mon, Jan 16, 2012 at 10:17 AM, Nathan Smyth naf...@ymail.com wrote: Just seeking advice/things to consider for deadlock (or 'wait') on a SSL_Connect(). Unfortunately it stalls here, so there's no return code. The project establishes a number of SSL conns between various application instances. It's in C++, where standard socket libs are used to establish the connection, SSL added via SSL_Set_Fd and then SSL_connect()/accept(). Normal sockets (i.e. without SSL) are used for local inter-proc comms - maybe this is relevant? I've been stuck for a while - and advice as to common areas/mistakes/considerations are most appreciated. Thanks! __ 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
observing a crash while doing ssl_connect on linux 5.5 platform
Hello Sir/Madam, I am seeing a crash while authenticating through open ldap on linux 5.5 x86-64. The application is 32 bit multithreaded. I am using openssl0.9.8e version. Below is stack trace for same *** glibc detected *** ./cserver: free(): invalid pointer: 0xf47fa858 *** === Backtrace: = /lib/libc.so.6[0xb325a5] /lib/libc.so.6(cfree+0x59)[0xb329e9] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/liboss_t.so.9(CRYPTO_free+0x2d)[0xf7ad7f7e] /lib/libssl.so.6(ssl3_connect+0x852)[0xf6ddda32] /lib/libssl.so.6(SSL_connect+0x2a)[0xf6defc0a] /lib/libssl.so.6(ssl23_connect+0xb01)[0xf6de4431] /lib/libssl.so.6(SSL_connect+0x2a)[0xf6defc0a] /usr/lib/libldap-2.3.so.0(ldap_int_tls_start+0xac)[0xf6e6098c] /usr/lib/libldap-2.3.so.0(ldap_int_open_connection+0x1a0)[0xf6e3cce0] /usr/lib/libldap-2.3.so.0(ldap_new_connection+0xa6)[0xf6e506a6] /usr/lib/libldap-2.3.so.0(ldap_open_defconn+0x41)[0xf6e3cb11] /usr/lib/libldap-2.3.so.0(ldap_send_initial_request+0xd8)[0xf6e510b8] /usr/lib/libldap-2.3.so.0(ldap_sasl_bind+0x178)[0xf6e461d8] /usr/lib/libldap-2.3.so.0(ldap_simple_bind+0x8a)[0xf6e4675a] /lib/security/pam_ldap.so[0xf6e7bd4d] /lib/security/pam_ldap.so[0xf6e7c619] /lib/security/pam_ldap.so[0xf6e7df59] /lib/security/pam_ldap.so(pam_sm_authenticate+0x2f0)[0xf6e7e260] /lib/libpam.so.0(_pam_dispatch+0x28f)[0xf78c843f] /lib/libpam.so.0(pam_authenticate+0x51)[0xf78c7c81] /opt/bmc/common/security/bin_v3.0/linux-2-6-x86-nptl/libbmcauth.so[0xf6ed35c7] /opt/bmc/common/security/bin_v3.0/linux-2-6-x86-nptl/libbmcauth.so(BAA_ImportLoginUser+0x100)[0xf6ed470a] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/liboss_t.so.9(BAA_LoginUser+0x21)[0xf7b3c9a0] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/liboss_t.so.9(_ZN17OSS_BaaAuthObject13checkPasswordEP11BAA_SESSIONRK11I18n_StringRK11bmc_string8+0x65)[0xf7ace8b9] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/liboss_t.so.9(_ZN17OSS_BaaAuthObject12validateUserERK11I18n_StringRK11bmc_string8S2_PP11OSS_Account+0x8c)[0xf7ace5e4] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/liboss_t.so.9(_ZN14OSS_AuthObject12validateUserERK11I18n_StringRK11bmc_string8S2_PK14OSS_EncryptionPP11OSS_AccountR9OSS_Error+0xbc)[0xf7a84e48] /opt/bmc/common/bmc/bin/linux-2-6-x86-nptl/libagentlib9_t.so.9.0[0xf7df6ca0] /opt/bmc/common/bmc/bin/linux-2-6-x86-nptl/libagentlib9_t.so.9.0(_ZN19Agent_MLMChallenger17checkPasswordAsynERP16Cpl_AuthUserDataRK12bmc_string16S5_S5_RK11bmc_string8P22Cpl_AuthSchemeCallbackRS3_Rb+0x6c)[0xf7df9118] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libauth_t.so.9(_ZN23Auth_PasswordChallenger18handleResponseAsynERP16Cpl_AuthUserDataRK12bmc_string16S5_S5_jRK15Cpl_AuthArgListRS6_RS3_P22Cpl_AuthSchemeCallbackRb+0xdb)[0xf7d739b7] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libauth_t.so.9(_ZN11Auth_Scheme20dispatchResponseAsynERK11bmc_string8RP16Cpl_AuthUserDataRK12bmc_string16S8_S8_jRK15Cpl_AuthArgListRS9_RS6_P22Cpl_AuthSchemeCallbackRb+0x61)[0xf7d76859] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libauth_t.so.9(_ZN11Auth_Scheme19handleResponseAsyncERP16Cpl_AuthUserDataRK12bmc_string16S5_S5_RK15Cpl_AuthArgListP22Cpl_AuthSchemeCallback+0x1f6)[0xf7d7662e] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libcos_t.so.9(_ZN14Cos_AuthServer12authenticateER14Cos_IPCMessageR11I18n_String+0x48c)[0xf7c51094] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libcos_t.so.9(_ZN19_Cos_ServicesObject24_handleRPCRequestMessageER14Cos_IPCMessageb+0x2fac)[0xf7ca19a8] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libcos_t.so.9(_ZN19_Cos_ServicesObject17_decodeCosMessageER14Cos_IPCMessage+0x94)[0xf7ca339c] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libcos_t.so.9(_ZN14Cos_IPCMessage7executeEv+0x22)[0xf7c655aa] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/liboss_t.so.9(_ZN15OSS_Gen_ThreadQ15dispatchMessageEP11OSS_Message+0x29)[0xf7ac9539] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libcos_t.so.9(_ZN21_Cos_ThreadPoolMember10threadProcEv+0x6a)[0xf7c43a2a] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libtss_t.so.9[0xf7db9fdf] /lib/libpthread.so.0[0xc28832] /lib/libc.so.6(clone+0x5e)[0xb9ae0e] Please suggest how we can proceed with the same. Above stack trace shows the CRYPTO_free function is from liboss_t.so but there is no such function in the library. While building the same it was linked with openssl library. Please suggest how should we diagnose the problem further. Thanks, Minal
observing a crash while doing ssl_connect
Hello Sir/Madam, I am seeing a crash while authenticating through open ldap on linux 5.5 x86-64. The application is 32 bit multithreaded. I am using openssl0.9.8e version. Below is stack trace for same *** glibc detected *** ./cserver: free(): invalid pointer: 0xf47fa858 *** === Backtrace: = /lib/libc.so.6[0xb325a5] /lib/libc.so.6(cfree+0x59)[0xb329e9] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/liboss_t.so.9(CRYPTO_free+0x2d)[0xf7ad7f7e] /lib/libssl.so.6(ssl3_connect+0x852)[0xf6ddda32] /lib/libssl.so.6(SSL_connect+0x2a)[0xf6defc0a] /lib/libssl.so.6(ssl23_connect+0xb01)[0xf6de4431] /lib/libssl.so.6(SSL_connect+0x2a)[0xf6defc0a] /usr/lib/libldap-2.3.so.0(ldap_int_tls_start+0xac)[0xf6e6098c] /usr/lib/libldap-2.3.so.0(ldap_int_open_connection+0x1a0)[0xf6e3cce0] /usr/lib/libldap-2.3.so.0(ldap_new_connection+0xa6)[0xf6e506a6] /usr/lib/libldap-2.3.so.0(ldap_open_defconn+0x41)[0xf6e3cb11] /usr/lib/libldap-2.3.so.0(ldap_send_initial_request+0xd8)[0xf6e510b8] /usr/lib/libldap-2.3.so.0(ldap_sasl_bind+0x178)[0xf6e461d8] /usr/lib/libldap-2.3.so.0(ldap_simple_bind+0x8a)[0xf6e4675a] /lib/security/pam_ldap.so[0xf6e7bd4d] /lib/security/pam_ldap.so[0xf6e7c619] /lib/security/pam_ldap.so[0xf6e7df59] /lib/security/pam_ldap.so(pam_sm_authenticate+0x2f0)[0xf6e7e260] /lib/libpam.so.0(_pam_dispatch+0x28f)[0xf78c843f] /lib/libpam.so.0(pam_authenticate+0x51)[0xf78c7c81] /opt/bmc/common/security/bin_v3.0/linux-2-6-x86-nptl/libbmcauth.so[0xf6ed35c7] /opt/bmc/common/security/bin_v3.0/linux-2-6-x86-nptl/libbmcauth.so(BAA_ImportLoginUser+0x100)[0xf6ed470a] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/liboss_t.so.9(BAA_LoginUser+0x21)[0xf7b3c9a0] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/liboss_t.so.9(_ZN17OSS_BaaAuthObject13checkPasswordEP11BAA_SESSIONRK11I18n_StringRK11bmc_string8+0x65)[0xf7ace8b9] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/liboss_t.so.9(_ZN17OSS_BaaAuthObject12validateUserERK11I18n_StringRK11bmc_string8S2_PP11OSS_Account+0x8c)[0xf7ace5e4] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/liboss_t.so.9(_ZN14OSS_AuthObject12validateUserERK11I18n_StringRK11bmc_string8S2_PK14OSS_EncryptionPP11OSS_AccountR9OSS_Error+0xbc)[0xf7a84e48] /opt/bmc/common/bmc/bin/linux-2-6-x86-nptl/libagentlib9_t.so.9.0[0xf7df6ca0] /opt/bmc/common/bmc/bin/linux-2-6-x86-nptl/libagentlib9_t.so.9.0(_ZN19Agent_MLMChallenger17checkPasswordAsynERP16Cpl_AuthUserDataRK12bmc_string16S5_S5_RK11bmc_string8P22Cpl_AuthSchemeCallbackRS3_Rb+0x6c)[0xf7df9118] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libauth_t.so.9(_ZN23Auth_PasswordChallenger18handleResponseAsynERP16Cpl_AuthUserDataRK12bmc_string16S5_S5_jRK15Cpl_AuthArgListRS6_RS3_P22Cpl_AuthSchemeCallbackRb+0xdb)[0xf7d739b7] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libauth_t.so.9(_ZN11Auth_Scheme20dispatchResponseAsynERK11bmc_string8RP16Cpl_AuthUserDataRK12bmc_string16S8_S8_jRK15Cpl_AuthArgListRS9_RS6_P22Cpl_AuthSchemeCallbackRb+0x61)[0xf7d76859] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libauth_t.so.9(_ZN11Auth_Scheme19handleResponseAsyncERP16Cpl_AuthUserDataRK12bmc_string16S5_S5_RK15Cpl_AuthArgListP22Cpl_AuthSchemeCallback+0x1f6)[0xf7d7662e] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libcos_t.so.9(_ZN14Cos_AuthServer12authenticateER14Cos_IPCMessageR11I18n_String+0x48c)[0xf7c51094] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libcos_t.so.9(_ZN19_Cos_ServicesObject24_handleRPCRequestMessageER14Cos_IPCMessageb+0x2fac)[0xf7ca19a8] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libcos_t.so.9(_ZN19_Cos_ServicesObject17_decodeCosMessageER14Cos_IPCMessage+0x94)[0xf7ca339c] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libcos_t.so.9(_ZN14Cos_IPCMessage7executeEv+0x22)[0xf7c655aa] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/liboss_t.so.9(_ZN15OSS_Gen_ThreadQ15dispatchMessageEP11OSS_Message+0x29)[0xf7ac9539] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libcos_t.so.9(_ZN21_Cos_ThreadPoolMember10threadProcEv+0x6a)[0xf7c43a2a] /opt/bmc/common/bmc/bin/linux-2-4-x86-nptl/libtss_t.so.9[0xf7db9fdf] /lib/libpthread.so.0[0xc28832] /lib/libc.so.6(clone+0x5e)[0xb9ae0e] Please suggest how we can proceed with the same. Above stack trace shows the CRYPTO_free function is from liboss_t.so but there is no such function in the library. While building the same it was linked with openssl library. Please suggest how should we diagnose the problem further. Thanks, Minal
RE: SSL_Connect call gives SSL_ERROR_WANT_READ for non blocking sockets
Since I wait until the SSL_connect() function succeeds I
wanted to know if there is a better approach.
Yes, there is a better approach, for example the one mentioned
in the manual:
* http://www.openssl.org/docs/ssl/SSL_connect.html
If the underlying BIO is non-blocking, SSL_connect() will also return
when the underlying BIO could not satisfy the needs of SSL_connect()
to continue the handshake, indicating the problem by the return value
-1. In this case a call to SSL_get_error() with the return value of
SSL_connect() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE.
The calling process then must repeat the call after taking appropriate
action to satisfy the needs of SSL_connect(). The action depends on
the underlying BIO. When using a non-blocking socket, nothing is to be
done, but select() can be used to check for the required condition.
When using a buffering BIO, like a BIO pair, data must be written into
or retrieved out of the BIO before being able to continue.
So it tells you should call SSL_connect again. If you just call it again
directly, you end up calling it thousand times for nothing but wasting
resources until data arives on the socket. Thus you shall wait for data
arriving on the socket and then call SSL_connect. To wait until data
arrived, you may use select(). So you could:
while(ret == READ || ret==WRITE) {
if (ret = WANTREAD) {
select(fd+1, fd, NULL, NULL, tv);
} else {
select(fd+1, NULL, fd, NULL, tv);
}
ret = SSL_connect(...);
}
Needed improvements include timeout management, handling select timeout
and handling of errors.
oki,
Steffen
End of message.
--
About Ingenico: Ingenico is a leading provider of payment, transaction and
business solutions, with over 15 million terminals deployed in more than 125
countries. Over 3,000 employees worldwide support merchants, banks and service
providers to optimize and secure their electronic payments solutions, develop
their offer of services and increase their point of sales revenue.
http://www.ingenico.com/.
This message may contain confidential and/or privileged information. If you
are not the addressee or authorized to receive this for the addressee, you must
not use, copy, disclose or take any action based on this message or any
information herein. If you have received this message in error, please advise
the sender immediately by reply e-mail and delete this message. Thank you for
your cooperation.
P Please consider the environment before printing this e-mail
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: SSL_Connect call gives SSL_ERROR_WANT_READ for non blocking sockets
Ohh .. ok. But I just want the SSL_connect to succeed because I want to
fetch the certificate of an HTTPS website. So after the success of
SSL_connect() function, I would call SSL_get_peer_certificate().
Since I wait until the SSL_connect() function succeeds I wanted to know if
there is a better approach.
Hope I am able to convey my understandings for these functions. If you feel
that I dont, please help in understanding the same.
~Arjun
On Mon, Nov 21, 2011 at 8:10 PM, Michael S. Zick open...@morethan.orgwrote:
On Mon November 21 2011, Arjun SM wrote:
Well yes, these are not errors. My bad for naming the variable as
'error'.
Not my point -
Your logic shows that you think the connection has failed when it has
simple not yet finished with its protocol.
Not finished because you didn't respond to the want-write and/or want-read.
Something which your code must do when using non-blocking sockets.
Mike
~Arjun
On Thu, Nov 17, 2011 at 11:50 PM, Michael S. Zick open...@morethan.org
wrote:
On Thu November 17 2011, Arjun SM wrote:
Hi,
Thanks for the reply.
I have called the ssl_connect() function again after checking for
SSL_ERROR_WANT_READ
and SSL_ERROR_WANT_WRITE. But I wanted to know if I can optimize my
code.
Below is my code
int counter = 6;
while (status 0 --counter 0 )
{
if(status 0)
{
error=SSL_get_error(ssl,status);
if(error == SSL_ERROR_WANT_READ || error ==
SSL_ERROR_WANT_WRITE)
{
MessageLog.Write(SSL 1st Connect error ,
error);
But these two cases are __not__ errors,
you just need to 'read' or 'write' as indicated so the protocol can
advance.
Mike
usleep(200);
status = SSL_connect(ssl);
error=SSL_get_error(ssl,status);
MessageLog.Write(SSL 2nd Connect error ,
error);
}
else
{
break;
}
}
} // end of while
I would try for some time and break out saying unable to connect. I
am
sure
I can optimize this code by using select() but I am unable to make it
work.
If there is a better approach please do share.
~Arjun
On Tue, Nov 15, 2011 at 9:04 PM, Huaqing Wang whuaq...@gmail.com
wrote:
Hi, Arjun,
For non-blocking case, you have to handle SSL_ERROR_WANT_READ and
SSL_ERROR_WANT_WRITE
In that case you need to redo *SSL_connect.*
*
*
Huaqing
On Tue, Nov 15, 2011 at 5:51 AM, Arjun SM arjun...@gmail.com
wrote:
Hi all,
I am newbie to openssl any help is greatly appreciated.
I have a requirement of fetching the Common name (domin name )
from
the
certificate that I request from any HTTPS websites. I followed the
regular
method of
1. establish a connection with the ip address using *connect()
*system
call.
2. Use *SSL_connect()* system call to perform handshake.
3. Use *SSL_get_peer_certificate()* to get the certificate.
The problem I faced was that, the connect() call would at times
return a
errno 4 (EINTR) error . So i changed code from blocking to
non-blocking
sockets and used select() call to have a valid connection and
return
an
appropriate file descriptor.
Now the ssl_connect() call returns SSL_ERROR_WANT_READ
or SSL_ERROR_WANT_WRITE error. I am unable to make my code work by
adding a
select() even on ssl_connect() call.
If any one can please help as to how I need to use the
ssl_connect()
by
polling that would be of great help. preferred language would be
C/C++
thanks,
~Arjun
--
Thank you.
Best Regards,
Michael(Huaqing) Wang
__
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
Re: SSL_Connect call gives SSL_ERROR_WANT_READ for non blocking sockets
Well yes, these are not errors. My bad for naming the variable as 'error'.
~Arjun
On Thu, Nov 17, 2011 at 11:50 PM, Michael S. Zick open...@morethan.orgwrote:
On Thu November 17 2011, Arjun SM wrote:
Hi,
Thanks for the reply.
I have called the ssl_connect() function again after checking for
SSL_ERROR_WANT_READ
and SSL_ERROR_WANT_WRITE. But I wanted to know if I can optimize my code.
Below is my code
int counter = 6;
while (status 0 --counter 0 )
{
if(status 0)
{
error=SSL_get_error(ssl,status);
if(error == SSL_ERROR_WANT_READ || error ==
SSL_ERROR_WANT_WRITE)
{
MessageLog.Write(SSL 1st Connect error ,
error);
But these two cases are __not__ errors,
you just need to 'read' or 'write' as indicated so the protocol can
advance.
Mike
usleep(200);
status = SSL_connect(ssl);
error=SSL_get_error(ssl,status);
MessageLog.Write(SSL 2nd Connect error ,
error);
}
else
{
break;
}
}
} // end of while
I would try for some time and break out saying unable to connect. I am
sure
I can optimize this code by using select() but I am unable to make it
work.
If there is a better approach please do share.
~Arjun
On Tue, Nov 15, 2011 at 9:04 PM, Huaqing Wang whuaq...@gmail.com
wrote:
Hi, Arjun,
For non-blocking case, you have to handle SSL_ERROR_WANT_READ and
SSL_ERROR_WANT_WRITE
In that case you need to redo *SSL_connect.*
*
*
Huaqing
On Tue, Nov 15, 2011 at 5:51 AM, Arjun SM arjun...@gmail.com wrote:
Hi all,
I am newbie to openssl any help is greatly appreciated.
I have a requirement of fetching the Common name (domin name ) from
the
certificate that I request from any HTTPS websites. I followed the
regular
method of
1. establish a connection with the ip address using *connect() *system
call.
2. Use *SSL_connect()* system call to perform handshake.
3. Use *SSL_get_peer_certificate()* to get the certificate.
The problem I faced was that, the connect() call would at times
return a
errno 4 (EINTR) error . So i changed code from blocking to
non-blocking
sockets and used select() call to have a valid connection and return
an
appropriate file descriptor.
Now the ssl_connect() call returns SSL_ERROR_WANT_READ
or SSL_ERROR_WANT_WRITE error. I am unable to make my code work by
adding a
select() even on ssl_connect() call.
If any one can please help as to how I need to use the ssl_connect()
by
polling that would be of great help. preferred language would be C/C++
thanks,
~Arjun
--
Thank you.
Best Regards,
Michael(Huaqing) Wang
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: SSL_Connect call gives SSL_ERROR_WANT_READ for non blocking sockets
On Mon November 21 2011, Arjun SM wrote:
Well yes, these are not errors. My bad for naming the variable as 'error'.
Not my point -
Your logic shows that you think the connection has failed when it has
simple not yet finished with its protocol.
Not finished because you didn't respond to the want-write and/or want-read.
Something which your code must do when using non-blocking sockets.
Mike
~Arjun
On Thu, Nov 17, 2011 at 11:50 PM, Michael S. Zick open...@morethan.orgwrote:
On Thu November 17 2011, Arjun SM wrote:
Hi,
Thanks for the reply.
I have called the ssl_connect() function again after checking for
SSL_ERROR_WANT_READ
and SSL_ERROR_WANT_WRITE. But I wanted to know if I can optimize my code.
Below is my code
int counter = 6;
while (status 0 --counter 0 )
{
if(status 0)
{
error=SSL_get_error(ssl,status);
if(error == SSL_ERROR_WANT_READ || error ==
SSL_ERROR_WANT_WRITE)
{
MessageLog.Write(SSL 1st Connect error ,
error);
But these two cases are __not__ errors,
you just need to 'read' or 'write' as indicated so the protocol can
advance.
Mike
usleep(200);
status = SSL_connect(ssl);
error=SSL_get_error(ssl,status);
MessageLog.Write(SSL 2nd Connect error ,
error);
}
else
{
break;
}
}
} // end of while
I would try for some time and break out saying unable to connect. I am
sure
I can optimize this code by using select() but I am unable to make it
work.
If there is a better approach please do share.
~Arjun
On Tue, Nov 15, 2011 at 9:04 PM, Huaqing Wang whuaq...@gmail.com
wrote:
Hi, Arjun,
For non-blocking case, you have to handle SSL_ERROR_WANT_READ and
SSL_ERROR_WANT_WRITE
In that case you need to redo *SSL_connect.*
*
*
Huaqing
On Tue, Nov 15, 2011 at 5:51 AM, Arjun SM arjun...@gmail.com wrote:
Hi all,
I am newbie to openssl any help is greatly appreciated.
I have a requirement of fetching the Common name (domin name ) from
the
certificate that I request from any HTTPS websites. I followed the
regular
method of
1. establish a connection with the ip address using *connect() *system
call.
2. Use *SSL_connect()* system call to perform handshake.
3. Use *SSL_get_peer_certificate()* to get the certificate.
The problem I faced was that, the connect() call would at times
return a
errno 4 (EINTR) error . So i changed code from blocking to
non-blocking
sockets and used select() call to have a valid connection and return
an
appropriate file descriptor.
Now the ssl_connect() call returns SSL_ERROR_WANT_READ
or SSL_ERROR_WANT_WRITE error. I am unable to make my code work by
adding a
select() even on ssl_connect() call.
If any one can please help as to how I need to use the ssl_connect()
by
polling that would be of great help. preferred language would be C/C++
thanks,
~Arjun
--
Thank you.
Best Regards,
Michael(Huaqing) Wang
__
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
Re: SSL_Connect call gives SSL_ERROR_WANT_READ for non blocking sockets
Hi,
Thanks for the reply.
I have called the ssl_connect() function again after checking for
SSL_ERROR_WANT_READ
and SSL_ERROR_WANT_WRITE. But I wanted to know if I can optimize my code.
Below is my code
int counter = 6;
while (status 0 --counter 0 )
{
if(status 0)
{
error=SSL_get_error(ssl,status);
if(error == SSL_ERROR_WANT_READ || error ==
SSL_ERROR_WANT_WRITE)
{
MessageLog.Write(SSL 1st Connect error , error);
usleep(200);
status = SSL_connect(ssl);
error=SSL_get_error(ssl,status);
MessageLog.Write(SSL 2nd Connect error , error);
}
else
{
break;
}
}
} // end of while
I would try for some time and break out saying unable to connect. I am sure
I can optimize this code by using select() but I am unable to make it work.
If there is a better approach please do share.
~Arjun
On Tue, Nov 15, 2011 at 9:04 PM, Huaqing Wang whuaq...@gmail.com wrote:
Hi, Arjun,
For non-blocking case, you have to handle SSL_ERROR_WANT_READ and
SSL_ERROR_WANT_WRITE
In that case you need to redo *SSL_connect.*
*
*
Huaqing
On Tue, Nov 15, 2011 at 5:51 AM, Arjun SM arjun...@gmail.com wrote:
Hi all,
I am newbie to openssl any help is greatly appreciated.
I have a requirement of fetching the Common name (domin name ) from the
certificate that I request from any HTTPS websites. I followed the regular
method of
1. establish a connection with the ip address using *connect() *system
call.
2. Use *SSL_connect()* system call to perform handshake.
3. Use *SSL_get_peer_certificate()* to get the certificate.
The problem I faced was that, the connect() call would at times return a
errno 4 (EINTR) error . So i changed code from blocking to non-blocking
sockets and used select() call to have a valid connection and return an
appropriate file descriptor.
Now the ssl_connect() call returns SSL_ERROR_WANT_READ
or SSL_ERROR_WANT_WRITE error. I am unable to make my code work by adding a
select() even on ssl_connect() call.
If any one can please help as to how I need to use the ssl_connect() by
polling that would be of great help. preferred language would be C/C++
thanks,
~Arjun
--
Thank you.
Best Regards,
Michael(Huaqing) Wang
Re: SSL_Connect call gives SSL_ERROR_WANT_READ for non blocking sockets
On Thu November 17 2011, Arjun SM wrote:
Hi,
Thanks for the reply.
I have called the ssl_connect() function again after checking for
SSL_ERROR_WANT_READ
and SSL_ERROR_WANT_WRITE. But I wanted to know if I can optimize my code.
Below is my code
int counter = 6;
while (status 0 --counter 0 )
{
if(status 0)
{
error=SSL_get_error(ssl,status);
if(error == SSL_ERROR_WANT_READ || error ==
SSL_ERROR_WANT_WRITE)
{
MessageLog.Write(SSL 1st Connect error , error);
But these two cases are __not__ errors,
you just need to 'read' or 'write' as indicated so the protocol can advance.
Mike
usleep(200);
status = SSL_connect(ssl);
error=SSL_get_error(ssl,status);
MessageLog.Write(SSL 2nd Connect error , error);
}
else
{
break;
}
}
} // end of while
I would try for some time and break out saying unable to connect. I am sure
I can optimize this code by using select() but I am unable to make it work.
If there is a better approach please do share.
~Arjun
On Tue, Nov 15, 2011 at 9:04 PM, Huaqing Wang whuaq...@gmail.com wrote:
Hi, Arjun,
For non-blocking case, you have to handle SSL_ERROR_WANT_READ and
SSL_ERROR_WANT_WRITE
In that case you need to redo *SSL_connect.*
*
*
Huaqing
On Tue, Nov 15, 2011 at 5:51 AM, Arjun SM arjun...@gmail.com wrote:
Hi all,
I am newbie to openssl any help is greatly appreciated.
I have a requirement of fetching the Common name (domin name ) from the
certificate that I request from any HTTPS websites. I followed the regular
method of
1. establish a connection with the ip address using *connect() *system
call.
2. Use *SSL_connect()* system call to perform handshake.
3. Use *SSL_get_peer_certificate()* to get the certificate.
The problem I faced was that, the connect() call would at times return a
errno 4 (EINTR) error . So i changed code from blocking to non-blocking
sockets and used select() call to have a valid connection and return an
appropriate file descriptor.
Now the ssl_connect() call returns SSL_ERROR_WANT_READ
or SSL_ERROR_WANT_WRITE error. I am unable to make my code work by adding a
select() even on ssl_connect() call.
If any one can please help as to how I need to use the ssl_connect() by
polling that would be of great help. preferred language would be C/C++
thanks,
~Arjun
--
Thank you.
Best Regards,
Michael(Huaqing) Wang
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
SSL_Connect call gives SSL_ERROR_WANT_READ for non blocking sockets
Hi all, I am newbie to openssl any help is greatly appreciated. I have a requirement of fetching the Common name (domin name ) from the certificate that I request from any HTTPS websites. I followed the regular method of 1. establish a connection with the ip address using *connect() *system call. 2. Use *SSL_connect()* system call to perform handshake. 3. Use *SSL_get_peer_certificate()* to get the certificate. The problem I faced was that, the connect() call would at times return a errno 4 (EINTR) error . So i changed code from blocking to non-blocking sockets and used select() call to have a valid connection and return an appropriate file descriptor. Now the ssl_connect() call returns SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE error. I am unable to make my code work by adding a select() even on ssl_connect() call. If any one can please help as to how I need to use the ssl_connect() by polling that would be of great help. preferred language would be C/C++ thanks, ~Arjun
Re: SSL_Connect call gives SSL_ERROR_WANT_READ for non blocking sockets
Hi, Arjun, For non-blocking case, you have to handle SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE In that case you need to redo *SSL_connect.* * * Huaqing On Tue, Nov 15, 2011 at 5:51 AM, Arjun SM arjun...@gmail.com wrote: Hi all, I am newbie to openssl any help is greatly appreciated. I have a requirement of fetching the Common name (domin name ) from the certificate that I request from any HTTPS websites. I followed the regular method of 1. establish a connection with the ip address using *connect() *system call. 2. Use *SSL_connect()* system call to perform handshake. 3. Use *SSL_get_peer_certificate()* to get the certificate. The problem I faced was that, the connect() call would at times return a errno 4 (EINTR) error . So i changed code from blocking to non-blocking sockets and used select() call to have a valid connection and return an appropriate file descriptor. Now the ssl_connect() call returns SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE error. I am unable to make my code work by adding a select() even on ssl_connect() call. If any one can please help as to how I need to use the ssl_connect() by polling that would be of great help. preferred language would be C/C++ thanks, ~Arjun -- Thank you. Best Regards, Michael(Huaqing) Wang
SSL_connect is indicating the www.google.com certificate is expired
Hi! When I use SSL_connect with the https://www.google.com address then it is claiming that the certificate is expired even though I have checked the certificate and the issuers and anything I can find related to it to see why it might think that but it all looks correct. This only happens on Windows XP and not with all certificates as the majority of them work fine without a problem. I have tried with the latest version - OpenSSL v1.0.0e and it still occurs there. Does anyone have any idea why this could be the case for me? Any suggestions will be gratefully received :) Regards, Andy PS: To give more of a context, I am working with Qt directly here (as a developer to some extent on Qt) and thus I have not written the code that is failing myself so if it is likely to be a problem with how the code is implemented I can try and reproduce it standalone.
SSL_ERROR_ZERO_RETURN with ssl_connect
hi , iam getting ssl_error_zero_return erro when i used ssl_connect . it returns 0 and the ssl_get error functio returns SSL_ERROR_ZERO_RETURN . web search shows that solution as to retry till it works. but it might not work in every case. the issue seems to be only with 2008 windoes on vmware. can anybody provide some information on any know issue like this . tanx anandasr -- View this message in context: http://old.nabble.com/SSL_ERROR_ZERO_RETURN-with-ssl_connect-tp32462743p32462743.html Sent from the OpenSSL - User mailing list archive at Nabble.com.
Re: Query Regarding usage of SSL_Connect()
On 7/14/2011 6:17 AM, Amit Kumar wrote: Hi team, I am using SSL_Connect() in one of my projects and this SSL_connect is returning a value of -1. With SSL_get_error() i can see it is *SSL_ERROR_WANT_READ ?* * * * Now i am not understanding why this can come and if this is there then should i call SSL_Connect again. * I am really new to OpenSSL API's and learning it. Please consider me as a beginner while replying. Any help will be greatly appreciated. It means SSL_Connect has made as much forward progress as it can right now and will be able to make further forward progress when it reads some data from the server. Since you asked it not to block, it is not blocking. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Fwd: Query Regarding usage of SSL_Connect()
Hi Amit I believe you are using non-blocking call. This kind of error will come in the situatation when the SSL is still waiting for data to be available to be read. Before that it can't start processing the data. Pls send me the code snippets where it is failing. I can try to help you in this. If it is in non-blocking mode, then you put the SSL_connect in do while and continue this till SSL_pending is zero bytes or any other error comes. Whichever is earlier. This is based on my assumptions. I can provide you help only when you send your code. Take care. Sushil On Thu, Jul 14, 2011 at 6:47 PM, Amit Kumar amit.kumar...@gmail.com wrote: Hi team, I am using SSL_Connect() in one of my projects and this SSL_connect is returning a value of -1. With SSL_get_error() i can see it is *SSL_ERROR_WANT_READ ?* * * * Now i am not understanding why this can come and if this is there then should i call SSL_Connect again. * I am really new to OpenSSL API's and learning it. Please consider me as a beginner while replying. Any help will be greatly appreciated. -- Amit Kumar Engineer
Query Regarding usage of SSL_Connect()
Hi team, I am using SSL_Connect() in one of my projects and this SSL_connect is returning a value of -1. With SSL_get_error() i can see it is *SSL_ERROR_WANT_READ ?* * * * Now i am not understanding why this can come and if this is there then should i call SSL_Connect again. * I am really new to OpenSSL API's and learning it. Please consider me as a beginner while replying. Any help will be greatly appreciated. -- Amit Kumar Engineer
Re: Query Regarding usage of SSL_Connect()
Please dont expect much response to this question. Going thro the man pages of openssl will have all the necessary answers you are expecting. Do you homework before coding. Thanks --Gayathri On Thu, Jul 14, 2011 at 8:17 AM, Amit Kumar amit.kumar...@gmail.com wrote: Hi team, I am using SSL_Connect() in one of my projects and this SSL_connect is returning a value of -1. With SSL_get_error() i can see it is *SSL_ERROR_WANT_READ ?* * * * Now i am not understanding why this can come and if this is there then should i call SSL_Connect again. * I am really new to OpenSSL API's and learning it. Please consider me as a beginner while replying. Any help will be greatly appreciated. -- Amit Kumar Engineer
Re: Why my SSL_Connect() hangs at times?
On 6/11/2011 8:52 AM, kali muthu wrote: I have Linux Server which has been connected with a Windows XP client using SSL Sockets. I am able to read and write through those sockets. Good. Recently my calls to SSL_Connect() waits for long time. And yes I am using in Blocking mode. My search on that issue ended up with, I have to use non-blocking mode and have to use time outs as well. But I want the connection to be successful so as to proceed further. Only when I am done with those little transfers between the Server and the Client, I will be able to move to the next step. Hence I used blocking mode here. Sounds good. While at the start of SSL Socket programming, I let the socket connections close abruptly without releasing them (through exceptions and as a beginner's ignorance). Will that might be the reason for my client not get connected with the Server? By the way I mean that those connections may not be still cleared which makes my current SSL_Connect() call to hang? If so, can I clean up those through any command or something? It's not clear what you're talking about. What did you not do? Your SSL_Connect isn't hanging, it's blocking, because you asked it to. Or What might be reasons that make SSL_Connect to hang/wait for long? In blocking mode, SSL_Connection will block until the connection is established or until it fails definitively. This can take arbitrarily long, depending on what the other side does. And how can I establish a connection in such case when I had to use blocking mode? You are establishing a connection, right? It's just taking awhile. But you said you wanted to wait. So what's the problem exactly? DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Why my SSL_Connect() hangs at times?
From: owner-openssl-us...@openssl.org On Behalf Of kali muthu Sent: Saturday, 11 June, 2011 11:52 I have Linux Server which has been connected with a Windows XP client using SSL Sockets. I am able to read and write through those sockets. What is the server? Is it something you wrote? openssl or not? I assume you created or at least are debugging the client. Can you try another client program, like openssl commandline s_client? Do you try your client on more than one machine, or can you? Recently my calls to SSL_Connect() waits for long time. And yes I am using in Blocking mode. snip Does recently mean it used to be fast and changed to slow? If so, did you make any code or configuration changes? Or do you mean you just recently attempted this, and found it slow? Approximately how long is long? 10 seconds? 5 minutes? While at the start of SSL Socket programming, I let the socket connections close abruptly without releasing them (through exceptions and as a beginner's ignorance). [Might] those connections may not be still cleared which makes my current SSL_Connect() call to hang? I doubt it. Assuming you mean Windows close/exit without shutdown(), or Unix(?) with linger=0, either of which (usually?) causes RST, those should not leave 'leftover' control blocks at all. *Normal* shutdown sometimes (often?) leaves TIME_WAIT entries on the server side for a limited period of time, usually 1-5 minutes, as shown by netstat. For a server not coded to deal with this (by REUSEADDR or similar) it can cause listen (actually bind) to *fail* with an error, but not hang. The server might appear to hang if it retries bind until it succeeds. But even that wouldn't cause your client connects to hang; they would be refused promptly until the server manages to listen, then accepted. Or What might be reasons that make SSL_Connect to hang/wait for long? And how can I establish a connection in such case when I had to use blocking mode? Some servers check the client in rDNS at connection start; does yours, and if so is rDNS working in its environment, for your client(s)? openssl in client, and in server if using client auth, can callback for cert verification which could be doing something slow. Other SSL implementations might, but I don't know. But you should know if you coded that, or should have been told if someone else's code does so, and it shouldn't have changed by itself. The server could be doing an expensive crypto computation during the handshake, such as choosing DHE or ECDHE parameters. But this normally shouldn't have changed by itself, and on reasonable desktop hardware shouldn't be *very* long. Can you put wireshark on the XP machine (or another Windows machine on the same nonswitched network link) and monitor? That will show exactly how long the delay is and at what point in the handshake. Or openssl s_client with -msg or -debug will also show you the handshake in real time, but not with timestamps, so you'll have to watch closely with a stopwatch or similar. Blocking-mode in openssl only affects the organization of your code. It is simpler to code, but doesn't allow other concurrent things in the same program/proces. Nonblocking-mode requires somewhat more complicated code, but once coded correctly it actually executes exactly the same operations within openssl, and with the same timing modulo a few nanoseconds for somewhat more function calls and kernel calls and cache refills that no human will notice. Whatever is causing your delay, use of blocking-mode should not be a factor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Why my SSL_Connect() hangs at times?
I have Linux Server which has been connected with a Windows XP client using SSL Sockets. I am able to read and write through those sockets. Recently my calls to SSL_Connect() waits for long time. And yes I am using in Blocking mode. My search on that issue ended up with, I have to use non-blocking mode and have to use time outs as well. But I want the connection to be successful so as to proceed further. Only when I am done with those little transfers between the Server and the Client, I will be able to move to the next step. Hence I used blocking mode here. While at the start of SSL Socket programming, I let the socket connections close abruptly without releasing them (through exceptions and as a beginner's ignorance). Will that might be the reason for my client not get connected with the Server? By the way I mean that those connections may not be still cleared which makes my current SSL_Connect() call to hang? If so, can I clean up those through any command or something? Or What might be reasons that make SSL_Connect to hang/wait for long? And how can I establish a connection in such case when I had to use blocking mode? -- Regards, Kali
ssl_connect core dump in multi-threading application
Hi, I have an application which has more than 100 SSL client threads and each of those threads tried to connect to a SSL server simultaneously. Occasionally the application process got coredump on the call to ssl_connect(), please see the stack trace below for detail. *** glibc detected *** testnetwork: double free or corruption (!prev): 0x2aaaf001adf0 *** === Backtrace: = /lib64/libc.so.6[0x30896722ef] /lib64/libc.so.6[0x3089674542] /lib64/libc.so.6(realloc+0x102)[0x30896751a2] ~/openssl/lib/libcrypto.so.1.0.0(CRYPTO_realloc+0x60)[0x2b06737c1d80] ~/openssl/lib/libcrypto.so.1.0.0(lh_insert+0x176)[0x2b067382a926] ~/openssl/lib/libcrypto.so.1.0.0[0x2b067382c9c6] ~/openssl/lib/libcrypto.so.1.0.0(ERR_get_state+0x1f9)[0x2b067382cf09] ~/openssl/lib/libcrypto.so.1.0.0(ERR_clear_error+0xd)[0x2b067382d62d] ~/openssl/lib/libssl.so.1.0.0(ssl3_connect+0x31)[0x2b0673529f21] Could someone give me some suggestions about this issue? By the way, in my application, all these 100 SSL client threads share the same SSL_CTX object and the application runs under RedHat Linux. Thanks Bob
Re: ssl_connect core dump in multi-threading application
On Tue, May 31, 2011, Yan, Bob wrote: Hi, I have an application which has more than 100 SSL client threads and each of those threads tried to connect to a SSL server simultaneously. Occasionally the application process got coredump on the call to ssl_connect(), please see the stack trace below for detail. *** glibc detected *** testnetwork: double free or corruption (!prev): 0x2aaaf001adf0 *** === Backtrace: = /lib64/libc.so.6[0x30896722ef] /lib64/libc.so.6[0x3089674542] /lib64/libc.so.6(realloc+0x102)[0x30896751a2] ~/openssl/lib/libcrypto.so.1.0.0(CRYPTO_realloc+0x60)[0x2b06737c1d80] ~/openssl/lib/libcrypto.so.1.0.0(lh_insert+0x176)[0x2b067382a926] ~/openssl/lib/libcrypto.so.1.0.0[0x2b067382c9c6] ~/openssl/lib/libcrypto.so.1.0.0(ERR_get_state+0x1f9)[0x2b067382cf09] ~/openssl/lib/libcrypto.so.1.0.0(ERR_clear_error+0xd)[0x2b067382d62d] ~/openssl/lib/libssl.so.1.0.0(ssl3_connect+0x31)[0x2b0673529f21] Could someone give me some suggestions about this issue? By the way, in my application, all these 100 SSL client threads share the same SSL_CTX object and the application runs under RedHat Linux. The usual cause of something like that is problem with the locking callbacks and/or the thread ID callback. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: ssl_connect core dump in multi-threading application
Thanks Steve, Currently my test program does not setup the locking callbacks as well as the thread ID callback. In general, should I must setup them in multi-threading openssl application? If so, should the following two functions be used to setup the locking callbacks and the thread ID callback? CRYPTO_set_id_callback((unsigned long (*)())pthreads_thread_id); CRYPTO_set_locking_callback((void (*)())pthreads_locking_callback); Thanks Bob __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SSL_connect failed with FATAL FIPS SELFTEST FAILURE
Hi: Our application crashed during startup when tried to connect to the remote server via libCurl which calls SSL_connect with the following error: fips.c(146): OpenSSL internal error, assertion failed: FATAL FIPS SELFTEST FAILURE Program received signal SIGABRT, Aborted. Wondering what could be the root cause of this error? Is there any way to get more information? What would be the solution to solve the problem? Thanks a lot, -Yolanda Here is the stack trace. (gdb) bt #0 0x00f4a410 in __kernel_vsyscall () #1 0x00dbedf0 in raise () from /lib/libc.so.6 #2 0x00dc0701 in abort () from /lib/libc.so.6 #3 0x002c64da in OpenSSLDie () from /usr/local/cm/lib/libcrypto.so.0.9.8 #4 0x002b8c0c in FIPS_selftest_check () from /usr/local/cm/lib/libcrypto.so.0.9.8 #5 0x002c998f in EVP_DigestUpdate () from /usr/local/cm/lib/libcrypto.so.0.9.8 #6 0x0075eb6b in ssl3_finish_mac () from /usr/local/cm/lib/libssl.so.0.9.8 #7 0x00763e33 in ssl23_connect () from /usr/local/cm/lib/libssl.so.0.9.8 #8 0x0077063a in SSL_connect () from /usr/local/cm/lib/libssl.so.0.9.8 #9 0x009c6177 in ossl_connect_step2 (conn=0xb7b56138, sockindex=value optimized out, nonblocking=false, done=0xaf8e47c7) at ssluse.c:1539 #10 ossl_connect_common (conn=0xb7b56138, sockindex=value optimized out, nonblocking=false, done=0xaf8e47c7) at ssluse.c:1891 #11 0x009c72cd in Curl_ossl_connect (conn=0xb7b56138, sockindex=0) at ssluse.c:1932 #12 0x009d85c3 in Curl_ssl_connect (conn=0xb7b56138, sockindex=0) at sslgen.c:187 #13 0x009b8537 in Curl_http_connect (conn=0xb7b56138, done=0xaf8e4936) at http.c:1786 #14 0x009bed3b in Curl_protocol_connect (conn=0xb7b56138, protocol_done=0xaf8e4936) at url.c:2842 #15 0x009bf18b in setup_conn (conn=0xb7b56138, hostaddr=0xb7b56790, ---Type return to continue, or q return to quit--- protocol_done=0xaf8e4936) at url.c:4449 #16 0x009c1bf3 in Curl_connect (data=0xb7b44548, in_connect=0xaf8e4930, asyncp=0xaf8e4937, protocol_done=0xaf8e4936) at url.c:4525 #17 0x009ce4ba in connect_host (data=0xb7b44548) at transfer.c:2357 #18 Curl_perform (data=0xb7b44548) at transfer.c:2438 #19 0x009cf19d in curl_easy_perform (curl=0xb7b44548) at easy.c:538 #20 0x00be1bbe in CCsHttpRequest::Submit(long, TCsAutoArraychar, unsigned int) () from /opt/cisco/connection/lib/libCsHttp.so #21 0x00be256f in CCsHttpRequest::Submit(long, ICsString) () from /opt/cisco/connection/lib/libCsHttp.so #22 0x00a6defd in CCsEwsClient::makeHttpRequest(CCsString const, CCsString const, TCsAutoPtrxercesc_2_7::SAX2XMLReader, CCsString const, std::vectorCCsString, std::allocatorCCsString , long, CCsEwsCapture*, CCsString*) () from /opt/cisco/connection/lib/libCsEws.so __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_connect failed with FATAL FIPS SELFTEST FAILURE
On Sun, Mar 27, 2011, Yolanda Liu (liuyu) wrote: Hi: Our application crashed during startup when tried to connect to the remote server via libCurl which calls SSL_connect with the following error: fips.c(146): OpenSSL internal error, assertion failed: FATAL FIPS SELFTEST FAILURE Program received signal SIGABRT, Aborted. Wondering what could be the root cause of this error? Is there any way to get more information? What would be the solution to solve the problem? Looks like you're entering FIPS mode and not printing out the selftest failue reason. Most likely cause if the application is statically linked against libcrypto.a is that you aren't using fipsld to link it. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: SSL_connect( ) want read
On 3/3/2011 6:50 AM, ikuzar wrote: Hello, I have got a SSL_ERROR_WANT_READ after a call to SSL_connect. I 'd like to know what should I do exactly ? Thanks Retry the connect operation later, ideally after confirming that the underlying socket is readable. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
SSL_connect( ) want read
Hello, I have got a SSL_ERROR_WANT_READ after a call to SSL_connect. I 'd like to know what should I do exactly ? Thanks
