alt-svc vs the ability to convey the scheme inside the protocol

[reschke]

See https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0193.html:

"Alternative Services MUST NOT be advertised for a protocol that is not
designed to carry the scheme. In particular, HTTP/1.1 over TLS cannot
carry safely requests for http resources."

...which refers to the :scheme pseudo header field in HTTP/2
(http://greenbytes.de/tech/webdav/rfc7540.html#HttpRequest).

As far as I recall the intention of the statement above is to avoid that
when alt-svc is used to move http traffic to a TLSsy port such as 443,
the alternative server gets confused about whether it's serving HTTP or
HTTPS.

In reality, even when the protocol does carry the scheme (such as
in HTTP/2), the application (think PHP running on top of Apache httpd)
is so distant from the actual server stack that it wouldn't have that
information. This is especially true as long many servers shield
applications from any knowledge about whether they are accessed over
HTTP/1.1 or HTTP/2. (Speaking of which, HTTP/1.1 can carry this
information as well, see
http://greenbytes.de/tech/webdav/rfc7230.html#absolute-form).

[icing]

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.

[martinthomson]

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.

[mnot]

Discussed in Yokohama; needs more discussion on list, as Julian and Martin have different viewpoints on whether the requirement can be removed.

[mnot]

... but adding more guidance to 9.5 is desirable in any case.

[mnot]

Straw-man proposal:

✂︎

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).

[icing]

Good enough for me. How exactly scheme needs to be visible and how connection details need to be hidden is beyond the scope of the spec anyway.

[reschke]

Sounds good. @martinthomson does this work for you?

[martinthomson]

👍

[reschke]

I note that this would also address #91.

[mnot]

OK, let's incorporate that and push a new draft for the WG to review.

[reschke]

(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
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 or the
"absolute form" of the request URI in HTTP/1.1) as an indication of
security context, instead of other connection properties ([RFC7540],
Section 8.1.2.3 and [RFC7230], Section 5.3.2).

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).

[enygren]

In the list of server mitigations we likely want to also include:

"or return (421 Not Authoritative?) for insecure scheme requests
received over TLS".

Neither of the other proposed mechanisms protect existing
secure applications/servers that assume that port-443/TLS
traffic is "secure". Since the "advertising alternative services
for insecure schemes" would be done over an insecure channel,
simply refraining doesn't mitigate attacks if there is an application
vulnerability due to existing assumptions.

On Tue, Nov 17, 2015 at 3:32 AM, Julian Reschke notifications@github.com
wrote:

9.5. Confusion Regarding Request Scheme

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 or the
"absolute form" of the request URI in HTTP/1.1) as an indication of
security context, instead of other connection properties ([RFC7540],
Section 8.1.2.3 and [RFC7230], Section 5.3.2).

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).

—
Reply to this email directly or view it on GitHub
#92 (comment)
.