Re: Comments about draft-ietf-httpbis-http2-16 : Connection reuse

On Wed, Dec 31, 2014 at 4:04 PM, Aeris <aeris@imirhil.fr> wrote:

> Sorry to speak about this only now, but I notice the following problem only
> few days ago when I activate SPDY on a TLSA protected domain.
>
> §9.1.1 about connection reusage on HTTP/2 say
>
>         Connections that are made to an origin servers MAY
>         be reused for requests with multiple different URI authority
>         components.  A connection can be reused as long as the origin
> server
>         is authoritative (Section 10.1).
>         For "https" resources, connection reuse additionally depends on
>         having a certificate that is valid for the host in the URI.
>
> In my opinion, this behaviour leads to 2 huge problems in term of security
> and
> 1 in term of usability/maintenability of HTTP/2.
>
> 1- X.509 certificate is not trustable by itself and need real content for
> validation
>
> There are some extensions completing the certificate validation, as
> DANE/TLSA
> (RFC6698) or websec-key-pinning (currently IETF draft).
> For both, guessing A certificate validity for B domain can’t be done just
> with
> the A certificate fetched from the A domain.
> In case of TLSA, you need the real B certificate to check if this is the
> one
> declared in the DNS. For PKP, you need the real B content to check the
> HTTP header.
>
> So current specification of HTTP/2 can break TLSA and PKP, by badly
> guessing
> that A certificate can be reuse on B domain, instead of using the real B
> certificate.
>
> This is actually the case with current SPDY implementation (Firefox or
> Chrome). Having a A content including B content on the same IP with a A
> certificate valid for B domain but not for B TLSA, SPDY reuse the A
> channel for
> B content, and Firefox/Chrome display warning or block the content because
> TLSA error.
>

​Chrome does not support TLSA so I'm not sure how the current Chrome SPDY
implementation could be breaking TLSA.
​


> 2- TLS is not only X.509 certificate. It’s also a lot of other things.
>
> The current HTTP/2 specification restrict TLS to only the certificate it
> use.
> If A domain use RSA 1024 bits key but B domain use ECC 571 bits key,
> reusing
> the A channel for B content reduce a lot the security compared to the case
> with 2 differents channels. Same problem if you enable different ciphers
> (saying
> NULL cipher for static content and AES256-GCM for critical content), or
> perfect forward secrecy ciphers for one and not for the other.
> Can be the case if you use weak but fast config for your static content and
> strong but slow one for the critical content.
> Same trouble in case of some downgrade attack on static content.
> If HTTP/2 use the weakest channel for both, there is a big security
> problem.
>
> 421 error code is not usable in this case to reject a channel reusage,
> because
> the required checks can’t be done application-side (TLS client context and
> server config not available) and even server-side, is extremly complicated
> (if
> even doable)…
>
> 3- Channel reuse leads to « systemd-for-the-web » if done cleanly.
>
> Given the 2 points above, doing channel reuse cleanly require for HTTP/2 to
> become a systemd-like monster.
> « cleanly » means « no difference compare to 2 channels usage », so take
> into
> account real B TLS context : certificat, key type and size, TLSA entry and
> corresponding DNSSec validation, TLS version, selected cipher, PKP HTTP
> header, key pinning (hardcoded in browser, pinned by user, pinned by plugin
> (HTTPS Everywhere / Certificate Patrol)) and virtually any others things a
> overall TLS ecosystem can have to manage, including not built-in or
> custom/non-standard.
> TLSA is a good example for this point because not browser built-in but
> available through plugin, PKP because not currently a standard, and
> HTTPSEverywhere/CertificatePatrol because interfering with browser built-in
> config.
>
> To choose if you can reuse or not a A channel for a B domain, HTTP/2 must
> be
> aware of many things, perhaps neither built-in nor even standardized.
> Changing or adding a new step of verification on TLS will require rebuild
> of
> HTTP/2 client, hooks on plugins for not-built-in features, plugins need to
> be
> notified if HTTP/2 is in use or not…
> Everything will be aware of HTTP/2 and HTTP/2 will be aware of everything.
> New
> SystemD on the road…
>
> And even if done cleanly, channel reusing choice will be more expensive
> than
> just open a new channel (and worse, require a new channel in all cases for
> protocol/cipher/key/certificate/PKP/TLSA verification…).
>
> So, HTTP/2 must reject connection reusage, and respect real wills of system
> administrator if they declare 2 differents TLS contexts for 2 domains, but
> behind the same IP. This kind of config decision must no be done or worse
> changed client-side.
> On a post-Snowden era, don’t sacrifice security for speed… :'(
>
> Regards (and happy new year :)),
> --
> Aeris
>
> Protect your privacy, encrypt your communications
> GPG : EFB74277 ECE4E222
> OTR : 5769616D 2D3DAC72
> https://café-vie-privée.fr/ <https://xn--caf-vie-prive-dhbj.fr/>