Re: http2 opportunistic security negotiation

[Martin Thomson <[e-mail]>]

I wouldn't assume to know with 100% confidence what any given client will
accept.
On Feb 6, 2015 7:16 PM, "Ilari Liusvaara" <[e-mail]>
wrote:

> On Thu, Feb 05, 2015 at 05:21:26PM -0500, Erik Nygren wrote:
> > On Thu, Feb 5, 2015 at 11:28 AM, Ilari Liusvaara <
> > [e-mail]> wrote:
> >
> > >
> > > Even TLS 1.3 won't encrypt the ALPN (at least as TLS 1.3 currently is).
> >
> >
> >
> > Why can't the server's ALPN response be in EncryptedExtensions for a TLS
> > 1.3 ServerHello
> > even if the client's ALPN (a superset so less interesting) is
> in-the-clear
> > in the ClientHello?
>
> Ah yeah, Server's ALPN. Client's ALPN would be always constant per client.
>
>
> Also, it occurs to me that if one can tell from certificate if it is
> supposed to be valid or not, the ALPN leak does not add much:
>
> - On TLS 1.2, one can inspect certificate of connection before deciding
>   to MITM or not (since nothing before it has any commitments).
> - In TLS 1.3, where that isn't possible (there are commitments from
>   both sides before), one can still connect to the server and probe
>   the certificate.
>
>
> Then there are some servers where getting good certificate is
> much less of a problem than dealing with the https:// scheme
> (due to legacy internal baggage).
>
>
> -Ilari
>
>