@Lucas: I've some a lot of testing/debugging since.....the blog article you linked was spot on. I had the exact same issue. As the article basically stated near the end, 2 conditions were required to reproduce: 1. SSLv3 must be enabled. 2. The hostname of the server itself must not include the domain(s) that is included as a the 'search' or 'nameserver' option in /etc/resolv.conf
The 2nd point is why I had such trouble reproducing in test environments. A lot of my test proxies didnt have a proper hostname, they just used the AWS default format: "ip-192-168-1-100". Consider this answered. Mad respect Lucas. You too Olivier - I appreciate both your quick responses and helpfulness. Thanks! -Phil On Tue, Mar 8, 2016 at 12:55 PM, Lukas Tribus <[email protected]> wrote: > > > Hi, > > > > I'm an admin for a software dev company. We host our software in the > > AWS cloud, using HAProxy as an entry point to a private VPC. Our > > HAProxy handles SSL. Recently, we've had an issue that we can reproduce > > on multiple proxies. > > We found that running the following test against our proxies causes the > > HAProxy service to crash or hang: > > https://www.ssllabs.com/ssltest/analyze.html > > > > We have to restart the HAProxy service for it to begin responding > > again. The crash seems to be related to cipher suite testing; HAProxy > > seems to crash during the part of that SSLlabs.com test called "testing > > deprecated cipher suites", and we found the solution is to specify a > > particular list of ciphers using the option "ssl-default-bind-ciphers". > > Sounds like the CentOS 6.4 issue: > http://blog.tinola.com/?e=36 > > Are you using CentOS 6.4? What about chroot? Some more outputs > like haproxy -vv or a crash backtrace would be useful, yes. > > > cheers, > > lukas > >
