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: Elevation of privilege #73

Closed
MikeBishop opened this issue May 28, 2015 · 5 comments

Comments

Projects
None yet
4 participants
@MikeBishop
Copy link
Contributor

commented May 28, 2015

Someone who controls any resource on an origin can issue directives that affect all resources on that origin. (Thinking of the server the CS/CE students could work with in college, where we all had pages at server.example.edu/~username.) Sure, I can’t change the host because I don’t have the server cert, but I can change ports without that requirement.

The guidance in 9.1 just says “don’t let people do that,” which is easier said than done on systems that already exist. People can run apps listening on ephemeral ports, and people can control their home pages. With this combination, everyone else's home pages can be hijacked unless the server admin reads this draft before any students do and promptly prohibits pages from emitting headers named Alt-Svc.

The way to partially fix this is to require strong auth for changes of port as well. Resources can still slow down access by causing attempts to access an alternate, but the alternate won't be able to supply fake resources.

@reschke reschke added the alt-svc label May 30, 2015

@mnot mnot added the design label Jun 1, 2015

@mnot

This comment has been minimized.

Copy link
Member

commented Jun 1, 2015

Noting that that would effectively disallow OppSec - one of the main (but not only) use cases for Alt-Svc.

@MikeBishop

This comment has been minimized.

Copy link
Contributor Author

commented Jun 1, 2015

Well, that goes back to the "do you validate certs in Opp-Sec?" discussion. If the server has a valid cert, there's no problem changing ports. Opp-Sec already states "A client MAY perform additional checks on the offered certificate if the server does not select an unauthenticated TLS cipher suite. This document doesn’t define any such checks, though clients could be configured with a policy that defines what is acceptable."

I think we're saying that if we implement, our additional checks (default, at least) will be the same as for an https:// origin. Otherwise, we see a security risk here.

@enygren

This comment has been minimized.

Copy link
Contributor

commented Jun 1, 2015

Does having different behavior for privileged vs non-privileged ports help? (i.e., being able to bind to port 443 in most of these circumstances is typically quite different from being able to bind to 8443.)

@mnot

This comment has been minimized.

Copy link
Member

commented Jul 21, 2015

Discussed in Prague; feeling in room was to non-normatively describe the risks, and recommend a privilege barrier ++ .

@mnot mnot added the editor-ready label Aug 24, 2015

@mnot

This comment has been minimized.

Copy link
Member

commented Oct 5, 2015

Can someone work on some text here?

reschke added a commit that referenced this issue Oct 6, 2015

@reschke reschke closed this Oct 6, 2015

@mnot mnot modified the milestone: alt-svc-09 Oct 7, 2015

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.