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