Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
reschke opened this issue Aug 13, 2015 · 12 comments

Comments

Projects
None yet
5 participants
@reschke
Copy link
Contributor

commented Aug 13, 2015

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

@reschke reschke added the alt-svc label Aug 13, 2015

@reschke reschke changed the title alt-svc vc the ability to convey the scheme inside the protocol alt-svc vs the ability to convey the scheme inside the protocol Sep 23, 2015

@icing

This comment has been minimized.

Copy link

commented Sep 23, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Sep 23, 2015

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 mnot added the design label Sep 25, 2015

@mnot

This comment has been minimized.

Copy link
Member

commented Nov 2, 2015

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

@mnot

This comment has been minimized.

Copy link
Member

commented Nov 2, 2015

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

@mnot

This comment has been minimized.

Copy link
Member

commented Nov 16, 2015

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

This comment has been minimized.

Copy link

commented Nov 16, 2015

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

This comment has been minimized.

Copy link
Contributor Author

commented Nov 16, 2015

Sounds good. @martinthomson does this work for you?

@martinthomson

This comment has been minimized.

Copy link
Contributor

commented Nov 16, 2015

👍

@reschke

This comment has been minimized.

Copy link
Contributor Author

commented Nov 16, 2015

I note that this would also address #91.

@mnot

This comment has been minimized.

Copy link
Member

commented Nov 16, 2015

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

@mnot mnot added the editor-ready label Nov 16, 2015

@reschke

This comment has been minimized.

Copy link
Contributor Author

commented Nov 17, 2015

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

reschke added a commit that referenced this issue Nov 17, 2015

reschke added a commit that referenced this issue Nov 17, 2015

@mnot mnot closed this Nov 19, 2015

@enygren

This comment has been minimized.

Copy link
Contributor

commented Nov 19, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.