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 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? 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. Lukas [1] http://cbonte.github.com/haproxy-dconv/configuration-1.5.html#5-strict-sni
