@lukas - I think you may have hit the nail on the head! The link you provided (http://blog.tinola.com/?e=36) <http://blog.tinola.com/?e=36> describes an experience VERY similar to mine. I also had a lot of trouble finding an instance I could reproduce it on. I intend to delve into the article a bit more and figure out how to run a debug backtrace on HAProxy, but I quickly tested the 'packet of death' command in the article, and it crashed my HAProxy just as noted: "openssl s_client -cipher LOW -connect 192.168.1.1:443".
I am not using CentOS 6.4 per se; all my Test and Prod machines are AWS instances, running "Amazon Linux", which is apparently a customized CentOS distribution. I'm not a Linux expert, so I dont know which version of CentOS this OS would be closest to. "uname -a" shows me: "Linux ip-10-10-0-61 3.14.35-28.38.amzn1.x86_64" Appreciate the response; this gives me a real direction to go in! -Phil <http://blog.tinola.com/?e=36> 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 > >
