Re: SSL handshake failure when using "send-proxy" on HTTPS backend
2015-12-07 13:26 GMT+01:00 Lukas Tribus : > True, but its always a good idea to simplify the configuration when > troubleshooting issues like this. For testing purposes therefor, you > should try with just one server declaration (e.g. what if nginx doesn't > propagate the proxy_protocol directive correctly due to a bug?). So, yeah, It was a bug on Nginx side : https://trac.nginx.org/nginx/ticket/858 > btw: you are using unencrypted backend traffic as well, whats the reason > to encrypt some but not all of the backend traffic? The application need to receive HTTP and HTTPS requests on separate ports. Thank you all :) -- Jonathan Leroy http://www.inikup.com/ Tel: +33 (0)9 74 77 41 72
RE: SSL handshake failure when using "send-proxy" on HTTPS backend
> Both listen directives on port 8443 uses SSL. > With Nginx, listening options must be specified on only one "listen" > directive for each address:port combination. > > So the "listen 10.0.80.1:8443" directive inherit parameters from > "listen 10.0.80.1:8443 default_server ssl proxy_protocol" True, but its always a good idea to simplify the configuration when troubleshooting issues like this. For testing purposes therefor, you should try with just one server declaration (e.g. what if nginx doesn't propagate the proxy_protocol directive correctly due to a bug?). To see if haproxy is behaving correctly tcpdump the failed SSL backend session and check out how it looks on the wire. Then you will have evidence whether haproxy or nginx is behaving incorrectly. btw: you are using unencrypted backend traffic as well, whats the reason to encrypt some but not all of the backend traffic? Regards, Lukas
Re: SSL handshake failure when using "send-proxy" on HTTPS backend
2015-12-06 12:25 GMT+01:00 Lukas Erlacher : > I can't find an obvious error with this. When I tried combining SSL and > proxy protocol in Postfix, it didn't work due to a bug in Postfix. Maybe you > should try to ask an nginx support list instead. Thanks, I'll try that. -- Jonathan Leroy http://www.inikup.com/ Tel: +33 (0)9 74 77 41 72
Re: SSL handshake failure when using "send-proxy" on HTTPS backend
2015-12-06 16:14 GMT+01:00 PiBa-NL :
> Hi,
>
> Ive never used nginx and have little experience with proxy_protocol.. But
> could it be an issue that on the same port your both using and not using
> proxy protocol? What happens if you remove the first server definition
> there?
>
> server {
> listen 10.0.80.1:8443;
> server {
> listen 10.0.80.1:8443 default_server ssl proxy_protocol;
>
> Just a thought..
Hi,
See my previous response to Lukas Tribus. With Nginx, listening
options must be specified only once for the same address+port
combinations.
--
Jonathan Leroy
http://www.inikup.com/
Tel: +33 (0)9 74 77 41 72
Re: SSL handshake failure when using "send-proxy" on HTTPS backend
Hi,
Ive never used nginx and have little experience with proxy_protocol..
But could it be an issue that on the same port your both using and not
using proxy protocol? What happens if you remove the first server
definition there?
server {
listen 10.0.80.1:8443;
server {
listen 10.0.80.1:8443 default_server ssl proxy_protocol;
Just a thought..
Regards,
PiBa-NL
Op 6-12-2015 om 12:25 schreef Lukas Erlacher:
Hi,
On 12/04/2015 04:27 PM, Jonathan Leroy - Inikup wrote:
2015-12-04 13:23 GMT+01:00 Lukas Erlacher :
Please show the nginx config.
Hi Luke,
Here's the Nginx config :
https://gist.githubusercontent.com/jleroy/ab45c328263731c46ec1/raw/69af9edc154329c113aad588ff5f9501edfd61b1/gistfile1.txt
Thanks,
I can't find an obvious error with this. When I tried combining SSL
and proxy protocol in Postfix, it didn't work due to a bug in Postfix.
Maybe you should try to ask an nginx support list instead.
Best,
Luke
Re: SSL handshake failure when using "send-proxy" on HTTPS backend
Hi, On 12/04/2015 04:27 PM, Jonathan Leroy - Inikup wrote: 2015-12-04 13:23 GMT+01:00 Lukas Erlacher : Please show the nginx config. Hi Luke, Here's the Nginx config : https://gist.githubusercontent.com/jleroy/ab45c328263731c46ec1/raw/69af9edc154329c113aad588ff5f9501edfd61b1/gistfile1.txt Thanks, I can't find an obvious error with this. When I tried combining SSL and proxy protocol in Postfix, it didn't work due to a bug in Postfix. Maybe you should try to ask an nginx support list instead. Best, Luke
Re: SSL handshake failure when using "send-proxy" on HTTPS backend
Hi, 2015-12-04 17:02 GMT+01:00 Lukas Tribus : > Well, you will have to update the first config line in nginx: > set_real_ip_from fc00::/7 > > To allow proxy connection from the ULA range. Already done. > As to the original problem: > I don't think you can use both SSL and non-SSL on the same port (8443). > > The non-SSL server block should have a dedicated port, otherwise nginx > will never know what to expect (SSL vs non-SSL, proxy or not proxy). Both listen directives on port 8443 uses SSL. With Nginx, listening options must be specified on only one "listen" directive for each address:port combination. So the "listen 10.0.80.1:8443" directive inherit parameters from "listen 10.0.80.1:8443 default_server ssl proxy_protocol" -- Jonathan Leroy http://www.inikup.com/ Tel: +33 (0)9 74 77 41 72
RE: SSL handshake failure when using "send-proxy" on HTTPS backend
> 2015-12-04 16:27 GMT+01:00 Jonathan Leroy - Inikup : >> Hi Luke, >> >> Here's the Nginx config : >> https://gist.githubusercontent.com/jleroy/ab45c328263731c46ec1/raw/69af9edc154329c113aad588ff5f9501edfd61b1/gistfile1.txt > > Now that I use ULA instead of link-local addresses, send-proxy no > longer works on HTTP backend... Well, you will have to update the first config line in nginx: set_real_ip_from fc00::/7 To allow proxy connection from the ULA range. As to the original problem: I don't think you can use both SSL and non-SSL on the same port (8443). The non-SSL server block should have a dedicated port, otherwise nginx will never know what to expect (SSL vs non-SSL, proxy or not proxy). Regards, Lukas
Re: SSL handshake failure when using "send-proxy" on HTTPS backend
2015-12-04 16:27 GMT+01:00 Jonathan Leroy - Inikup : > Hi Luke, > > Here's the Nginx config : > https://gist.githubusercontent.com/jleroy/ab45c328263731c46ec1/raw/69af9edc154329c113aad588ff5f9501edfd61b1/gistfile1.txt Now that I use ULA instead of link-local addresses, send-proxy no longer works on HTTP backend... -- Jonathan Leroy http://www.inikup.com/ Tel: +33 (0)9 74 77 41 72
Re: SSL handshake failure when using "send-proxy" on HTTPS backend
2015-12-04 13:23 GMT+01:00 Lukas Erlacher : > Please show the nginx config. Hi Luke, Here's the Nginx config : https://gist.githubusercontent.com/jleroy/ab45c328263731c46ec1/raw/69af9edc154329c113aad588ff5f9501edfd61b1/gistfile1.txt Thanks, -- Jonathan Leroy http://www.inikup.com/ Tel: +33 (0)9 74 77 41 72
Re: SSL handshake failure when using "send-proxy" on HTTPS backend
Please show the nginx config.
Best,
Luke
On 12/04/2015 03:30 AM, Jonathan Leroy - Inikup wrote:
Hi,
I have two backends named "nginx-http" and "nginx-https": the first
one handle HTTP connections, the second one HTTPS connections.
The proxy protocol works successfully on nginx-http backend:
server server1 10.0.80.1:8080 send-proxy check check-send-proxy fall
3 inter 2s weight 10
But the same configuration doen't work on nginx-https backend ("SSL
handshake failure"):
server server1 10.0.80.1:8443 ssl send-proxy check check-send-proxy
check-ssl ca-file /etc/ssl/certs/Certum_Trusted_Network_CA.pem cookie
test1 fall 3 inter 2s weight 10
As soon has I remove the "send-proxy" and "check-send-proxy"
directives everything works fine, so I think this is not an
SSL-related issue.
I use latest HAProxy and Nginx stables versions on Debian Jessie. SPDY
is not activated on Nginx side.
Thanks,
smime.p7s
Description: S/MIME Cryptographic Signature
Re: SSL handshake failure when setting up no-tlsv10
ok thanks i will upgrade the OS, even i don't feel comfortable upgrading and patching libraries outside the repo (hence never tried it.)The only thing i wanted to test was if it works with the new version of openssl but even if that is going to cause issues i will focus on upgrading the OS Thanks bryan and lukas once again From: Bryan Talbot To: Lukas Tribus Cc: Amol ; Bryan Talbot ; HAproxy Mailing Lists Sent: Wednesday, May 20, 2015 1:47 PM Subject: Re: SSL handshake failure when setting up no-tlsv10 On Wed, May 20, 2015 at 10:40 AM, Lukas Tribus wrote: > yes i figured since it is a ubuntu 10.04 machine it has old version of > openssl > > so i looked around for upgrading the openssl and found this link > https://sandilands.info/sgordon/upgrade-latest-version-openssl-on-ubuntu > > so can i just upgrade to openssl 1.0.1 and add it to the correct path > and just restart the haproxy service? Please don't. As long as you don't *exactly* know what you are doing, ONLY use your OS internal packaging system and don't follow tips you find on google. This particular blog post for example makes you install a ancient version of openssl (just look at the date of the post), with numerous issues and bugs. Also you would very likely mess up your whole system. Ubuntu 10.04 is EOL, you don't use an EOL'ed OS in production, period. Upgrade to the next Ubuntu LTS edition by following the howto of your OS vendor: https://help.ubuntu.com/community/PreciseUpgrades I agree with Lukas. Unless you're an expert at building and installing customized system software, I would not recommend you do anything like that on a server you want to be stable. Upgrade your OS is your best option for sure. -Bryan
Re: SSL handshake failure when setting up no-tlsv10
On Wed, May 20, 2015 at 10:40 AM, Lukas Tribus wrote: > > yes i figured since it is a ubuntu 10.04 machine it has old version of > > openssl > > > > so i looked around for upgrading the openssl and found this link > > https://sandilands.info/sgordon/upgrade-latest-version-openssl-on-ubuntu > > > > so can i just upgrade to openssl 1.0.1 and add it to the correct path > > and just restart the haproxy service? > > Please don't. > > As long as you don't *exactly* know what you are doing, ONLY use your > OS internal packaging system and don't follow tips you find on google. > This particular blog post for example makes you install a ancient version > of openssl (just look at the date of the post), with numerous issues and > bugs. Also you would very likely mess up your whole system. > > Ubuntu 10.04 is EOL, you don't use an EOL'ed OS in production, period. > > Upgrade to the next Ubuntu LTS edition by following the howto of your > OS vendor: > https://help.ubuntu.com/community/PreciseUpgrades > > > I agree with Lukas. Unless you're an expert at building and installing customized system software, I would not recommend you do anything like that on a server you want to be stable. Upgrade your OS is your best option for sure. -Bryan
RE: SSL handshake failure when setting up no-tlsv10
> yes i figured since it is a ubuntu 10.04 machine it has old version of > openssl > > so i looked around for upgrading the openssl and found this link > https://sandilands.info/sgordon/upgrade-latest-version-openssl-on-ubuntu > > so can i just upgrade to openssl 1.0.1 and add it to the correct path > and just restart the haproxy service? Please don't. As long as you don't *exactly* know what you are doing, ONLY use your OS internal packaging system and don't follow tips you find on google. This particular blog post for example makes you install a ancient version of openssl (just look at the date of the post), with numerous issues and bugs. Also you would very likely mess up your whole system. Ubuntu 10.04 is EOL, you don't use an EOL'ed OS in production, period. Upgrade to the next Ubuntu LTS edition by following the howto of your OS vendor: https://help.ubuntu.com/community/PreciseUpgrades Lukas
Re: SSL handshake failure when setting up no-tlsv10
yes i figured since it is a ubuntu 10.04 machine it has old version of openssl so i looked around for upgrading the openssl and found this link https://sandilands.info/sgordon/upgrade-latest-version-openssl-on-ubuntu so can i just upgrade to openssl 1.0.1 and add it to the correct path and just restart the haproxy service?Do you think that would work i really liked to install haproxy from the repository instead of compiling it myself From: Bryan Talbot To: Amol ; HAproxy Mailing Lists Sent: Wednesday, May 20, 2015 1:18 PM Subject: Re: SSL handshake failure when setting up no-tlsv10 On Wed, May 20, 2015 at 10:10 AM, Amol wrote: here is the output from the commands you requested Built with OpenSSL version : OpenSSL 0.9.8k 25 Mar 2009 Running on OpenSSL version : OpenSSL 0.9.8k 25 Mar 2009 :~$ openssl version OpenSSL 0.9.8k 25 Mar 2009 The openssl version is just too old to support TLS 1.2 as you can see in the supported cipher list below. Best bet would be to upgrade to a newer release of your OS. Another option would be to compile a newer version of openssl and compile your own haproxy and statically link against the newer openssl. -Bryan :~$ openssl ciphers -v DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 DES-CBC3-MD5 SSLv2 Kx=RSA Au=RSA Enc=3DES(168) Mac=MD5 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1 DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 DES-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=DES(56) Mac=MD5 EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 export EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC2-CBC-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export :~$ From: Bryan Talbot To: Amol ; HAproxy Mailing Lists Sent: Wednesday, May 20, 2015 1:04 PM Subject: Re: SSL handshake failure when setting up no-tlsv10 On Wed, May 20, 2015 at 9:39 AM, Amol wrote: Thanks you for responding and i wanted to share some more from my findings when i set ssl-default-bind-options no-sslv3 force-tlsv12 $ sudo vi /etc/haproxy/haproxy.cfg :~$ sudo /etc/init.d/haproxy restart * Restarting haproxy haproxy [ALERT] 139/122930 (8602) : parsing [/etc/haproxy/haproxy.cfg:22] : 'ssl-default-bind-options' 'force-tlsv12': library does not support protocol TLSv1.2 [ALERT] 139/122930 (8602) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg [ALERT] 139/122930 (8602) : Fatal errors found in configuration. Yes, it sounds like your openssl lib must be pretty old or is oddly configured. What does "haproxy -vv" and "openssl version" report? You can see a list of supported ciphers and protocols using "openssl ciphers -v" as well. -Bryan
Re: SSL handshake failure when setting up no-tlsv10
On Wed, May 20, 2015 at 10:10 AM, Amol wrote: > here is the output from the commands you requested > > Built with OpenSSL version : OpenSSL 0.9.8k 25 Mar 2009 > Running on OpenSSL version : OpenSSL 0.9.8k 25 Mar 2009 > > > :~$ openssl version > OpenSSL 0.9.8k 25 Mar 2009 > > > The openssl version is just too old to support TLS 1.2 as you can see in the supported cipher list below. Best bet would be to upgrade to a newer release of your OS. Another option would be to compile a newer version of openssl and compile your own haproxy and statically link against the newer openssl. -Bryan > :~$ openssl ciphers -v > DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 > DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 > AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 > EDH-RSA-DES-CBC3-SHASSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 > EDH-DSS-DES-CBC3-SHASSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 > DES-CBC3-SHASSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 > DES-CBC3-MD5SSLv2 Kx=RSA Au=RSA Enc=3DES(168) Mac=MD5 > DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 > DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 > AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 > RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 > RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 > RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 > RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 > EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 > EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1 > DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 > DES-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=DES(56) Mac=MD5 > EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 > export > EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 > export > EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 > export > EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 > export > EXP-RC2-CBC-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 > export > EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 > export > EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 > export > :~$ > > > -- > *From:* Bryan Talbot > *To:* Amol ; HAproxy Mailing Lists < > haproxy@formilux.org> > *Sent:* Wednesday, May 20, 2015 1:04 PM > > *Subject:* Re: SSL handshake failure when setting up no-tlsv10 > > On Wed, May 20, 2015 at 9:39 AM, Amol wrote: > > Thanks you for responding and i wanted to share some more from my findings > > when i set > *ssl-default-bind-options no-sslv3 force-tlsv12* > > $ sudo vi /etc/haproxy/haproxy.cfg > :~$ sudo /etc/init.d/haproxy restart > * Restarting haproxy > haproxy > [ALERT] 139/122930 (8602) : parsing [/etc/haproxy/haproxy.cfg:22] : > 'ssl-default-bind-options' 'force-tlsv12': library does not support > protocol TLSv1.2 > [ALERT] 139/122930 (8602) : Error(s) found in configuration file : > /etc/haproxy/haproxy.cfg > [ALERT] 139/122930 (8602) : Fatal errors found in configuration. > > > > Yes, it sounds like your openssl lib must be pretty old or is oddly > configured. What does "haproxy -vv" and "openssl version" report? You can > see a list of supported ciphers and protocols using "openssl ciphers -v" as > well. > > > > -Bryan > > > >
Re: SSL handshake failure when setting up no-tlsv10
here is the output from the commands you requested :~$ haproxy -vvHA-Proxy version 1.5.9 2014/11/25 Copyright 2000-2014 Willy Tarreau Build options : TARGET = linux2628 CPU = generic CC = gcc CFLAGS = OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built with zlib version : 1.2.3.3 Compression algorithms supported : identity, deflate, gzip Built with OpenSSL version : OpenSSL 0.9.8k 25 Mar 2009 Running on OpenSSL version : OpenSSL 0.9.8k 25 Mar 2009 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes Built with PCRE version : 7.8 2008-09-05 PCRE library supports JIT : no (USE_PCRE_JIT not set) Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND Available polling systems : epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result OK Total: 3 (3 usable), will use epoll. :~$ openssl version OpenSSL 0.9.8k 25 Mar 2009 :~$ openssl ciphers -v DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 DES-CBC3-MD5 SSLv2 Kx=RSA Au=RSA Enc=3DES(168) Mac=MD5 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1 DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 DES-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=DES(56) Mac=MD5 EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 export EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC2-CBC-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export :~$ From: Bryan Talbot To: Amol ; HAproxy Mailing Lists Sent: Wednesday, May 20, 2015 1:04 PM Subject: Re: SSL handshake failure when setting up no-tlsv10 On Wed, May 20, 2015 at 9:39 AM, Amol wrote: Thanks you for responding and i wanted to share some more from my findings when i set ssl-default-bind-options no-sslv3 force-tlsv12 $ sudo vi /etc/haproxy/haproxy.cfg :~$ sudo /etc/init.d/haproxy restart * Restarting haproxy haproxy [ALERT] 139/122930 (8602) : parsing [/etc/haproxy/haproxy.cfg:22] : 'ssl-default-bind-options' 'force-tlsv12': library does not support protocol TLSv1.2 [ALERT] 139/122930 (8602) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg [ALERT] 139/122930 (8602) : Fatal errors found in configuration. Yes, it sounds like your openssl lib must be pretty old or is oddly configured. What does "haproxy -vv" and "openssl version" report? You can see a list of supported ciphers and protocols using "openssl ciphers -v" as well. -Bryan
Re: SSL handshake failure when setting up no-tlsv10
On Wed, May 20, 2015 at 9:39 AM, Amol wrote: > Thanks you for responding and i wanted to share some more from my findings > > when i set > *ssl-default-bind-options no-sslv3 force-tlsv12* > > $ sudo vi /etc/haproxy/haproxy.cfg > :~$ sudo /etc/init.d/haproxy restart > * Restarting haproxy > haproxy > [ALERT] 139/122930 (8602) : parsing [/etc/haproxy/haproxy.cfg:22] : > 'ssl-default-bind-options' 'force-tlsv12': library does not support > protocol TLSv1.2 > [ALERT] 139/122930 (8602) : Error(s) found in configuration file : > /etc/haproxy/haproxy.cfg > [ALERT] 139/122930 (8602) : Fatal errors found in configuration. > Yes, it sounds like your openssl lib must be pretty old or is oddly configured. What does "haproxy -vv" and "openssl version" report? You can see a list of supported ciphers and protocols using "openssl ciphers -v" as well. -Bryan
Re: SSL handshake failure when setting up no-tlsv10
Thanks you for responding and i wanted to share some more from my findings when i set ssl-default-bind-options no-sslv3 force-tlsv12 $ sudo vi /etc/haproxy/haproxy.cfg :~$ sudo /etc/init.d/haproxy restart * Restarting haproxy haproxy [ALERT] 139/122930 (8602) : parsing [/etc/haproxy/haproxy.cfg:22] : 'ssl-default-bind-options' 'force-tlsv12': library does not support protocol TLSv1.2 [ALERT] 139/122930 (8602) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg [ALERT] 139/122930 (8602) : Fatal errors found in configuration. when i set ssl-default-bind-options no-sslv3 force-tlsv11 :~$ sudo /etc/init.d/haproxy restart * Restarting haproxy haproxy [ALERT] 139/122945 (8649) : parsing [/etc/haproxy/haproxy.cfg:22] : 'ssl-default-bind-options' 'force-tlsv11': library does not support protocol TLSv1.1 [ALERT] 139/122945 (8649) : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg [ALERT] 139/122945 (8649) : Fatal errors found in configuration. when i set ssl-default-bind-options no-sslv3 force-tlsv10 :~$ sudo /etc/init.d/haproxy restart * Restarting haproxy haproxy [ OK ] does that mean the it is an issue with the ubuntu installation of haproxy?is there a way to resolve this? From: Bryan Talbot To: Amol Cc: HAproxy Mailing Lists Sent: Monday, May 11, 2015 5:29 PM Subject: Re: SSL handshake failure when setting up no-tlsv10 On Mon, May 11, 2015 at 1:46 PM, Amol wrote: Hi I am using Haproxy (1.5.9) and trying to resolve a PCI compliance issue with TLS v1.0, but when i set the following options in global section of the haproxy.cfg i am getting an error in my haproxy.log and the webpage does not showup. ssl-default-bind-options no-sslv3 no-tlsv10 error in haproxy.log May 11 16:37:39 load-lb haproxy[2680]: xx.xx.xx.xx:56787 [11/May/2015:16:37:39.626] www-https/1: SSL handshake failure here is the snippet of the actual SSL settings ssl-default-bind-ciphers EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4: EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4 ssl-default-bind-options no-sslv3 no-tlsv10 tune.ssl.default-dh-param 4096 Please let me know if i am missing anything? Works for me. $ ./haproxy -vvHA-Proxy version 1.5.12-2 2015/05/11Copyright 2000-2015 Willy Tarreau Build options : TARGET = generic CPU = generic CC = gcc CFLAGS = -O2 -g -fno-strict-aliasing OPTIONS = USE_ZLIB=1 USE_OPENSSL=0 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): noBuilt with zlib version : 1.2.5Compression algorithms supported : identity, deflate, gzipBuilt with OpenSSL version : OpenSSL 1.0.2a 19 Mar 2015Running on OpenSSL version : OpenSSL 1.0.2a 19 Mar 2015OpenSSL library supports TLS extensions : yesOpenSSL library supports SNI : yesOpenSSL library supports prefer-server-ciphers : yesBuilt without PCRE support (using libc's regex instead) Available polling systems : poll : pref=200, test result OK select : pref=150, test result OKTotal: 2 (2 usable), will use poll. $ cat haproxy.cfgglobal tune.ssl.default-dh-param 4096 ssl-default-bind-options no-sslv3 no-tlsv10 ssl-default-bind-ciphers EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4 defaults timeout client 5s timeout server 5s mode http listen foo bind :4433 ssl crt ./test.pem $ ./haproxy -f ./haproxy.cfg -cConfiguration file is valid $ openssl versionOpenSSL 1.0.2a 19 Mar 2015 $ echo | openssl s_client -connect 127.0.0.1:4433 ...SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384... Maybe it's an issue with your client? -Bryan
Re: SSL handshake failure when setting up no-tlsv10
On Mon, May 11, 2015 at 1:46 PM, Amol wrote: > Hi > I am using Haproxy (1.5.9) and trying to resolve a PCI compliance issue > with TLS v1.0, but when i set the following options in global section of > the haproxy.cfg i am getting an error in my haproxy.log and the webpage > does not showup. > > ssl-default-bind-options no-sslv3 *no-tlsv10* > > *error in haproxy.log* > > May 11 16:37:39 load-lb haproxy[2680]: xx.xx.xx.xx:56787 > [11/May/2015:16:37:39.626] www-https/1: SSL handshake failure > > > here is the snippet of the actual SSL settings > > ssl-default-bind-ciphers > EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4: > EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4 > ssl-default-bind-options no-sslv3 *no-tlsv10* > tune.ssl.default-dh-param 4096 > > > Please let me know if i am missing anything? > > > Works for me. $ ./haproxy -vv HA-Proxy version 1.5.12-2 2015/05/11 Copyright 2000-2015 Willy Tarreau Build options : TARGET = generic CPU = generic CC = gcc CFLAGS = -O2 -g -fno-strict-aliasing OPTIONS = USE_ZLIB=1 USE_OPENSSL=0 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): no Built with zlib version : 1.2.5 Compression algorithms supported : identity, deflate, gzip Built with OpenSSL version : OpenSSL 1.0.2a 19 Mar 2015 Running on OpenSSL version : OpenSSL 1.0.2a 19 Mar 2015 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes Built without PCRE support (using libc's regex instead) Available polling systems : poll : pref=200, test result OK select : pref=150, test result OK Total: 2 (2 usable), will use poll. $ cat haproxy.cfg global tune.ssl.default-dh-param 4096 ssl-default-bind-options no-sslv3 no-tlsv10 ssl-default-bind-ciphers EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4 defaults timeout client 5s timeout server 5s mode http listen foo bind :4433 ssl crt ./test.pem $ ./haproxy -f ./haproxy.cfg -c Configuration file is valid $ openssl version OpenSSL 1.0.2a 19 Mar 2015 $ echo | openssl s_client -connect 127.0.0.1:4433 ... SSL-Session: Protocol : TLSv1.2 Cipher: ECDHE-RSA-AES256-GCM-SHA384 ... Maybe it's an issue with your client? -Bryan
Re: SSL handshake failure when setting up no-tlsv10
On 11/05/2015 10:46 μμ, Amol wrote: > Hi > I am using Haproxy (1.5.9) and trying to resolve a PCI compliance issue > with TLS v1.0, but when i set the following options in global section of > the haproxy.cfg i am getting an error in my haproxy.log and the webpage > does not showup. > > ssl-default-bind-options no-sslv3 *no-tlsv10* > > *error in haproxy.log* > > May 11 16:37:39 load-lb haproxy[2680]: xx.xx.xx.xx:56787 > [11/May/2015:16:37:39.626] www-https/1: SSL handshake failure > > I guess your client tried to use TLS1.0 which is disabled. > here is the snippet of the actual SSL settings > > ssl-default-bind-ciphers > EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4: > EECDH:EDH+aRSA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4 > ssl-default-bind-options no-sslv3 *no-tlsv10* > tune.ssl.default-dh-param 4096 > > > Please let me know if i am missing anything? > > > Try openssl s_client -connect site:443 -tls1_1 and should work and openssl s_client -connect site:443 -tls1 it shouldn't work as you disabled that version. Cheers, Pavlos signature.asc Description: OpenPGP digital signature
Re: SSL handshake failure
On 9/10/2014 11:43 PM, Willy Tarreau wrote: > It is also possible that they have stored locally a copy of your old cert > or maybe they have your CA's certs and you changed to a new CA to sign this > new cert. It's the same CA and intermediate cert. We suspect that they have configured it to only validate a specific certificate -- the broken one. > If they're willing to do some tests, you could probably use openssl itself > to wait for an incoming connection. Check "openssl s_server -accept " > for this. You'd get a lot more detailed info from the openssl tool itself. > Maybe you'l discover that their client is old and cannot negociate a key of > the size you're using for example. Next step could be to have them connect > to your openssl using "openssl s_client -connect" and see on their side if > anything looks wrong. I can make this suggestion, although one thing I do know is that they've got an aspx application running on Windows 2003 ... they probably know less about SSL than my immediate supervisor ... and that's saying something. I'm getting backend servers going down due to Layer6 timeout after five seconds. Is this during SSL handshaking, by chance? I can start a new thread on this issue if that's advisable. This may be the entire problem with these connections -- the Mule process on the back end may have some SSL issues. We've discussed turning SSL off on the back end .. if switching to haproxy proves useful, we may do that. Sep 11 05:21:57 localhost.localdomain haproxy[8434]: Backup Server services-ai-search-backend/aladdin is DOWN, reason: Layer6 timeout, check duration: 5001ms. 0 active and 0 backup servers left. 2 sessions active, 0 requeued, 0 remaining in queue. Sep 11 05:24:28 localhost.localdomain haproxy[8434]: Server services-ai-request-backend/fiesta is DOWN, reason: Layer6 timeout, check duration: 5004ms. 0 active and 0 backup servers left. 1 sessions active, 0 requeued, 0 remaining in queue. Thanks, Shawn
Re: SSL handshake failure
On Wed, Sep 10, 2014 at 07:09:13PM -0600, Shawn Heisey wrote: > > having two different versions, we cannot rule out a problem there. > > I did manage to do that. My captures (of my test requests) don't show an > improvement in wireshark's ability to decrypt. > > I suspect that the actual handshake problem with the customer is on their > end. The certificate we were using in production was expired and had the > wrong host name in the subject, so we got a new one with the correct name. > They couldn't connect to that either. I now have placed that expired and > incorrect cert in haproxy's configuration, and I bet they'll be able to > connect to it now. I think their client is probably very stupid. It is also possible that they have stored locally a copy of your old cert or maybe they have your CA's certs and you changed to a new CA to sign this new cert. If they're willing to do some tests, you could probably use openssl itself to wait for an incoming connection. Check "openssl s_server -accept " for this. You'd get a lot more detailed info from the openssl tool itself. Maybe you'l discover that their client is old and cannot negociate a key of the size you're using for example. Next step could be to have them connect to your openssl using "openssl s_client -connect" and see on their side if anything looks wrong. > Because they're in Japan, it takes pretty much a full day for every little > tweak we make to get tested. I hope we can get a more interactive testing > session going. Yeah I know this situation as well. On the other hand you don't waste as much time as you think because it forces you to prepare everything and review everything before going to sleep, and generally you can spot a number of issues on your side. Willy
Re: SSL handshake failure
> having two different versions, we cannot rule out a problem there. I did manage to do that. My captures (of my test requests) don't show an improvement in wireshark's ability to decrypt. I suspect that the actual handshake problem with the customer is on their end. The certificate we were using in production was expired and had the wrong host name in the subject, so we got a new one with the correct name. They couldn't connect to that either. I now have placed that expired and incorrect cert in haproxy's configuration, and I bet they'll be able to connect to it now. I think their client is probably very stupid. Because they're in Japan, it takes pretty much a full day for every little tweak we make to get tested. I hope we can get a more interactive testing session going. Thanks, Shawn
Re: SSL handshake failure
On Wed, Sep 10, 2014 at 12:20:00PM -0600, Shawn Heisey wrote: > On 9/9/2014 11:45 PM, Willy Tarreau wrote: > > It is possible that the more recent openssl lib above defined a few extra > > fields that are not supported by the older one used at runtime, resulting > > in undefined behaviour. If you cannot upgrade the production version, I > > suggest that instead you rebuild haproxy with a static openssl lib, ideally > > with the same version first, then with a more recent one (eg: 1.0.1h) if it > > continues to fail. > > > >> If I force haproxy to use sslv3, then wireshark can decrypt the packets > >> properly (when checked with a browser), but then our testing tools can't > >> connect to it. > > > > TLS supports a wide number of extensions, it is possible that wireshark > > doesn't know them all. But it's also possible that some garbage is being > > sent due to the incompatibility between the build and runtime version, > > which would explain why Wireshark cannot decrypt it. > > I managed to get a dev environment on the server where I'm running it > and get it recompiled. Unfortunately that didn't change the info in the > capture, so I'm guessing that it's something that wireshark just can't > deal with yet. The request that shows up in the capture with "Ignored > Unknown Record" on the TLSv1 packets worked perfectly from a browser -- > it was a request for a jpg image. > > This means that if I can't force sslv3, I won't be able to fully decode > the packet capture. I *can* see the requests, which may be enough. Could you try with the same version for building and runtime ? Also, can you try with a recent openssl version in this dev environment ? I'm not dismissing 0.9.8 which must work of course, but since you're having two different versions, we cannot rule out a problem there. > I'd really like to completely reload these with an OS newer than CentOS > 5. I don't know what the linux2628 target has that's not in linux26, > but I bet it's pretty nice. You'll see them in the makefile : splice(), accept4(), cpu affinity, transparent proxy. That's already nice indeed :-) But that's not compatible with RHEL5 which comes with a heavily patched 2.6.18. Willy
Re: SSL handshake failure
On 9/9/2014 11:45 PM, Willy Tarreau wrote: > It is possible that the more recent openssl lib above defined a few extra > fields that are not supported by the older one used at runtime, resulting > in undefined behaviour. If you cannot upgrade the production version, I > suggest that instead you rebuild haproxy with a static openssl lib, ideally > with the same version first, then with a more recent one (eg: 1.0.1h) if it > continues to fail. > >> If I force haproxy to use sslv3, then wireshark can decrypt the packets >> properly (when checked with a browser), but then our testing tools can't >> connect to it. > > TLS supports a wide number of extensions, it is possible that wireshark > doesn't know them all. But it's also possible that some garbage is being > sent due to the incompatibility between the build and runtime version, > which would explain why Wireshark cannot decrypt it. I managed to get a dev environment on the server where I'm running it and get it recompiled. Unfortunately that didn't change the info in the capture, so I'm guessing that it's something that wireshark just can't deal with yet. The request that shows up in the capture with "Ignored Unknown Record" on the TLSv1 packets worked perfectly from a browser -- it was a request for a jpg image. This means that if I can't force sslv3, I won't be able to fully decode the packet capture. I *can* see the requests, which may be enough. I'd really like to completely reload these with an OS newer than CentOS 5. I don't know what the linux2628 target has that's not in linux26, but I bet it's pretty nice. Thanks, Shawn
Re: SSL handshake failure
Hi Shawn,
On Tue, Sep 09, 2014 at 03:47:30PM -0600, Shawn Heisey wrote:
> I do not think this is a problem with haproxy (running 1.5.4), but I'm
> hoping haproxy can help me debug it.
>
> When I get SSL handshake failure, can haproxy be configured to log debug
> messages about WHY it failed?
Normally it will log one line indicating that a handshake has failed, with
a cause when it could determine it. The following SSL errors are diagnosed
and logged (from include/proto/connection.h) :
case CO_ER_SSL_EMPTY: return "Connection closed during SSL
handshake";
case CO_ER_SSL_ABORT: return "Connection error during SSL
handshake";
case CO_ER_SSL_TIMEOUT: return "Timeout during SSL handshake";
case CO_ER_SSL_TOO_MANY: return "Too many SSL connections";
case CO_ER_SSL_NO_MEM:return "Out of memory when initializing an
SSL connection";
case CO_ER_SSL_RENEG: return "Rejected a client-initiated SSL
renegociation attempt";
case CO_ER_SSL_CA_FAIL: return "SSL client CA chain cannot be
verified";
case CO_ER_SSL_CRT_FAIL: return "SSL client certificate not trusted";
case CO_ER_SSL_HANDSHAKE: return "SSL handshake failure";
case CO_ER_SSL_HANDSHAKE_HB: return "SSL handshake failure after
heartbeat";
case CO_ER_SSL_KILLED_HB: return "Stopped a TLSv1 heartbeat attack
(CVE-2014-0160)";
case CO_ER_SSL_NO_TARGET: return "Attempt to use SSL on an unknown
target (internal error)";
> We don't have any visibility into the
> client -- it's at a customer site in Japan, I'm in the US.
If you only get the "SSL handshake failure" message in the logs, it's very
likely that it was not possible to agree on a cipher. A sniffer in the middle
wlil help you diagnose it I guess.
> There is another question, but it's on an unrelated product. I've got
> the latest version of Wireshark (1.12.0), configured with my
> certificate's private key for SSL decrypting. The problem is that
> Wireshark is telling me that there is something wrong with the TLSv1
> frames ("Ignored Unknown Record"). I do not have decrypted responses,
> only decrypted requests, and I assume that is because of those TLSv1
> problems. The question: Is wireshark buggy, or are those TLSv1 frames
> actually problematic? The program was compiled against
> openssl-0.9.8e-27.el5_10.1 and it's running on a system with
> openssl-0.9.8e-7.el5 installed -- the production systems don't have a
> compiler or dev libraries installed, and when I attempted to install
> them, yum wouldn't work.
It is possible that the more recent openssl lib above defined a few extra
fields that are not supported by the older one used at runtime, resulting
in undefined behaviour. If you cannot upgrade the production version, I
suggest that instead you rebuild haproxy with a static openssl lib, ideally
with the same version first, then with a more recent one (eg: 1.0.1h) if it
continues to fail.
> If I force haproxy to use sslv3, then wireshark can decrypt the packets
> properly (when checked with a browser), but then our testing tools can't
> connect to it.
TLS supports a wide number of extensions, it is possible that wireshark
doesn't know them all. But it's also possible that some garbage is being
sent due to the incompatibility between the build and runtime version,
which would explain why Wireshark cannot decrypt it.
Regards,
Willy
RE: SSL handshake failure
Hi, > Lukas, > > The folks that access our service via the ColdFusion CFHTTP method > report errors, because those calls fail, and thus they are not getting > the requested data. It fails sporadically for some clients or it never works for specific clients? I would suggest: - collect as much informations as possible about those clients (OS, platform, ssllib, browser, sw/hw firewall + other security products) - try to find something affected clients all have in common and if possible: - try reproducing it - post the output of haproxy -vv, so we can see what openssl release you are running - catch a failed request with tcpdump (-s0 to avoid truncating the packets; write it to a pcap file, not just stdout output) This is most likely client related. Regards, Lukas
Re: SSL handshake failure
Lukas, The folks that access our service via the ColdFusion CFHTTP method report errors, because those calls fail, and thus they are not getting the requested data. -- Thomas Best, Thomas Amsler http://gplus.to/tamsler On Thu, Oct 17, 2013 at 10:41 AM, Lukas Tribus wrote: > Hi Thomas! > > > We are using HAProxy v1.5-dev19, and are seeing a lot of the following > > errors in our haproxy logs: > > > > <-- snip --> > > Oct 16 02:24:22 localhost haproxy[2473]: :44950 > > [16/Oct/2013:02:24:22.643] https-in/1: SSL handshake failure > > Oct 16 02:30:47 localhost haproxy[2473]: :37530 > > [16/Oct/2013:02:30:47.436] https-in/1: SSL handshake failure > > Oct 16 02:32:09 localhost haproxy[2473]: :32930 > > [16/Oct/2013:02:32:08.709] https-in/1: SSL handshake failure > > Oct 16 02:32:28 localhost haproxy[2473]: :38069 > > [16/Oct/2013:02:32:27.731] https-in/1: SSL handshake failure > > <-- snip --> > > > > This error occurs at a rate of 0.7%. It most often happens via > > ColdFusion CFHTTP connections. Could there be any issues with HAProxy > > or is this a client connection issue? > > Did you have an actual customer reporting issues or are you just seeing > this errors in the log? > > Until you have a reported and confirmed issue, I wouldn't worry too much. > Clients may do bogus things, have transient network issues or simply die. > All those things may generate the error above. > > Other software simply doesn't show you those errors. > > > > Lukas
RE: SSL handshake failure
Hi Thomas! > We are using HAProxy v1.5-dev19, and are seeing a lot of the following > errors in our haproxy logs: > > <-- snip --> > Oct 16 02:24:22 localhost haproxy[2473]: :44950 > [16/Oct/2013:02:24:22.643] https-in/1: SSL handshake failure > Oct 16 02:30:47 localhost haproxy[2473]: :37530 > [16/Oct/2013:02:30:47.436] https-in/1: SSL handshake failure > Oct 16 02:32:09 localhost haproxy[2473]: :32930 > [16/Oct/2013:02:32:08.709] https-in/1: SSL handshake failure > Oct 16 02:32:28 localhost haproxy[2473]: :38069 > [16/Oct/2013:02:32:27.731] https-in/1: SSL handshake failure > <-- snip --> > > This error occurs at a rate of 0.7%. It most often happens via > ColdFusion CFHTTP connections. Could there be any issues with HAProxy > or is this a client connection issue? Did you have an actual customer reporting issues or are you just seeing this errors in the log? Until you have a reported and confirmed issue, I wouldn't worry too much. Clients may do bogus things, have transient network issues or simply die. All those things may generate the error above. Other software simply doesn't show you those errors. Lukas
Re: SSL handshake failure
Baptiste, Please see my inline comments below: > It could be related to opened but unused connections from some > browsers (chrome). > We know that the "SSL handshake failures" are related to connections made by the ColdFusion CFHTTP client. So in this specific case, there are no browsers involved. > The only way to confirm this behavior, is to capture some traffic > using tcpdump and see if you get connections reseted by HAProxy due to > client timeout with no client traffic or some real SSL handshake > failure. > Do you know what the various error conditions are in the HAProxy source code, that can generate this specific "SSL handshake failure" error message? > > Do you have an IPS in front of HAProxy? > What is an IPS? We are running our service on Amazon's AWS. Traffic hits HAProxy and it load balances requests to Node.js instances. Thank you very much for your quick response and help. Best, -- Thomas Amsler > Baptiste > > > On Wed, Oct 16, 2013 at 4:45 AM, Thomas Amsler wrote: > > Hello, > > > > We are using HAProxy v1.5-dev19, and are seeing a lot of the following > > errors in our haproxy logs: > > > > <-- snip --> > > Oct 16 02:24:22 localhost haproxy[2473]: :44950 > > [16/Oct/2013:02:24:22.643] https-in/1: SSL handshake failure > > Oct 16 02:30:47 localhost haproxy[2473]: :37530 > > [16/Oct/2013:02:30:47.436] https-in/1: SSL handshake failure > > Oct 16 02:32:09 localhost haproxy[2473]: :32930 > > [16/Oct/2013:02:32:08.709] https-in/1: SSL handshake failure > > Oct 16 02:32:28 localhost haproxy[2473]: :38069 > > [16/Oct/2013:02:32:27.731] https-in/1: SSL handshake failure > > <-- snip --> > > > > This error occurs at a rate of 0.7%. It most often happens via ColdFusion > > CFHTTP connections. Could there be any issues with HAProxy or is this a > > client connection issue? > > > > Our server infrastructure handles REST as well as Socket.io (WetSocket) > > connections. > > > > > > Our config file: > > > > > > global > > nbproc 1 > > daemon > > maxconn 8192 > > log 127.0.0.1 local0 > > user ec2-user > > group ec2-user > > chroot /var/lib/haproxy > > > > defaults > > mode http > > option httplog > > log global > > # Add x-forwarded-for header. > > option forwardfor > > option http-server-close > > timeout connect 5s > > timeout client 30s > > timeout server 30s > > # Long timeout for WebSocket connections. > > timeout tunnel 1h > > > > # Redirect HTTP to HTTPS > > frontend http-in > > bind *:80 > > acl is_aggiefeed hdr_end(host) -i aggiefeed.ucdavis.edu > > redirect prefix https://aggiefeed.ucdavis.edu code 301 if > is_aggiefeed > > > > # HTTPS > > frontend https-in > > bind *:443 ssl crt /home/ec2-user/ssl/aggiefeed.pem > > default_backend servers > > errorfile 503 /home/ec2-user/errorfiles/503.http > > > > backend servers > > balance roundrobin > > cookie SERVERID insert indirect nocache > > server server1 10.0.1.100:8080 cookie server1 weight 1 maxconn 4096 > > check > > server server2 10.0.1.101:8080 cookie server2 weight 1 maxconn 4096 > > check > > > > > > > > Best, > > Thomas Amsler > > http://gplus.to/tamsler >
Re: SSL handshake failure
Hi Thomas, It could be related to opened but unused connections from some browsers (chrome). The only way to confirm this behavior, is to capture some traffic using tcpdump and see if you get connections reseted by HAProxy due to client timeout with no client traffic or some real SSL handshake failure. Do you have an IPS in front of HAProxy? Baptiste On Wed, Oct 16, 2013 at 4:45 AM, Thomas Amsler wrote: > Hello, > > We are using HAProxy v1.5-dev19, and are seeing a lot of the following > errors in our haproxy logs: > > <-- snip --> > Oct 16 02:24:22 localhost haproxy[2473]: :44950 > [16/Oct/2013:02:24:22.643] https-in/1: SSL handshake failure > Oct 16 02:30:47 localhost haproxy[2473]: :37530 > [16/Oct/2013:02:30:47.436] https-in/1: SSL handshake failure > Oct 16 02:32:09 localhost haproxy[2473]: :32930 > [16/Oct/2013:02:32:08.709] https-in/1: SSL handshake failure > Oct 16 02:32:28 localhost haproxy[2473]: :38069 > [16/Oct/2013:02:32:27.731] https-in/1: SSL handshake failure > <-- snip --> > > This error occurs at a rate of 0.7%. It most often happens via ColdFusion > CFHTTP connections. Could there be any issues with HAProxy or is this a > client connection issue? > > Our server infrastructure handles REST as well as Socket.io (WetSocket) > connections. > > > Our config file: > > > global > nbproc 1 > daemon > maxconn 8192 > log 127.0.0.1 local0 > user ec2-user > group ec2-user > chroot /var/lib/haproxy > > defaults > mode http > option httplog > log global > # Add x-forwarded-for header. > option forwardfor > option http-server-close > timeout connect 5s > timeout client 30s > timeout server 30s > # Long timeout for WebSocket connections. > timeout tunnel 1h > > # Redirect HTTP to HTTPS > frontend http-in > bind *:80 > acl is_aggiefeed hdr_end(host) -i aggiefeed.ucdavis.edu > redirect prefix https://aggiefeed.ucdavis.edu code 301 if is_aggiefeed > > # HTTPS > frontend https-in > bind *:443 ssl crt /home/ec2-user/ssl/aggiefeed.pem > default_backend servers > errorfile 503 /home/ec2-user/errorfiles/503.http > > backend servers > balance roundrobin > cookie SERVERID insert indirect nocache > server server1 10.0.1.100:8080 cookie server1 weight 1 maxconn 4096 > check > server server2 10.0.1.101:8080 cookie server2 weight 1 maxconn 4096 > check > > > > Best, > Thomas Amsler > http://gplus.to/tamsler
Re: 'SSL handshake failure' errors
Hi Merton, It is a good way to capture the packets during SSL handshake by tcpdump or wireshark from your client to find out what error happens. I have used this method in debugging SSL feature in haproxy. FYI. Best Regards, Godbach On 2013/6/20 1:46, Merton Lister wrote: Thank you Lukas. We will see whether SSLv3 improves things. Best, Merton On Wed, Jun 19, 2013 at 1:15 AM, Lukas Tribus mailto:luky...@hotmail.com>> wrote: Hi Merton! don't forget to CC the mailing-list :) > Out of the 5 possible causes you listed, we probably can't do much > about the other ones. But we can control the above two from our end. I > suppose that most 'modern' browsers nowadays should be able to do TLS > v1.0, and SSLv3 is considered as a weaker choice (But I wonder if it > will make more compatible for clients to support both TLSv1.0 and > SSLv3?). The specific ciphers we've chosen is to speed up the SSL but > it might 'screen out' some clients. The issue is probably with embedded, mobile and outdated browsers. If you have a 5 year old Windows CE phone, chances are it will connect in SSLv3 only (for example). > We also see in the log that some clients connected/handshake > successfully initially on some page, but failed the handshake in > subsequent requests to other parts of the site. Keep in mind that a browsers may open a connection to accelerate a _possible_ future HTTP transaction - and if the users doesn't request another page, the connection will just be dropped. Those optimizations in browsers can trigger warnings on the server-side. > Any suggestion on making SSL as much compatible as possible while > keeping it fast? You may enable SSLv3 again and monitor the log. Regards, Lukas
Re: 'SSL handshake failure' errors
Thank you Lukas. We will see whether SSLv3 improves things. Best, Merton On Wed, Jun 19, 2013 at 1:15 AM, Lukas Tribus wrote: > Hi Merton! > > > don't forget to CC the mailing-list :) > > > > Out of the 5 possible causes you listed, we probably can't do much > > about the other ones. But we can control the above two from our end. I > > suppose that most 'modern' browsers nowadays should be able to do TLS > > v1.0, and SSLv3 is considered as a weaker choice (But I wonder if it > > will make more compatible for clients to support both TLSv1.0 and > > SSLv3?). The specific ciphers we've chosen is to speed up the SSL but > > it might 'screen out' some clients. > > The issue is probably with embedded, mobile and outdated browsers. > If you have a 5 year old Windows CE phone, chances are it will connect > in SSLv3 only (for example). > > > > > We also see in the log that some clients connected/handshake > > successfully initially on some page, but failed the handshake in > > subsequent requests to other parts of the site. > > Keep in mind that a browsers may open a connection to accelerate a > _possible_ future HTTP transaction - and if the users doesn't request > another page, the connection will just be dropped. > > Those optimizations in browsers can trigger warnings on the server-side. > > > > > Any suggestion on making SSL as much compatible as possible while > > keeping it fast? > > You may enable SSLv3 again and monitor the log. > > > > Regards, > > Lukas
RE: 'SSL handshake failure' errors
Hi Merton! don't forget to CC the mailing-list :) > Out of the 5 possible causes you listed, we probably can't do much > about the other ones. But we can control the above two from our end. I > suppose that most 'modern' browsers nowadays should be able to do TLS > v1.0, and SSLv3 is considered as a weaker choice (But I wonder if it > will make more compatible for clients to support both TLSv1.0 and > SSLv3?). The specific ciphers we've chosen is to speed up the SSL but > it might 'screen out' some clients. The issue is probably with embedded, mobile and outdated browsers. If you have a 5 year old Windows CE phone, chances are it will connect in SSLv3 only (for example). > We also see in the log that some clients connected/handshake > successfully initially on some page, but failed the handshake in > subsequent requests to other parts of the site. Keep in mind that a browsers may open a connection to accelerate a _possible_ future HTTP transaction - and if the users doesn't request another page, the connection will just be dropped. Those optimizations in browsers can trigger warnings on the server-side. > Any suggestion on making SSL as much compatible as possible while > keeping it fast? You may enable SSLv3 again and monitor the log. Regards, Lukas
RE: 'SSL handshake failure' errors
Hi Merton! > We are seeing a fair amount of 'SSL handshake failure' errors in our > log, and we are running HAProxy 1.5-dev18. I suggest to update to dev19. There are a lot of bug fixes, including a security fix since dev18, which you want to have if this is a production box. It will not make those warnings disappear however. > Any idea what causes these 'SSL handshake failure' errors? SSL/TLS clients not completing the SSL handshake due to: - not being at least TLSv1.0 compatible (you disabled SSLv3) - not matching your ciphers (you have a pretty specific configuration) - a user hit STOP in the browser - a transient network problem - a bug somewhere > SSL handshake failure Don't look at this from a server perspective. Look at every single client with problems and troubleshoot it from there. > Given our whole site uses SSL, this is impacting usability for users. Do you have actual user reports of failing SSL handshakes or is this a conclusion you based on the log? If the former, then collect all the informations you can get from those users, like OS, SSL stack, browser version, tcpdumps of the failed handshake, etc. If the latter is the case, then don't panic - this is normal if you have a internet facing server. Check "option dontlognull" if you want to mute those warnings. Cheers, Lukas
Re: SSL handshake failure
Hi Samat, On Mon, Feb 11, 2013 at 08:23:54PM +0400, Samat Galimov wrote: > First connectin, gracefully started & closed: > 0001:https.accept(0005)=0007 from [5.9.11.40:25188] > 0002:decipher.accept(0006)=0009 from [5.9.11.40:25188] > 0002:decipher.clicls[0009:] > 0002:decipher.closed[0009:] > 0001:https.srvcls[0007:0008] > 0001:https.clicls[0007:0008] > 0001:https.closed[0007:0008] > Second one, broken > 0003:https.accept(0005)=0007 from [5.9.11.40:64633] > 0003:https.clicls[0007:0008] > 0003:https.closed[0007:0008] Yesterday we fixed an issue which happens when the openssl lib used at runtime differs from the one used to build haproxy, and which can cause such things depending on the variations between the versions. Could you please retest with latest snapshot and also send the output of "haproxy -vv" ? Thanks, Willy
Re: SSL handshake failure
First connectin, gracefully started & closed: 0001:https.accept(0005)=0007 from [5.9.11.40:25188] 0002:decipher.accept(0006)=0009 from [5.9.11.40:25188] 0002:decipher.clicls[0009:] 0002:decipher.closed[0009:] 0001:https.srvcls[0007:0008] 0001:https.clicls[0007:0008] 0001:https.closed[0007:0008] Second one, broken 0003:https.accept(0005)=0007 from [5.9.11.40:64633] 0003:https.clicls[0007:0008] 0003:https.closed[0007:0008] On Mon, Feb 11, 2013 at 1:26 PM, Emeric Brun wrote: > On 02/08/2013 08:27 PM, Samat Galimov wrote: > >> You are right. >> After I start haproxy with patch it establishes first connection >> normally, as it should. >> All following connections are randomly dropping an error as before. >> >> >> > Could you check your logs, Do you see HTTP redirects (status codes 30x) > > I suspect your servers send redirects with a clear scheme in location > (http:// instead https://). > > > >
Re: SSL handshake failure
On 02/08/2013 08:27 PM, Samat Galimov wrote: You are right. After I start haproxy with patch it establishes first connection normally, as it should. All following connections are randomly dropping an error as before. Could you check your logs, Do you see HTTP redirects (status codes 30x) I suspect your servers send redirects with a clear scheme in location (http:// instead https://).
Re: SSL handshake failure
On Sat, Feb 09, 2013 at 08:45:50PM +0400, Samat Galimov wrote: > Can I help in any way? Not yes I think, I'll check with Emeric if we can find other locations where errors might remain uncaught. Thanks! Willy
Re: SSL handshake failure
Can I help in any way? On Fri, Feb 8, 2013 at 11:29 PM, Willy Tarreau wrote: > On Fri, Feb 08, 2013 at 11:27:31PM +0400, Samat Galimov wrote: > > You are right. > > After I start haproxy with patch it establishes first connection > normally, > > as it should. > > All following connections are randomly dropping an error as before. > > OK, so maybe there are still some places where the change is needed. We'll > audit the code again to try to find something else. > > Thanks, > Willy > >
Re: SSL handshake failure
On Fri, Feb 08, 2013 at 11:27:31PM +0400, Samat Galimov wrote: > You are right. > After I start haproxy with patch it establishes first connection normally, > as it should. > All following connections are randomly dropping an error as before. OK, so maybe there are still some places where the change is needed. We'll audit the code again to try to find something else. Thanks, Willy
Re: SSL handshake failure
You are right. After I start haproxy with patch it establishes first connection normally, as it should. All following connections are randomly dropping an error as before. On Thu, Feb 7, 2013 at 11:09 PM, Willy Tarreau wrote: > On Thu, Feb 07, 2013 at 09:22:37PM +0400, Samat Galimov wrote: > > Funny, with patch applied it establishes first connection after start > > normally. > > Then old thing continues. > > I'm unsure what you mean, do you mean the patch has slightly improved the > situation but not completely ? > > Willy > >
Re: SSL handshake failure
On Thu, Feb 07, 2013 at 09:22:37PM +0400, Samat Galimov wrote: > Funny, with patch applied it establishes first connection after start > normally. > Then old thing continues. I'm unsure what you mean, do you mean the patch has slightly improved the situation but not completely ? Willy
Re: SSL handshake failure
Funny, with patch applied it establishes first connection after start normally. Then old thing continues. On Thu, Feb 7, 2013 at 6:58 PM, Willy Tarreau wrote: > On Thu, Feb 07, 2013 at 06:49:14PM +0400, Samat Galimov wrote: > > Thank you very much, overlooked your email due to filters, sorry for > delay. > > I am very happy to help, sure I would accept a patch. > > Server is available from outside world but is not heavily used ??? we > dont > > point load to it because of this SSL errors. > > > > By the way, I am using default haproxy-devel port in FreeBSD tree, so > > > http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev17.tar.gzsource > > is being used. > > OK, please find it attached. You should apply it on top of your current > source tree and rebuild. > > Thanks, > Willy > >
Re: SSL handshake failure
On Thu, Feb 07, 2013 at 06:49:14PM +0400, Samat Galimov wrote:
> Thank you very much, overlooked your email due to filters, sorry for delay.
> I am very happy to help, sure I would accept a patch.
> Server is available from outside world but is not heavily used ??? we dont
> point load to it because of this SSL errors.
>
> By the way, I am using default haproxy-devel port in FreeBSD tree, so
> http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev17.tar.gzsource
> is being used.
OK, please find it attached. You should apply it on top of your current
source tree and rebuild.
Thanks,
Willy
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 87eff2b..07b1ca7 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -128,7 +128,8 @@ int ssl_sock_verifycbk(int ok, X509_STORE_CTX *x_store)
}
if (objt_listener(conn->target)->bind_conf->ca_ignerr & (1ULL
<< err)) {
- ERR_clear_error();
+ if (ERR_peek_error())
+ ERR_clear_error();
return 1;
}
@@ -141,7 +142,8 @@ int ssl_sock_verifycbk(int ok, X509_STORE_CTX *x_store)
/* check if certificate error needs to be ignored */
if (objt_listener(conn->target)->bind_conf->crt_ignerr & (1ULL << err))
{
- ERR_clear_error();
+ if (ERR_peek_error())
+ ERR_clear_error();
return 1;
}
@@ -885,6 +887,9 @@ int ssl_sock_handshake(struct connection *conn, unsigned
int flag)
if ((conn->flags & CO_FL_CONNECTED) &&
SSL_renegotiate_pending(conn->xprt_ctx)) {
char c;
+ if (unlikely(ERR_peek_error()))
+ ERR_clear_error();
+
ret = SSL_peek(conn->xprt_ctx, &c, 1);
if (ret <= 0) {
/* handshake may have not been completed, let's find
why */
@@ -942,6 +947,9 @@ int ssl_sock_handshake(struct connection *conn, unsigned
int flag)
goto reneg_ok;
}
+ if (unlikely(ERR_peek_error()))
+ ERR_clear_error();
+
ret = SSL_do_handshake(conn->xprt_ctx);
if (ret != 1) {
/* handshake did not complete, let's find why */
@@ -1008,7 +1016,8 @@ reneg_ok:
out_error:
/* Clear openssl global errors stack */
- ERR_clear_error();
+ if (ERR_peek_error())
+ ERR_clear_error();
/* free resumed session if exists */
if (objt_server(conn->target) &&
objt_server(conn->target)->ssl_ctx.reused_sess) {
@@ -1062,6 +1071,9 @@ static int ssl_sock_to_buf(struct connection *conn,
struct buffer *buf, int coun
* EINTR too.
*/
while (try) {
+ if (unlikely(ERR_peek_error()))
+ ERR_clear_error();
+
ret = SSL_read(conn->xprt_ctx, bi_end(buf), try);
if (conn->flags & CO_FL_ERROR) {
/* CO_FL_ERROR may be set by ssl_sock_infocbk */
@@ -1084,7 +1096,8 @@ static int ssl_sock_to_buf(struct connection *conn,
struct buffer *buf, int coun
conn->flags |= CO_FL_ERROR;
/* Clear openssl global errors stack */
- ERR_clear_error();
+ if (ERR_peek_error())
+ ERR_clear_error();
}
goto read0;
}
@@ -1118,7 +1131,8 @@ static int ssl_sock_to_buf(struct connection *conn,
struct buffer *buf, int coun
return done;
out_error:
/* Clear openssl global errors stack */
- ERR_clear_error();
+ if (ERR_peek_error())
+ ERR_clear_error();
conn->flags |= CO_FL_ERROR;
return done;
@@ -1158,6 +1172,9 @@ static int ssl_sock_from_buf(struct connection *conn,
struct buffer *buf, int fl
if (buf->data + try > buf->p)
try = buf->data + try - buf->p;
+ if (unlikely(ERR_peek_error()))
+ ERR_clear_error();
+
ret = SSL_write(conn->xprt_ctx, bo_ptr(buf), try);
if (conn->flags & CO_FL_ERROR) {
/* CO_FL_ERROR may be set by ssl_sock_infocbk */
@@ -1201,7 +1218,8 @@ static int ssl_sock_from_buf(struct connection *conn,
struct buffer *buf, int fl
out_error:
/* Clear openssl global errors stack */
- ERR_clear_error();
+ if (ERR_peek_error())
+ ERR_clear_error();
conn->flags |= CO_FL_ERROR;
return done;
@@ -1226,7 +1244,8 @@ static void ssl_sock_shutw(struct connection *conn, int
clean)
/* no handshake was in progress, try a clean ssl shutdown */
if (clean && (SSL_shutdown(conn->xprt_ctx) <= 0)) {
/* Clear openssl global errors stack */
- ERR_clear_error()
Re: SSL handshake failure
Thank you very much, overlooked your email due to filters, sorry for delay.
I am very happy to help, sure I would accept a patch.
Server is available from outside world but is not heavily used — we dont
point load to it because of this SSL errors.
By the way, I am using default haproxy-devel port in FreeBSD tree, so
http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev17.tar.gzsource
is being used.
On Wed, Feb 6, 2013 at 10:56 AM, Willy Tarreau wrote:
> Hello Samat,
>
> On Tue, Feb 05, 2013 at 12:39:20PM +0400, Samat Galimov wrote:
> > Hello,
> >
> > I have very strange behaviour of HA-Proxy version 1.5-dev17 2012/12/28 on
> > FreeBSD 9.0-Stable
> >
> > % openssl s_client -debug -servername dharma.zvq.me -connect
> > dharma.zvq.me:443 /usr/local/etc
> > CONNECTED(0003)
> > write to 0x801407160 [0x801525000] (128 bytes => 128 (0x80))
> > - 16 03 01 00 7b 01 00 00-77 03 01 51 10 6a 26 66 {...w..Q.j&f
> > 0010 - e8 2b 77 63 f9 ea 25 e8-b7 cb 51 84 0a d7 0d 7c .+wc..%...Q???.|
> > 0020 - 58 2c 32 6f 0f 54 94 c6-29 57 c4 00 00 34 00 39 X,2o.T..)W???4.9
> > 0030 - 00 38 00 35 00 88 00 87-00 84 00 16 00 13 00 0a .8.5..??
> > 0040 - 00 33 00 32 00 2f 00 45-00 44 00 41 00 05 00 04 .3.2./.E.D.A???.
> > 0050 - 00 15 00 12 00 09 00 14-00 11 00 08 00 06 00 03 .??.
> > 0060 - 00 ff 01 00 00 1a 00 00-00 12 00 10 00 00 0d 64 .??d
> > 0070 - 68 61 72 6d 61 2e 7a 76-71 2e 6d 65 00 23 harma.zvq.me.#
> > 0080 -
> > read from 0x801407160 [0x801577000] (7 bytes => 0 (0x0))
> > 42642:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
> >
> failure:/mnt/jq032hgn/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_lib.c:182:
> > OpenSSL is 0.9.8q 2 Dec 2010
> >
> > It's randomly gives such a weird error, 50% chance, as I see.
>
> Are you the only one to access this service or is it in production and
> used by other people ? I'm asking because we had a similar report a few
> weeks ago of 0.9.8 on solaris experiencing random errors, and we suspected
> that the error queue was probably sometimes filled by some SSL calls
> without returning an error, and thus was not flushed.
>
> Would you accept to try a patch ? We have one to change the behaviour
> that we have still not merged due to the lack of testers experiencing
> the issue !
>
> > On server side (i run haproxy with -d) i get:
> > 000c:https.accept(0005)=0007 from [5.9.11.40:43423]
> > 000c:https.clicls[0007:0008]
> > 000c:https.closed[0007:0008]
> >
> > Here is my config:
> (...)
>
> I see nothing wrong in your configuration, and a config should not cause
> a random behaviour anyway. Also you're not in a chroot so it cannot be
> caused by a lack of entropy caused by the inability to access /dev/urandom.
>
> Willy
>
>
Re: SSL handshake failure
Hello Samat,
On Tue, Feb 05, 2013 at 12:39:20PM +0400, Samat Galimov wrote:
> Hello,
>
> I have very strange behaviour of HA-Proxy version 1.5-dev17 2012/12/28 on
> FreeBSD 9.0-Stable
>
> % openssl s_client -debug -servername dharma.zvq.me -connect
> dharma.zvq.me:443 /usr/local/etc
> CONNECTED(0003)
> write to 0x801407160 [0x801525000] (128 bytes => 128 (0x80))
> - 16 03 01 00 7b 01 00 00-77 03 01 51 10 6a 26 66 {...w..Q.j&f
> 0010 - e8 2b 77 63 f9 ea 25 e8-b7 cb 51 84 0a d7 0d 7c .+wc..%...Q???.|
> 0020 - 58 2c 32 6f 0f 54 94 c6-29 57 c4 00 00 34 00 39 X,2o.T..)W???4.9
> 0030 - 00 38 00 35 00 88 00 87-00 84 00 16 00 13 00 0a .8.5..??
> 0040 - 00 33 00 32 00 2f 00 45-00 44 00 41 00 05 00 04 .3.2./.E.D.A???.
> 0050 - 00 15 00 12 00 09 00 14-00 11 00 08 00 06 00 03 .??.
> 0060 - 00 ff 01 00 00 1a 00 00-00 12 00 10 00 00 0d 64 .??d
> 0070 - 68 61 72 6d 61 2e 7a 76-71 2e 6d 65 00 23 harma.zvq.me.#
> 0080 -
> read from 0x801407160 [0x801577000] (7 bytes => 0 (0x0))
> 42642:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
> failure:/mnt/jq032hgn/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_lib.c:182:
> OpenSSL is 0.9.8q 2 Dec 2010
>
> It's randomly gives such a weird error, 50% chance, as I see.
Are you the only one to access this service or is it in production and
used by other people ? I'm asking because we had a similar report a few
weeks ago of 0.9.8 on solaris experiencing random errors, and we suspected
that the error queue was probably sometimes filled by some SSL calls
without returning an error, and thus was not flushed.
Would you accept to try a patch ? We have one to change the behaviour
that we have still not merged due to the lack of testers experiencing
the issue !
> On server side (i run haproxy with -d) i get:
> 000c:https.accept(0005)=0007 from [5.9.11.40:43423]
> 000c:https.clicls[0007:0008]
> 000c:https.closed[0007:0008]
>
> Here is my config:
(...)
I see nothing wrong in your configuration, and a config should not cause
a random behaviour anyway. Also you're not in a chroot so it cannot be
caused by a lack of entropy caused by the inability to access /dev/urandom.
Willy
