I setup my nagios in docker container,and It working.and sendmail can send mail to me.
I find it can't send message to me one day,and I see the Log of sendmail,I get this error
nagios sendEmail.pl[15471]: ERROR => TLS setup failed: SSL connect attempt failed because of handshake problems error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
during this time,I just stop and restart my nagios container
the packages of libio-socket-ssl-perl and libnet-ssleay-perl perl also have installed.
How can I slove this problem??
Thanks very much
If you mean with sendEmail.pl this script with the last update from 2009 then you are using unsupported and broken software. It might work if you change the following line in the script:
- if (! IO::Socket::SSL->start_SSL($SERVER, SSL_version => 'SSLv3 TLSv1')) {
+ if (! IO::Socket::SSL->start_SSL($SERVER)) {
Reason for this change is that the setting of SSL_version in the code was wrong from the beginning, only that 7 years ago IO::Socket::SSL did not complain about it but simply used the first setting SSLv3. But since 4 years IO::Socket::SSL is stricter and complains about the wrong usage. Apart from that SSLv3 would not work in many cases anyway today because the protocol is disabled for security reasons.
Related
I am kind of new to perl world but my script fails when loaded via SFTP with below error ,
IN SUBROUTINE: CSRF TOKEN DECODED CONTENT:
error while setting up ssl connection (SSL connect attempt failed with unknown error error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure) at /home/rcc/perl5/lib/perl5/LWP/Protocol/https/connect/Socket.pm line 23.
Looping through csrf response array, param = [error while setting up ssl connection (SSL connect attempt failed with unknown error error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure) at /home/rcc/perl5/lib/perl5/LWP/Protocol/https/connect/Socket.pm line 23.
]
Under the assumption its because of TLS depreciation , we upgraded SSL version but still doesn't work, can someone help us understand how to fix the issue ?
Or is there a latest version of perl LWP which by upgrade can fix the issue ? repacking the current package seems to be complex.
Thanks in advance.
The SSL handling is not done directly by LWP::Protocol::connect. Instead it uses IO::Socket::SSL which then uses Net::SSLeay which then uses the linked in OpenSSL library which is not necessarily the one used by the openssl binary. The general capability to use TLS 1.2 depends on the version of OpenSSL which should be at least 1.0.1.
To get the versions of the various parts use the following code
use strict;
use IO::Socket::SSL;
printf "IO::Socket::SSL %s\n", $IO::Socket::SSL::VERSION;
printf "Net::SSLeay %s\n", $Net::SSLeay::VERSION;
printf "OpenSSL compiled %x\n", Net::SSLeay::OPENSSL_VERSION_NUMBER();
printf "OpenSSL linked %x - %s\n", Net::SSLeay::SSLeay(),
Net::SSLeay::SSLeay_version(0);
... SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Note that a TLS handshake problem can have lots of different reasons and an unsupported TLS protocol version is just one of many. No shared ciphers is another common problem at this stage of the connection.
I have a perl code that sends SOAP request through SOAP::Lite like this:
eval
{
$sresp = SOAP::Lite
->uri('http://machine/key')
->proxy('https://usr:pwd#website.com/addr/addr/remotescript.pl')
->remotescript_pl_function(#parms, $gmtime);
};
if ($#)
{
print $#;
}
After existing certificate for *.website.com has been replaced I am not getting valid responses anymore, I am getting
500 Can\'t connect to website.com:443 at localscript.pl line 123.
If I enable
$ENV{PERL_LWP_SSL_VERIFY_HOSTNAME} = 0;
everything works. But I would like to verify the SSL hostname, how can I do that, or track down the problem? (I am a little lost in this proxying).
I have c++ code with libcurl that goes along the same lines and works well. Entering https://website.com into browser works fine. Entering http://machine (machine is on local network) works.
edit 1:
Both perl -MIO::Socket::SSL=debug4 yourscript.pl and analyze-ssl.pl from p5-ssl-tools show error message 1416F086 which lead me to information that SSL certificate has "Chain issues" that have to be fixed in certificate installation.
edit 2:
After fix of the certificate is the error gone! Perfect, solved!
Here is solution mentioned in comments by Corion and Steffen Ullrich:
Running either:
https://github.com/noxxi/p5-ssl-tools script analyze-ssl.pl
perl -MIO::Socket::SSL=debug4 yourscript.pl
displayed same error: SSL connect attempt failed error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed. This pointed me to: telegram bot SSL error: SSL error {error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed} where I found that I too have "Chain issues Incomplete".
After fixing certificate the error is gone.
I can see here how to set the socket adapter for Zend_Http_Client
http://framework.zend.com/manual/1.12/en/zend.http.client.adapters.html
The examples they give are tls or sslv2.
Does anyone know what the setting is for tls1.2?
I've tried a few but I'm just guessing. I get errors along the lines of:
Unable to find the socket transport "tls1.2" - did you forget to enable it when you configured PHP?'
If I try tls on it's own I get:
Unable to Connect to tls://www.sandbox.paypal.com:443
(For others Googling this is to fix our IPN verification with PayPal which gives the following error on our SSL connection:
Error in cURL request: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
)
You were close! Set ssltransport to tlsv1.2.
$config = array(
'adapter' => 'Zend_Http_Client_Adapter_Socket',
'ssltransport' => 'tlsv1.2'
);
$client = new Zend_Http_Client('https://www.sandbox.paypal.com', $config);
$response = $client->request();
echo $response->getStatus();
Figured it out by first checking what Zend_Http_Client_Adapter_Socket uses to send HTTP requests, which turned out to be stream_socket_client(). You can run the stream_get_transports() on your system to view the list of available socket transports.
See SSL/TLS version selection in the OpenSSL changes in PHP 5.6.x migration guide for more examples of how to select specific SSL/TLS versions.
Tested with PHP 5.6 on Ubuntu 14.04 Trusty, which supports TLSv1.2 out of the box.
I'm getting "Socket Error #10060, Connection timed out" when trying to access a https link.
Here is how you can reproduce it with INDY 10.6.2.0 and OpenSSL 1.0.2d DLLs (also happens with older Indy 10 version and dlls):
create a project and add a TButton, TIdHTTP and TMemo objects to the form
add to button onclick this code:
IdHTTP1.Request.UserAgent:='Indy';
IdHTTP1.HandleRedirects:=true;
Memo1.text:=IdHTTP1.Get('https://www.itv.com');`
now compile and run it, it will download correctly the file.
BUT if you are using a service like www.smartydns.com which redirects DNS request to their server, INDY sample above will not work and fail with "Socket Error #10060, Connection timed out" message.
Have tried it with WGET too (https://eternallybored.org/misc/wget/) and in version 1.13 its initializing the SSL handshake and freezes, but works without problems with version 1.15.
So the question is, what IdHTTP settings do I have to use to make it work, or is it a bug in Indy10 ?
I'm hoping someone can help, I'm using the nagios plugin check_ilo2_health, the plugin works fine on our OpenSuSE systems but the new Ubuntu 14.04 system has issues, removing the nagios stuff and running perl, is basically this:
perl -e 'use IO::Socket::SSL qw(debug3);IO::Socket::SSL->new(SSL_hostname => "", PeerAddr=>"10.0.0.1:443", Proto=>"tcp",SSL_verify_mode => SSL_VERIFY_NONE)or die $!'
I'm connecting to an HP ILO2 with a self signed certificate and get a reply:
DEBUG: .../IO/Socket/SSL.pm:2503: new ctx 19182624
DEBUG: .../IO/Socket/SSL.pm:526: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:528: socket connected
DEBUG: .../IO/Socket/SSL.pm:550: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:586: not using SNI because hostname is unknown
DEBUG: .../IO/Socket/SSL.pm:647: Net::SSLeay::connect -> 0
DEBUG: .../IO/Socket/SSL.pm:695: connection failed - connect returned 0
DEBUG: .../IO/Socket/SSL.pm:1757: SSL connect attempt failed because of handshake problems
DEBUG: .../IO/Socket/SSL.pm:2537: free ctx 19182624 open=19182624
DEBUG: .../IO/Socket/SSL.pm:2549: OK free ctx 19182624
IO::Socket::SSL: SSL connect attempt failed because of handshake problems error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac ...propagated at -e line 1.
If I run it in curl:
curl "https://10.0.0.1" --insecure
It works returning the page from the ILO.
I want to tell perl or openSSL to ignore any certificate problems as this is a monitoring system and a lot of the servers use self signed certificates.
Any ideas of what can be done?
Versions:
Perl Version: This is perl 5, version 18, subversion 2 (v5.18.2) built for x86_64-linux-gnu-thread-multi
Crypt::SSLeay 0.72
IO::Socket::SSL 1.997
Net::SSLeay 1.66
Thanks in advance
I want to tell perl or openSSL to ignore any certificate problems as this is a monitoring system and a lot of the servers use self signed certificates.
You are doing it correctly, that is by using SSL_verify_mode of SSL_VERIFY_NONE.
IO::Socket::SSL: SSL connect attempt failed because of handshake problems error:140943FC:SSL routines:SSL3_READ_BYTES:sslv3 alert bad record mac ...propagated at -e line 1.
Strange, but I've seen other reports with "HP ILO2" and bad_record_mac.
Try to reduce the version to SSL 3.0, e.g. SSL_version => "SSLv3".
But because SSL 3.0 would not be a satisfactory solution because of POODLE I would be interested to have a look at the working SSL handshake from curl (upload to cloudshark.org).
The same error happens with Net::LDAP (which also uses IO::Socket::SSL) when connecting to a server that only supports SSLv2.
IO::Socket::SSL "auto-negotiates between SSLv2 and SSLv3" by default according to man page, so omitting SSL_version allows scripts to work with older servers.
Or, more optimistically, the script will still work when the administrator gets around to upgrading the server!