- From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Date: Fri, 6 Feb 2015 10:10:33 +0200
- To: Erik Nygren <erik@nygren.org>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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 08:10:59 UTC