- From: Benjamin Kaduk <kaduk@mit.edu>
- Date: Thu, 20 Dec 2018 20:44:24 -0600
- To: Mark Nottingham <mnot@mnot.net>
- 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 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.) -Benjamin
Received on Friday, 21 December 2018 02:44:52 UTC