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