Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
alt-svc vs the ability to convey the scheme inside the protocol #92
"Alternative Services MUST NOT be advertised for a protocol that is not
...which refers to the :scheme pseudo header field in HTTP/2
As far as I recall the intention of the statement above is to avoid that
In reality, even when the protocol does carry the scheme (such as
It's a security consideration. From protocol pov, using HTTP/2 as Alternate Service will retain the scheme. If that scheme will make it to the web application, possibly residing behind HTTP/1.1 inspired APIs, needs to be considered when advertising Alternate Services.
In a similar way, TLS+HTTP/1.1 could carry the scheme when using absolute request URIs, but in practise, there is probably a very tall implementation barrier to overcome. There are dusty code paths, never trodden for ages - if at all, where scheme may fall into deep pits of insignificance.
Again, from pure protocol pov, absolute URIs over TLS could carry the information as well, but no one wants to explore that.
Yes, I think that @icing has it right. It is possible in theory, but the rift between theory and practice in this case is large.
The key thing to highlight here is that the server (implementation or deployment) might need to make its own assessment about safety. If the API doesn't allow the server to guarantee that the application is properly aware of the scheme of a request, then it should be possible for the server to deny the request on those grounds.
Some server-side HTTP applications make assumptions about security based upon connection context; for example, equating being served upon port 443 with the use of a HTTPS URL (and the various security properties that implies).
This affects not only the security properties of the connection itself, but also the state of the client at the other end of it; for example, a Web browser treats HTTPS URLs differently than HTTP URLs in many ways, not just for purposes of protocol handling.
Since one of the uses of Alternative Services is to allow a connection to be migrated to a different protocol and port, these applications can become confused about the security properties of a given connection, sending information (e.g., cookies, content) that is intended for a secure context (e.g., a HTTPS URL) to a client that is not treating it as one.
This risk can be mitigated in servers by using the URL scheme explicitly carried by the protocol (e.g., ":scheme" in HTTP/2) as an indication of security context, instead of other connection properties. When the protocol does not explicitly carry the scheme (e.g., as is usually the case for HTTP/1.1 over TLS), servers can mitigate this risk by either assuming that all requests have an insecure context, or by refraining from advertising alternative services for insecure schemes (such as HTTP).
(adding a mention of HTTP/1.1 absolute form plus references for that and HTTP/2's :scheme)
9.5. Confusion Regarding Request Scheme
Some server-side HTTP applications make assumptions about security
This affects not only the security properties of the connection
Since one of the uses of Alternative Services is to allow a
This risk can be mitigated in servers by using the URL scheme
When the protocol does not explicitly carry the scheme (e.g., as is
In the list of server mitigations we likely want to also include:
"or return (421 Not Authoritative?) for insecure scheme requests
Neither of the other proposed mechanisms protect existing
On Tue, Nov 17, 2015 at 3:32 AM, Julian Reschke firstname.lastname@example.org