On Fri, Feb 22, 2013 at 4:14 PM, Lukas Tribus <[email protected]> wrote:
> If you upgrade to a recent snapshot you can use the strict-sni feature > [1]. This way, when the client doesn't provide SNI, the handshake is > aborted. > I'd rather not clutter the conf with redundant statements. If the client doesn't support SNI, they will be delivered the default certificate. All clients know about this. > I think this is important even when your clients are supposed to support > SNI; the client may be buggy or the SNI detection in haproxy - strict-sni > will help to track issue down to SNI (or point to something else). Did you > reproduce this with different (client-) browser, SSL stacks and OS'es? > I've tried this with the latest Firefox,Chrome and Opera as well as Internet Explorer 9 and 10 on Windows (Vista and 7) and Chrome and Firefox on Linux. They all exhibit the same behaviour. Kinda hard to believe they would all fail in a similar fashion due to buggy implementation of SNI. > Could you capture a non-working SSL/TLS session with tcpdump and post the > .cap here (or on something like cloudshark.org). The SNI header should be > present as cleartext in the client hello message. > Since the problem is so intermittent it might be a bit tricky to capture this. Would there possibly be some sort of log entry from haproxy that could indicate this? Regards, Kenneth
