You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You can identify an alternative on a different port on localhost trivially and it might be considered authoritative. You probably don't want to accept localhost as a valid alternative for an http://example.com origin.
Discussed in Prague; add security considerations / non-normative text that this is another form of privilege escalation, and should be taken into account. (both localhost and special use networks / rfc1918). Need to discuss with webappsec as well as security folks in ietf.
Treating rfc1918 as special opens up a can of worms, especially as there is no clear mapping there in the IPv6 world and as other related spaces (rfc6598). We may just generally want to ensure AltSvc can't be used to probe/attack internal hosts behind a firewall regardless of what IP space is present. Due to the async behavior of Alt-Svc and the reliance on cert validation, we may be OK here as long as we don't treat rfc1918 space special (eg, as long as we don't relax cert validation requirements there).
due to the prohibition on host changes and the async nature of alt-svc, the only issue I can see here is that example.com can probe for things behind the firewall that have the example.com cert :) but maybe I'm missing the concern?
Activity
martinthomson commentedon Jul 21, 2015
See also #73
martinthomson commentedon Jul 21, 2015
1918 space is similarly problematic.
mnot commentedon Jul 21, 2015
Discussed in Prague; add security considerations / non-normative text that this is another form of privilege escalation, and should be taken into account. (both localhost and special use networks / rfc1918). Need to discuss with webappsec as well as security folks in ietf.
enygren commentedon Jul 21, 2015
Treating rfc1918 as special opens up a can of worms, especially as there is no clear mapping there in the IPv6 world and as other related spaces (rfc6598). We may just generally want to ensure AltSvc can't be used to probe/attack internal hosts behind a firewall regardless of what IP space is present. Due to the async behavior of Alt-Svc and the reliance on cert validation, we may be OK here as long as we don't treat rfc1918 space special (eg, as long as we don't relax cert validation requirements there).
martinthomson commentedon Jul 21, 2015
The prohibition on host changes for cleartext
http://should cover this.mcmanus commentedon Jul 21, 2015
due to the prohibition on host changes and the async nature of alt-svc, the only issue I can see here is that example.com can probe for things behind the firewall that have the example.com cert :) but maybe I'm missing the concern?
mnot commentedon Nov 2, 2015
Discussed in Yokohama; we think we can close this with no action.
mnot commentedon Nov 9, 2015
@reschke please add to the changes section.
Update changelog wrt to issue 89 (#89)