Hi,
On Sat, Feb 23, 2013 at 08:54:17AM +0100, Kenneth Mutka wrote:
> 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?
Yes, you could adapt the log format to log the TLS version, ciphers and SNI
you received (you need a quite recent snapshot for this) :
log-format %ci:%cp\ [%t]\ %ft\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %ST\ %B\ %CC\
%CS\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ %hr\ %hs\ %{+Q}r\
%[ssl_fc_protocol]:%[ssl_c_version]:%[ssl_fc_cipher]:%[ssl_fc_sni]
It will probably help you.
willy
