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
