Re: [TLS] Final nail in the coffin for cleartext SNI/ALPN in TLS 1.3

[Ralf Skyper Kaiser <[e-mail]>]

Hi Yoav,

thanks for pointing this out. How widely is this technique used? (and
clients which do not support SNI [there are plenty!]
can not connect at all via HTTPS with what they are doing - odd. but i'm
not here to judge :>).

We shall not compromise the security of the many to accommodate the
performance needs of the few.

Get a F5 or equivalent SSL Proxy. Done.

regards,

ralf


On Tue, Nov 12, 2013 at 10:17 AM, Yoav Nir <[e-mail]> wrote:

>
> On Nov 12, 2013, at 12:06 PM, Ralf Skyper Kaiser <[e-mail]>
>  wrote:
>
> > Hi,
> >
> > Martin, you are right that SNI is currently implemented and transmitted
> in clear.
> > This was however not the primary design goal but rather a choice of
> convenience
> > and lack of better/easier ideas. The primary design goal for SNI was to
> allow
> > multi-homing HTTPS servers on the same IP (so that apache can select the
> > correct x509 certificate for whatever site the client requested). There
> is no
> > practical or security benefit  or transmitting SNI in clear.
>
> There is a design I've seen at a site some years ago. I don't know how
> popular this is, but at least there's a non-empty set of servers doing this.
>
> They have multiple servers within the datacenter and a reverse proxy. All
> server names resolve to the address of the reverse proxy. For each
> connection, it reads the ClientHello and extracts the SNI, and then
> forwards the ClientHello (and the rest of the connection) to the
> appropriate server. In no SNI, there is a default server (which is where
> most of the traffic is going anyways)
>
> With encrypted SNI it would have to actually terminate the TLS rather than
> just look at the ClientHello.
>
> Yoav
>
>