- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 21 Dec 2018 12:13:19 +1100
- To: Eric Rescorla <ekr@rtfm.com>
- Cc: The IESG <iesg@ietf.org>, draft-ietf-httpbis-cdn-loop@ietf.org, httpbis-chairs@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>, Tommy Pauly <tpauly@apple.com>, Patrick McManus <mcmanus@ducksong.com>
On 21 Dec 2018, at 11:17 am, Eric Rescorla <ekr@rtfm.com> wrote: > > > > As Alissa points out, this also potentially leaks the CDN you use, > > > even if that would otherwise be hidden. For instance, suppose that a > > > request goes A -> B -> C but B is hidden (doesn't add anything to the > > > headers). If you know B's token, then you can tell if this is the case > > > or not., by injecting it yourself and seeing if you get service. Seems > > > like you should document this. > > > > It leaks the CDN the origin configures to the origin -- what attack are you concerned about here? > > > > If the client forges it, it leaks it to the client, no? > > Can you be more specific -- what do you mean by "client" and "it" here? > > We have a situation with two alternate topologies: > > 1. A -> B -> Origin > 2. A -> Origin > > The original HTTP client (i.e., an external attacker on the Internet) sends a request with a CDN-Loop header containing B. In topology (1) this causes some kind of failure and in topology (2) it does not, thus leaking the topology. Ah - so you're saying that 'A' is also a CDN, not the user-agent? If the answer is 'yes', I understand; will add some text. Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Friday, 21 December 2018 01:13:49 UTC