- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 21 Dec 2018 13:46:32 +1100
- To: Benjamin Kaduk <kaduk@mit.edu>
- Cc: Eric Rescorla <ekr@rtfm.com>, draft-ietf-httpbis-cdn-loop@ietf.org, httpbis-chairs@ietf.org, Patrick McManus <mcmanus@ducksong.com>, The IESG <iesg@ietf.org>, Tommy Pauly <tpauly@apple.com>, HTTP Working Group <ietf-http-wg@w3.org>
> On 21 Dec 2018, at 1:44 pm, Benjamin Kaduk <kaduk@mit.edu> wrote: > > On Fri, Dec 21, 2018 at 01:40:11PM +1100, Mark Nottingham wrote: >> >> >>> On 21 Dec 2018, at 12:13 pm, Mark Nottingham <mnot@mnot.net> wrote: >>> >>>> 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. >> >> I've added: >> >> """ >> A CDN's use of the CDN-Loop header field might expose its presence. For example, if CDN A is configured to forward its requests to CDN B for a given origin, CDN B's presence can be revealed if it behaves differently based upon the presence of the CDN-Loop header field. >> """ > > Sorry for being slow to catch up. > > It's not entirely clear to me that you actually need A to be a CDN for this > to work -- if I want to know if CDN B is used to serve a given origin, > can't I just tell my browser to add B's CDN-Loop header field to the > request? (With the idea being that if that change causes me to not get > content, then I know CDN B is in use.) I'm not following you. There are any number of ways to determine that a given CDN is configured to serve a given origin; how does CDN-Loop specifically change this? Cheers, -- Mark Nottingham https://www.mnot.net/
Received on Friday, 21 December 2018 02:47:03 UTC