W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

Re: http2 opportunistic security negotiation

From: Martin Thomson <martin.thomson@gmail.com>
Date: Sat, 7 Feb 2015 08:35:17 +1100
Message-ID: <CABkgnnXYcPs4bP6N4hO4kTHpskLkaOcV5xXZD=Je62FsyDs-gg@mail.gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Erik Nygren <erik@nygren.org>
I wouldn't assume to know with 100% confidence what any given client will
accept.
On Feb 6, 2015 7:16 PM, "Ilari Liusvaara" <ilari.liusvaara@elisanet.fi>
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 <
> > ilari.liusvaara@elisanet.fi> 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
>
>
Received on Friday, 6 February 2015 21:35:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:43 UTC