To back up for a second, remember that a server administrator can prevent connection reuse at will by either: 1) Changing the hostname -> IP mapping so that hosts which should not share connections are on different address 2) Serving certificates which are not valid for hosts which should not reuse connections to the current host As such, any server administrator who is concerned about connection reuse can simply configure their servers to prevent it from happening. On Sat, Jan 3, 2015 at 2:22 AM, Aeris <aeris@imirhil.fr> wrote: > > For the record, I disagree with that assessment. There are strict > > security improvements in HTTP/2. > > Yep, requiring TLS1.2+ and strong ciphers is cool :) > > About this, why requiring P256 elliptic curve [FIPS186] support, which is > *not* safe (see http://safecurves.cr.yp.to/) and not the safe Curve25519 > curve > for example ? > > > Connection reuse can also provide > > non-trivial privacy advantages. > > If it means same behaviour as MITM or downgrade attack… > If you can exploit Chrome's connection reuse behavior to lead to a MITM attack, that would be a critical security bug which we would jump on immediately. Please let me know if you are able to do so. > And currently, I don’t see any of those non-trivial advantages. Do you have > some example ? > > What about TLS client auth with connection reusage ? > If dom A don’t require TLS client auth but B does, how the connection > reusage > will handle this case ? Without TLS renegociation for domain B, the HT2 > user- > agent won’t be able to see there is a client certificate to send, no ? > In Chrome, we prevent connection reuse to hosts which request client certificates. HTTP/2 prohibits TLS renegotiation in section 9.2.1. Cheers, Ryan
Received on Sunday, 4 January 2015 18:59:33 UTC