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

[Mark Nottingham <[e-mail]>]

> On 21 May 2016, at 5:40 AM, Erik Nygren <[e-mail]> 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?
> 
> 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.

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/