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 header host restriction #5

Closed
mnot opened this issue Jun 24, 2014 · 8 comments

Comments

Projects
None yet
2 participants
@mnot
Copy link
Member

commented Jun 24, 2014

Issue by mnot
Wednesday Jun 04, 2014 at 16:11 GMT
Originally opened as http2/http2-spec#492


When we were originally working on Alt-Svc, Patrick and I put a restriction on the Alt-Svc header field so that it couldn’t redirect clients to a different host.

Since then, several people have pointed out that the requirement to have strong server authentication, as well as cache flushing, seems to contain the risk associated with doing this, and that the facility could be quite useful.

So, I’m suggesting we (re-) add the capability to the header.

@mnot

This comment has been minimized.

Copy link
Member Author

commented Jun 24, 2014

Comment by mnot
Thursday Jun 05, 2014 at 19:42 GMT


Discussed in NYC; do it.

@mnot

This comment has been minimized.

Copy link
Member Author

commented Jun 24, 2014

Comment by reschke
Monday Jun 09, 2014 at 18:39 GMT


Two questions:

  1. the text around the ALTSVC frame currently talks about IDNA; I assume the same considerations would apply for the header field once we include the host, right?

  2. if we change the value from port to host:port we'll have to allow quoted-string syntax as well (because of the ":"), right?

@mnot

This comment has been minimized.

Copy link
Member Author

commented Jun 24, 2014

Comment by martinthomson
Monday Jun 09, 2014 at 23:32 GMT


Yes, IDNA restrictions apply equally (to bother or neither). The colon sucks, if you want a consistent grammar. (I suppose Host is an exception in that regard.)

@mnot

This comment has been minimized.

Copy link
Member Author

commented Jun 24, 2014

Comment by reschke
Tuesday Jun 10, 2014 at 20:31 GMT


On 2014-06-10 01:32, Martin Thomson wrote:

Yes, IDNA restrictions apply equally (to bother or neither). The colon
sucks, if you want a consistent grammar. (I suppose Host is an exception
in that regard.)

We already require understanding of quoted-string when processing the
parameters, so I'll stick to the colon and make the value
token/quoted-string.

Best regards, Julian

@mnot

This comment has been minimized.

Copy link
Member Author

commented Jun 24, 2014

Comment by enygren
Thursday Jun 12, 2014 at 12:43 GMT


Do we need to clarify whether IP addresses (IPv4 and/or IPv6) are or are not allowed?
If so, for the IPv6 case are the square brackets required and do the colons need to be escaped?

@mnot

This comment has been minimized.

Copy link
Member Author

commented Jun 24, 2014

Comment by reschke
Thursday Jun 12, 2014 at 12:54 GMT


The intent is to allow exactly what's allowed in an HTTP Host header field, which includes IP addresses.

See http://greenbytes.de/tech/webdav/rfc3986.html#host

So yes, IPv6 addresses would require square brackets. And no, colons would not need any additional escaping.

@mnot

This comment has been minimized.

Copy link
Member Author

commented Jun 24, 2014

Comment by reschke
Thursday Jun 12, 2014 at 18:07 GMT


Still need to explain what checks need to be done when switching hosts; see http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/1232.html

@reschke

This comment has been minimized.

Copy link
Contributor

commented Jul 23, 2014

Section 2.1 already has: "Clients MUST NOT use alternative services with a host other than the origin's without strong server authentication; this mitigates the attack described in Section 9.2. One way to achieve this is for the alternative to use TLS with a certificate that is valid for that origin."

So it seems we're good.

@reschke reschke closed this Jul 23, 2014

martinthomson added a commit that referenced this issue Dec 23, 2015

Merge pull request #5 from martinthomson/auth
A more principled approach on authentication
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.