Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Hi Zack, On Thu, Apr 25, 2013 at 08:46:57PM +, Connelly, Zachary (CGI Federal) wrote: Lukas (et al), I pulled down the latest code and compiled (thanks for the build fix). I'm still getting the same problem with the latest code. Despite compiling with the debug options as specified we're not seeing a core dump come out yet to then do the backtrace against. I'm still looking around for it unless anyone knows what I might be missing. Let me know if there is anything else I can run and/or provide. Thanks for the trace you sent me. It would really help if you could send me the core file with the equivalent executable, and report the exact snapshot you used. I think that this crash explains why it randomly fails. Something is not working as expected, and when we're lucky, it crashes, but when we're unlucky, it probably silently uses an incorrect memory location explaining why the rest of the processing fails. The patch that was discussed in the thread you mentionned had no reason for changing anything, instead of clearing the errors unconditionally, it only cleared them if there were any. It's more of an optimization and the fact that it changed something indicates that we have a random bug somewhere. And your trace proves that ! Thanks, Willy
RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Hi! report the exact snapshot you used. He is at current HEAD by using 20130425 with c621d36ba applied manually on it (linux 2.6.18 without tproxy support). He also saw the crashes in -dev18, but I had him update the code. Thanks, Lukas
Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Hi don't understand: You said using openssl version 0.9.8y, but haproxy -vv shows OpenSSL 1.0.0a. Emeric On 04/25/2013 04:45 PM, Connelly, Zachary (CGI Federal) wrote: Lukas (et al), Here’s what I have so far: 1.use latest snapshot from [1] – *I’ll* *work on this today* 2.provide the output of haproxy –vv – *Output below* Sharing sig_handlers with pipe Sharing pendconn with pipe HA-Proxy version 1.5-dev18 2013/04/03 Copyright 2000-2013 Willy Tarreau w...@1wt.eu Build options : TARGET = linux26 CPU = generic CC = gcc CFLAGS = -g -O0 OPTIONS = USE_OPENSSL=1 USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built without zlib support (USE_ZLIB not set) Compression algorithms supported : identity Built with OpenSSL version : OpenSSL 1.0.0a 1 Jun 2010 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes 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. 3.can you tell us OS, kernel and openssl version? *Linux 5.5, 2.6.18-164.11.1.el5, openssl version 0.9.8y* 4.compile haproxy with debug and without compiler optimizations: make DEBUG=-DDEBUG_FULL CFLAGS=-g -O0 TARGET=[...] *Done* 5.catch a backtrace of the crash with gdb (see [2] if you need details) – *Will work on this once #1 is complete from above* Thanks for the assistance so far, Zack *From:*Lukas Tribus [mailto:luky...@hotmail.com] *Sent:* Wednesday, April 24, 2013 12:36 PM *To:* Connelly, Zachary (CGI Federal); Baptiste *Cc:* haproxy@formilux.org *Subject:* RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013 Hi! Please also note that the second SOAP call made that fails the handshake also causes the HAProxy server to crash. Could you: - use latest snapshot from [1] - provide the output of haproxy -vv - can you tell us OS, kernel and openssl version? - compile haproxy with debug and without compiler optimizations: make DEBUG=-DDEBUG_FULL CFLAGS=-g -O0 TARGET=[...] - catch a backtrace of the crash with gdb (see [2] if you need details) Regards, Lukas [1] http://haproxy.1wt.eu/download/1.5/src/snapshot/ [2] http://www.mail-archive.com/haproxy@formilux.org/msg09472.html
RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Emeric, I'm not sure about that either actually. We definitely only have 0.9.8~ versions on the box and I explicitly reference the 0.9.8y library when I compile the executable: TARGET=linux26 USE_PCRE=1 USE_OPENSSL=1 ADDLIB=-L/usr/local/openssl-0.9.8y/lib LDFLAGS+=-ldl Zack -Original Message- From: Emeric Brun [mailto:eb...@exceliance.fr] Sent: Friday, April 26, 2013 6:04 AM To: Connelly, Zachary (CGI Federal) Cc: Lukas Tribus; Baptiste; haproxy@formilux.org Subject: Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013 Hi don't understand: You said using openssl version 0.9.8y, but haproxy -vv shows OpenSSL 1.0.0a. Emeric On 04/25/2013 04:45 PM, Connelly, Zachary (CGI Federal) wrote: Lukas (et al), Here's what I have so far: 1.use latest snapshot from [1] - *I'll* *work on this today* 2.provide the output of haproxy -vv - *Output below* Sharing sig_handlers with pipe Sharing pendconn with pipe HA-Proxy version 1.5-dev18 2013/04/03 Copyright 2000-2013 Willy Tarreau w...@1wt.eumailto:w...@1wt.eu Build options : TARGET = linux26 CPU = generic CC = gcc CFLAGS = -g -O0 OPTIONS = USE_OPENSSL=1 USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built without zlib support (USE_ZLIB not set) Compression algorithms supported : identity Built with OpenSSL version : OpenSSL 1.0.0a 1 Jun 2010 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes 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. 3.can you tell us OS, kernel and openssl version? *Linux 5.5, 2.6.18-164.11.1.el5, openssl version 0.9.8y* 4.compile haproxy with debug and without compiler optimizations: make DEBUG=-DDEBUG_FULL CFLAGS=-g -O0 TARGET=[...] *Done* 5.catch a backtrace of the crash with gdb (see [2] if you need details) - *Will work on this once #1 is complete from above* Thanks for the assistance so far, Zack *From:*Lukas Tribus [mailto:luky...@hotmail.com] *Sent:* Wednesday, April 24, 2013 12:36 PM *To:* Connelly, Zachary (CGI Federal); Baptiste *Cc:* haproxy@formilux.orgmailto:haproxy@formilux.org *Subject:* RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013 Hi! Please also note that the second SOAP call made that fails the handshake also causes the HAProxy server to crash. Could you: - use latest snapshot from [1] - provide the output of haproxy -vv - can you tell us OS, kernel and openssl version? - compile haproxy with debug and without compiler optimizations: make DEBUG=-DDEBUG_FULL CFLAGS=-g -O0 TARGET=[...] - catch a backtrace of the crash with gdb (see [2] if you need details) Regards, Lukas [1] http://haproxy.1wt.eu/download/1.5/src/snapshot/ [2] http://www.mail-archive.com/haproxy@formilux.org/msg09472.html
Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Zack, On Fri, Apr 26, 2013 at 02:12:46PM +, Connelly, Zachary (CGI Federal) wrote: Emeric, I'm not sure about that either actually. We definitely only have 0.9.8~ versions on the box and I explicitly reference the 0.9.8y library when I compile the executable: TARGET=linux26 USE_PCRE=1 USE_OPENSSL=1 ADDLIB=-L/usr/local/openssl-0.9.8y/lib LDFLAGS+=-ldl You're missing a ADDINC somewhere, so I guess you're building with another version's headers and with this version's lib, which explains why haproxy -vv reports 1.0.0a (it reports the version used for building). We've checked with Emeric and I can confirm that the SSL struct changed between the two versions, which exactly explains the 8 bytes offset we found for ssl-sid_ctx_length which pointed to some wrong location. I have added a second control in the sources to report both the build version and the runtime version. Cheers, Willy
Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013
On Fri, Apr 26, 2013 at 06:25:38PM +0200, Willy Tarreau wrote: We've checked with Emeric and I can confirm that the SSL struct changed between the two versions, which exactly explains the 8 bytes offset we found for ssl-sid_ctx_length which pointed to some wrong location. I have added a second control in the sources to report both the build version and the runtime version. Just an update, Emeric has removed the dereference on the SSL struct so that this issue does not happen in the future. But still you need to fix your build issue anyway, and check with haproxy -vv that build and runtime versions are the same. Willy
RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Thanks Willy/Emeric! I will try and track down the OpenSSL and we have and ensure we got the right versions. I did add the ADDINC parameter to the build to explicitly point to the include linked with the lib and same error occurred. I will also download the two fixes from today and see if the dereference especially helps resolve the issue. Zack
RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Two things: 1. After taking the two patches, ran version and am definitely getting different versions. I'll have to look into how this could be with the admins some more. Built with OpenSSL version : OpenSSL 1.0.0a 1 Jun 2010 Running on OpenSSL version : OpenSSL 0.9.8y 5 Feb 2013 (VERSIONS DIFFER!) 2. The fix for the SSL dereference looks to have solved the issue! I am no longer getting a crash and SSL seems to be handling the offload correctly without issue. Thank you so much again, I really appreciate the quick support and patience (as you can probably guess I am not the strongest Linux/C developer)! Zack
Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013
On Fri, Apr 26, 2013 at 06:22:57PM +, Connelly, Zachary (CGI Federal) wrote: Two things: 1. After taking the two patches, ran version and am definitely getting different versions. I'll have to look into how this could be with the admins some more. Built with OpenSSL version : OpenSSL 1.0.0a 1 Jun 2010 Running on OpenSSL version : OpenSSL 0.9.8y 5 Feb 2013 (VERSIONS DIFFER!) 2. The fix for the SSL dereference looks to have solved the issue! I am no longer getting a crash and SSL seems to be handling the offload correctly without issue. Thank you so much again, I really appreciate the quick support and patience (as you can probably guess I am not the strongest Linux/C developer)! Thank you for the tests and reports, Zack. I tend to be confident that if it runs OK for you it should be stable, but I have no idea how your lib might handle some 1.0-only extensions. Cheers, Willy
Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Hi, If it can help, I've been in touch with Emeric about SSL handshake failure since some times now but it's maybe preferable to use the ML to share experience. I'm using the following cipher filter list : 'ALL:!SSLv2:!eNULL:!aNULL:!LOW:!EXPORT:!kECDH:!MD5:@STRENGTH' The PEM file I used is composed by the following : -BEGIN CERTIFICATE- = Leaf cert -BEGIN CERTIFICATE- = Intermediate cert -BEGIN CERTIFICATE- = Root cert -BEGIN DH PARAMETERS- = openssl dhparam 4096 result -BEGIN DSA PARAMETERS- = openssl dsaparam 4096 result -BEGIN EC PARAMETERS- = openssl ecparam -name prime256v1 result -BEGIN RSA PRIVATE KEY- = Dumbo jacket Here is the result on trying to use each cipher on the list : $ openssl ciphers -v 'ALL:!SSLv2:!eNULL:!aNULL:!LOW:!EXPORT:!kECDH:!MD5:@STRENGTH' \ | while read C dumb; do echo -n # $C openssl s_client -connect 176.31.104.63:443 -cipher $C /dev/null /dev/null 21 \ echo OK \ || echo FAIL \ done \ | sort -k 3 \ | column -t # DHE-DSS-AES128-GCM-SHA256 FAIL # DHE-DSS-AES128-SHA256 FAIL # DHE-DSS-AES128-SHA FAIL # DHE-DSS-AES256-GCM-SHA384 FAIL # DHE-DSS-AES256-SHA256 FAIL # DHE-DSS-AES256-SHA FAIL # DHE-DSS-CAMELLIA128-SHAFAIL # DHE-DSS-CAMELLIA256-SHAFAIL # DHE-DSS-SEED-SHA FAIL # ECDHE-ECDSA-AES128-GCM-SHA256 FAIL # ECDHE-ECDSA-AES128-SHA256 FAIL # ECDHE-ECDSA-AES128-SHA FAIL # ECDHE-ECDSA-AES256-GCM-SHA384 FAIL # ECDHE-ECDSA-AES256-SHA384 FAIL # ECDHE-ECDSA-AES256-SHA FAIL # ECDHE-ECDSA-DES-CBC3-SHA FAIL # ECDHE-ECDSA-RC4-SHAFAIL # EDH-DSS-DES-CBC3-SHA FAIL # PSK-3DES-EDE-CBC-SHA FAIL # PSK-AES128-CBC-SHA FAIL # PSK-AES256-CBC-SHA FAIL # PSK-RC4-SHAFAIL # SRP-DSS-3DES-EDE-CBC-SHA FAIL # SRP-DSS-AES-128-CBC-SHAFAIL # SRP-DSS-AES-256-CBC-SHAFAIL # SRP-RSA-3DES-EDE-CBC-SHA FAIL # SRP-RSA-AES-128-CBC-SHAFAIL # SRP-RSA-AES-256-CBC-SHAFAIL # AES128-GCM-SHA256 OK # AES128-SHA256 OK # AES128-SHA OK # AES256-GCM-SHA384 OK # AES256-SHA256 OK # AES256-SHA OK # CAMELLIA128-SHAOK # CAMELLIA256-SHAOK # DES-CBC3-SHA OK # DHE-RSA-AES128-GCM-SHA256 OK # DHE-RSA-AES128-SHA256 OK # DHE-RSA-AES128-SHA OK # DHE-RSA-AES256-GCM-SHA384 OK # DHE-RSA-AES256-SHA256 OK # DHE-RSA-AES256-SHA OK # DHE-RSA-CAMELLIA128-SHAOK # DHE-RSA-CAMELLIA256-SHAOK # DHE-RSA-SEED-SHA OK # ECDHE-RSA-AES128-GCM-SHA256OK # ECDHE-RSA-AES128-SHA256OK # ECDHE-RSA-AES128-SHA OK # ECDHE-RSA-AES256-GCM-SHA384OK # ECDHE-RSA-AES256-SHA384OK # ECDHE-RSA-AES256-SHA OK # ECDHE-RSA-DES-CBC3-SHA OK # ECDHE-RSA-RC4-SHA OK # EDH-RSA-DES-CBC3-SHA OK # IDEA-CBC-SHA OK # RC4-SHAOK # SEED-SHA OK On the client (openssl s_client) it give : error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:741: --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE On the server : SSL handshake failure Also, while debugging haproxy v1.5-dev18-34-gf27af0d I can see that PEM_read_bio_DHparams() called in ssl_sock_load_dh_params() return the origin (in PEM file) DH parameter and that ssl_sock_load_dh_params() return 1. beber On 2013-04-19 20:53, Connelly, Zachary (CGI Federal) wrote: HAProxy list, I am currently working to implement SSL within HAProxy using the 1.5-dev18 version. Much like the thread started by Samat Galimov [1] on 2/5/2013, I am seeing the same behavior where the first time I send a request via SSL the request is serviced and everything is fine; the next time the same request is attempted I receive 'ERROR:Exception in request: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake.' I noticed the attached code in the thread was not put into the dev18 version (I believe). Did that code end up resolving the issue or is the issue still being reviewed? I can supply my config file if that would help. Is there any way to get more info out of HAProxy to see what it is doing while it handles the SSL Handshake (the log does not seem to write anything when the request fails)? Any assistance would be appreciated. Thanks, Zack Connelly Links: -- [1] http://search.gmane.org/?author=Samat#43;Galimovamp;sort=date
RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Lukas (et al), Here's what I have so far: 1. use latest snapshot from [1] - I'll work on this today 2. provide the output of haproxy -vv - Output below Sharing sig_handlers with pipe Sharing pendconn with pipe HA-Proxy version 1.5-dev18 2013/04/03 Copyright 2000-2013 Willy Tarreau w...@1wt.eu Build options : TARGET = linux26 CPU = generic CC = gcc CFLAGS = -g -O0 OPTIONS = USE_OPENSSL=1 USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built without zlib support (USE_ZLIB not set) Compression algorithms supported : identity Built with OpenSSL version : OpenSSL 1.0.0a 1 Jun 2010 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes 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. 3. can you tell us OS, kernel and openssl version? Linux 5.5, 2.6.18-164.11.1.el5, openssl version 0.9.8y 4. compile haproxy with debug and without compiler optimizations: make DEBUG=-DDEBUG_FULL CFLAGS=-g -O0 TARGET=[...] Done 5. catch a backtrace of the crash with gdb (see [2] if you need details) - Will work on this once #1 is complete from above Thanks for the assistance so far, Zack From: Lukas Tribus [mailto:luky...@hotmail.com] Sent: Wednesday, April 24, 2013 12:36 PM To: Connelly, Zachary (CGI Federal); Baptiste Cc: haproxy@formilux.org Subject: RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013 Hi! Please also note that the second SOAP call made that fails the handshake also causes the HAProxy server to crash. Could you: - use latest snapshot from [1] - provide the output of haproxy -vv - can you tell us OS, kernel and openssl version? - compile haproxy with debug and without compiler optimizations: make DEBUG=-DDEBUG_FULL CFLAGS=-g -O0 TARGET=[...] - catch a backtrace of the crash with gdb (see [2] if you need details) Regards, Lukas [1] http://haproxy.1wt.eu/download/1.5/src/snapshot/ [2] http://www.mail-archive.com/haproxy@formilux.org/msg09472.html
RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Lukas (et al), I pulled down the latest code and compiled (thanks for the build fix). I'm still getting the same problem with the latest code. Despite compiling with the debug options as specified we're not seeing a core dump come out yet to then do the backtrace against. I'm still looking around for it unless anyone knows what I might be missing. Let me know if there is anything else I can run and/or provide. Thanks for the assistance so far, Zack From: Connelly, Zachary (CGI Federal) Sent: Thursday, April 25, 2013 10:46 AM To: 'Lukas Tribus'; Baptiste Cc: haproxy@formilux.org Subject: RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013 Lukas (et al), Here's what I have so far: 1. use latest snapshot from [1] - I'll work on this today 2. provide the output of haproxy -vv - Output below Sharing sig_handlers with pipe Sharing pendconn with pipe HA-Proxy version 1.5-dev18 2013/04/03 Copyright 2000-2013 Willy Tarreau w...@1wt.eumailto:w...@1wt.eu Build options : TARGET = linux26 CPU = generic CC = gcc CFLAGS = -g -O0 OPTIONS = USE_OPENSSL=1 USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built without zlib support (USE_ZLIB not set) Compression algorithms supported : identity Built with OpenSSL version : OpenSSL 1.0.0a 1 Jun 2010 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes 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. 3. can you tell us OS, kernel and openssl version? Linux 5.5, 2.6.18-164.11.1.el5, openssl version 0.9.8y 4. compile haproxy with debug and without compiler optimizations: make DEBUG=-DDEBUG_FULL CFLAGS=-g -O0 TARGET=[...] Done 5. catch a backtrace of the crash with gdb (see [2] if you need details) - Will work on this once #1 is complete from above Thanks for the assistance so far, Zack From: Lukas Tribus [mailto:luky...@hotmail.com] Sent: Wednesday, April 24, 2013 12:36 PM To: Connelly, Zachary (CGI Federal); Baptiste Cc: haproxy@formilux.orgmailto:haproxy@formilux.org Subject: RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013 Hi! Please also note that the second SOAP call made that fails the handshake also causes the HAProxy server to crash. Could you: - use latest snapshot from [1] - provide the output of haproxy -vv - can you tell us OS, kernel and openssl version? - compile haproxy with debug and without compiler optimizations: make DEBUG=-DDEBUG_FULL CFLAGS=-g -O0 TARGET=[...] - catch a backtrace of the crash with gdb (see [2] if you need details) Regards, Lukas [1] http://haproxy.1wt.eu/download/1.5/src/snapshot/ [2] http://www.mail-archive.com/haproxy@formilux.org/msg09472.html
RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Hi Zack, your OS probably doesn't generate coredumps by default. It can be tricky to generate them. Make sure: - haproxy is started as root - it doesn't use chrooting - don't use the init script, but start haproxy manually right after you used the ulimit command - otherwise follow the description here: http://www.mail-archive.com/haproxy@formilux.org/msg09472.html The ´cat /proc/sys/kernel/core_pattern´ setting specifies in what directory the coredump is saved and By following the above suggestion you make your setup less secure, so use it with care and revert those things after you obtained the coredump. The coredump itself and the gdb output as well will contain things like ip addresses, etc. Please be aware of that when you post it to the mailing list. If you cannot publish such data you may just sent the gdb output to Willy Tarreau w...@1wt.eu instead of the mailing list. I'm CC'ing the list, maybe someone else finds this useful. Regards, Lukas From: zachary.conne...@cgifederal.com To: luky...@hotmail.com Subject: RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013 Date: Thu, 25 Apr 2013 20:41:47 + Lukas, Thanks, the change fixed the compile problem. Testing out the latest version now... Do you happen to know where the core dump would end up? So far we haven't found it but the server has definitely come down after the second SOAP request. Thanks, Zack -Original Message- From: Lukas Tribus [mailto:luky...@hotmail.com] Sent: Thursday, April 25, 2013 4:19 PM To: Connelly, Zachary (CGI Federal) Subject: RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013 Hi Zack, in fact there was a build breakage in the development snapshots. Please apply the following patch or wait for tonights snapshot, which will include the patch as well: http://haproxy.1wt.eu/git?p=haproxy.git;a=commitdiff_plain;h=c621d36ba3ff8b4ca2907f4dc966cfb13cbf3451http://haproxy.1wt.eu/git?p=haproxy.git%3ba=commitdiff_plain%3bh=c621d36ba3ff8b4ca2907f4dc966cfb13cbf3451 Regards, Lukas
RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Baptiste, Thanks for the advice. I am trying to receive an SSL request into HAProxy then pass along to the back-end server as http. The back-end server is a simple SOAP service that responds on http and we want HAProxy to respond to the client on https. We are not redirecting on the back-end in anyway, just receiving http from HAProxy after the SSL offload and responding with http to HAProxy. When that occurs we are seeing the error described here: http://comments.gmane.org/gmane.comp.web.haproxy/10830. I was wondering if the code change described in this thread was implemented and/or successful. Please also note that the second SOAP call made that fails the handshake also causes the HAProxy server to crash. Here are the front and back end sections for reference: frontend http-in bind xx.xx.xx.xx:80 #actual IP removed bind xx.xx.xx.xx:443 ssl crt /usr/local/cdx/apache/ssl/combined.pem id 100 #actual IP removed option http-server-close default_backend devngn1 capture response header Location len 32 capture response header Set-Cookie len 32 backend devngn1 balance roundrobin reqrep ^([^\ :]*)\ /generic(.*) \1\ /specific-path-location\2 #actual path removed server app1 xx.xx.xx.xx:80 Thanks, Zack -Original Message- From: Baptiste [mailto:bed...@gmail.com] Sent: Monday, April 22, 2013 2:43 AM To: Connelly, Zachary (CGI Federal) Cc: haproxy@formilux.orgmailto:haproxy@formilux.org Subject: Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013 Hi Zachary, It sounds your application server is not aware the connections was made over a SSL socket on HAProxy frontend and tries to redirect the user on the same socket but on HTTP protocol. To figure out if this is really the case, and to know how to fix it, you can read this blog article: http://blog.exceliance.fr/2013/02/26/ssl-offloading-impact-on-web-applications/ Baptiste On Fri, Apr 19, 2013 at 8:53 PM, Connelly, Zachary (CGI Federal) zachary.conne...@cgifederal.commailto:zachary.conne...@cgifederal.com wrote: HAProxy list, I am currently working to implement SSL within HAProxy using the 1.5-dev18 version. Much like the thread started by Samat Galimov on 2/5/2013, I am seeing the same behavior where the first time I send a request via SSL the request is serviced and everything is fine; the next time the same request is attempted I receive 'ERROR:Exception in request: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake.' I noticed the attached code in the thread was not put into the dev18 version (I believe). Did that code end up resolving the issue or is the issue still being reviewed? I can supply my config file if that would help. Is there any way to get more info out of HAProxy to see what it is doing while it handles the SSL Handshake (the log does not seem to write anything when the request fails)? Any assistance would be appreciated. Thanks, Zack Connelly
RE: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Hi! Please also note that the second SOAP call made that fails the handshake also causes the HAProxy server to crash. Could you: - use latest snapshot from [1] - provide the output of haproxy -vv - can you tell us OS, kernel and openssl version? - compile haproxy with debug and without compiler optimizations: make DEBUG=-DDEBUG_FULL CFLAGS=-g -O0 TARGET=[...] - catch a backtrace of the crash with gdb (see [2] if you need details) Regards, Lukas [1] http://haproxy.1wt.eu/download/1.5/src/snapshot/ [2] http://www.mail-archive.com/haproxy@formilux.org/msg09472.html
Re: Follow-up on thread 'SSL handshake failure' from 2/5/2013
Hi Zachary, It sounds your application server is not aware the connections was made over a SSL socket on HAProxy frontend and tries to redirect the user on the same socket but on HTTP protocol. To figure out if this is really the case, and to know how to fix it, you can read this blog article: http://blog.exceliance.fr/2013/02/26/ssl-offloading-impact-on-web-applications/ Baptiste On Fri, Apr 19, 2013 at 8:53 PM, Connelly, Zachary (CGI Federal) zachary.conne...@cgifederal.com wrote: HAProxy list, I am currently working to implement SSL within HAProxy using the 1.5-dev18 version. Much like the thread started by Samat Galimov on 2/5/2013, I am seeing the same behavior where the first time I send a request via SSL the request is serviced and everything is fine; the next time the same request is attempted I receive ‘ERROR:Exception in request: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake.’ I noticed the attached code in the thread was not put into the dev18 version (I believe). Did that code end up resolving the issue or is the issue still being reviewed? I can supply my config file if that would help. Is there any way to get more info out of HAProxy to see what it is doing while it handles the SSL Handshake (the log does not seem to write anything when the request fails)? Any assistance would be appreciated. Thanks, Zack Connelly
