Subject: constraining scheme (http vs https) on a connection

From: Erik Nygren <[email-masked]>
Date: Fri, 20 May 2016 15:40:12 -0400

In some recent discussions, it has come up that we don't clearly specify
whether multiple schemes (eg, http and https) can share a single
connection.  For example, if www.example.com  has a valid certificate for
www.example.com then by the reading of rfc7540 a client could potentially
use a single connection for http://www.example.com/ and
https://www.example.com/

By the reading of rfc7540, it also seems like if www.evil.com resolves to
the same IP address as www.example.com (which www.example.com has no
control over) a client might be willing/able to send requests over the
www.example.com connection?

This seems like it has the potential for confusion.  For example, if
www.example.com is using client cert auth.  Or if a server is
distinguishing HTTP vs HTTPS based on port number as described as a risk in
draft-ietf-httpbis-http2-encryption and discussed here.  There also seem
like some potential attacks that become easier if a client is making HTTP
requests over HTTP/2 sharing a connection with HTTPS.  (For example,
side-channel attacks between HTTP and HTTPS seem easy here, and there might
be some compression based attacks.)  Am I alone in thinking this connection
sharing (which servers can't really control today outside of returning a
421 for HTTP-scheme requests) is a bad idea?

Some things seem worth considering here:

* The ORIGIN frame helps here as an origin can list only supporting the "
https://www.example.com" origin.

* We likely want to have draft-ietf-httpbis-http2-encryption prohibit
sharing requests for secure and non-secure schemes over a single
connection, even if authenticated.

Is there any other guidance we should be proposing on this front?  For
example, to discourage clients from doing this sharing and to encourage
servers to return 421 if they see mixed schemes on a connection?

Best, Erik

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 21 May 2016 16:55:00 +1000

> On 21 May 2016, at 5:40 AM, Erik Nygren <[email-masked]> wrote:
> 
> In some recent discussions, it has come up that we don't clearly specify whether multiple schemes (eg, http and https) can share a single connection.  For example, if www.example.com  has a valid certificate for www.example.com then by the reading of rfc7540 a client could potentially use a single connection for http://www.example.com/ and https://www.example.com/
> 
> By the reading of rfc7540, it also seems like if www.evil.com resolves to the same IP address as www.example.com (which www.example.com has no control over) a client might be willing/able to send requests over the www.example.com connection?

My understanding is that's only the case when traffic is explicitly directed this way (e.g., using Alt-Svc).

For example, if we have an open connection to https://www.example.com/, that's on port 443; it can't be used for the origin (http, www.example.com, 80) without further information, because it has a different port.

However, 7540 could probably be more clear about this; currently, 9.1.1 says:

"""
Connections that are made to an origin server, either directly or through a tunnel created using the CONNECT method (Section 8.3), 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 TCP connections without TLS, this depends on the host having resolved to the same IP address.
"""

Really, that should be specified in terms of RFC6454 origins. I.e., if I have a connection to (https, www.example.com, 443), and the cert also covers other.example.com, that means that it can be reused for (https, other.example.com, 443), but not anything else (without additional information).

> This seems like it has the potential for confusion.  For example, if www.example.com is using client cert auth.  Or if a server is distinguishing HTTP vs HTTPS based on port number as described as a risk in draft-ietf-httpbis-http2-encryption and discussed here.  There also seem like some potential attacks that become easier if a client is making HTTP requests over HTTP/2 sharing a connection with HTTPS.  (For example, side-channel attacks between HTTP and HTTPS seem easy here, and there might be some compression based attacks.)  Am I alone in thinking this connection sharing (which servers can't really control today outside of returning a 421 for HTTP-scheme requests) is a bad idea?
> 
> * The ORIGIN frame helps here as an origin can list only supporting the "https://www.example.com" origin.
> 
> * We likely want to have draft-ietf-httpbis-http2-encryption prohibit sharing requests for secure and non-secure schemes over a single connection, even if authenticated.

At the least, we should warn about the issues that might be encountered. Servers can then choose not to advertise services like this, and clients can choose not to consume them.

> Is there any other guidance we should be proposing on this front?  For example, to discourage clients from doing this sharing and to encourage servers to return 421 if they see mixed schemes on a connection?

--
Mark Nottingham   https://www.mnot.net/

---

From: Erik Nygren <[email-masked]>
Date: Tue, 31 May 2016 18:31:58 -0400

Filed for the opp-sec draft where this is most relevant:

     https://github.com/httpwg/http-extensions/issues/188

In particular, mixing of secure and insecure schemes should require
server-side opt-in over a strongly authenticated channel.  (eg, an
attribute of /.well-known/http-opportunistic with properties similar to
"commit" as for where it can be set).

     Erik

At the least, we should warn about the issues that might be encountered.
> Servers can then choose not to advertise services like this, and clients
> can choose not to consume them.
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 1 Jun 2016 11:10:26 +1000

What do other folks think?

> On 1 Jun 2016, at 8:31 AM, Erik Nygren <[email-masked]> wrote:
> 
> In particular, mixing of secure and insecure schemes should require server-side opt-in over a strongly authenticated channel.  (eg, an attribute of /.well-known/http-opportunistic with properties similar to "commit" as for where it can be set).
> 
>      Erik
> 
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Jun 2016 12:06:54 +1000

This is reasonable.  A boolean `mixed-scheme` member that has to be
true seems appropriate.  It's cheap enough to warrant doing.