Re^2: Net::SSLeay::connect -> -1

Thanks for the hint. I tried it but the errors still persist. This is what I did:

my $ua = LWP::UserAgent->new(ssl_opts => { verify_hostname => 0, SSL_v
+erify_mode => IO::Socket::SSL::SSL_VERIFY_NONE });
[download]

Btw, on hitting google I can see mention of OCSP:

DEBUG: .../IO/Socket/SSL.pm:750: using SNI with hostname www.google.co
+m
DEBUG: .../IO/Socket/SSL.pm:785: request OCSP stapling
...
[download]

But with the server I am using there is no mention of OCSP with or without SSL_verify_mode => SSL_VERIFY_NONE. Does the following log suggest that SSL is set after a lot of failed (-1) attempts but finally the handshake is done? Because it is after that successful handshake that the server closes the connection.

DEBUG: .../IO/Socket/SSL.pm:2853: new ctx 93967426517920
DEBUG: .../IO/Socket/SSL.pm:692: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:694: socket connected
DEBUG: .../IO/Socket/SSL.pm:717: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:750: using SNI with hostname xyz.com
DEBUG: .../IO/Socket/SSL.pm:806: set socket to non-blocking to enforce
+ timeout=60
DEBUG: .../IO/Socket/SSL.pm:819: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:822: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:832: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:842: waiting for fd to become ready: SSL w
+ants a read first
DEBUG: .../IO/Socket/SSL.pm:862: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:819: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:822: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:832: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:842: waiting for fd to become ready: SSL w
+ants a read first
DEBUG: .../IO/Socket/SSL.pm:862: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:819: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:822: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:832: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:842: waiting for fd to become ready: SSL w
+ants a read first
DEBUG: .../IO/Socket/SSL.pm:862: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:819: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:822: done Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:832: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:842: waiting for fd to become ready: SSL w
+ants a read first
DEBUG: .../IO/Socket/SSL.pm:862: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:819: call Net::SSLeay::connect
DEBUG: .../IO/Socket/SSL.pm:822: done Net::SSLeay::connect -> 1
DEBUG: .../IO/Socket/SSL.pm:877: ssl handshake done
DEBUG: .../IO/Socket/SSL.pm:2875: free ctx 93967426517920 open=9396742
+6517920
DEBUG: .../IO/Socket/SSL.pm:2886: OK free ctx 93967426517920
[download]

thanks, bliako

Comment on Re^2: Net::SSLeay::connect -> -1 Select or Download Code

Replies are listed 'Best First'.
Re^3: Net::SSLeay::connect -> -1 by haj (Vicar) on Oct 23, 2018 at 22:46 UTC
Does the following log suggest that SSL is set after a lot of failed (-1) attempts but finally the handshake is done? As far as I recall a `-1` isn't a failure. It just indicates that the handshake isn't completed and yet another round of negotiation is required. So the return value `1` just says that the SSH handshake is done, but maybe server and client haven't found a common ground? During the handshake the SSL protocol version / TLS protocol version, the crypto algorithm and its parameters like forward secrecy need to be agreed upon. "Modern" web servers and "modern" LWP should easily find agreeable values, problems arise if an old or unpatched server only supports features which are considered not secure enough by a recent client - or vice versa. With OpenSSL's `s_client` you can dig into the steps of the handshake (expect lots of output): `openssl s_client -connect your.server:443 -debug` [download]	[reply] [d/l]
Re^4: Net::SSLeay::connect -> -1 by bliako (Abbot) on Oct 24, 2018 at 10:37 UTC
OK, I will check the output of your last suggestion. The server has just recently introduced "https" access, so I presume they are using something modern. I see IBM HTTP_server in the headers - don't know if that's comfort or woe. And the certificate is issued by `/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA` Would you agree that if the connection-closed-zero-data-received errors appear randomly then it is not likely that incompatibility issues are involved but rather, say, timing issues? I also tried with a fixed user-agent-string with same random problems. thanks for your help, bliako	[reply] [d/l]
Re^5: Net::SSLeay::connect -> -1 by haj (Vicar) on Oct 24, 2018 at 12:38 UTC
I admit that I've almost totally forgotten about the "random" part.... I myself have never seen timing issues (other than broken OCSP responders or certificate authorities with huge CRLs; with digicert this should not be a problem), but this is just personal experience. There are two other questions to narrow down the problem: Does it work with browsers or do they have the same random issues? If browsers work just fine, this would point to a problem with Perl's libraries but still leave the question why your client works with other HTTPS sites. Is this "one server" or something load-balanced? Check whether the server's name resolves to more than one IP address, and if so, point your client or OpenSSL's s_client to the individual IP-adresses and check whether it makes a difference.	[reply]