Host HTTP header cannot be modified using the webRequest API for HTTPS
Reported by
ilyaigpe...@gmail.com,
Sep 27 2017
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36 Steps to reproduce the problem: 1. Install extension. 2. Open http://google.com and see reply from my server. 3. Open https://google.com and see reply from Google. What is the expected behavior? Reply to https://google.com MUST come from appspot server passed via header "Host". What went wrong? Reply comes as it was a request without domain fronting. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 61.0.3163.91 Channel: n/a OS Version: Flash Version: — Firefox: domain fronting over HTTPS works (checkable with the same extension). — Wget also works as expected: `wget -q -O - https://google.com --header 'Host: domain-fronting-test.appspot.com'` — Why domain fronting is coveted? — Because it allows bypassing censorship that is abused by some government. Domain fronting original paper: https://bamsoftware.com/papers/fronting/
,
Oct 3 2017
Not DataTransfer (which is about clipboard/drag&drop APIs). Maybe extensions or network... ?
,
Oct 3 2017
I think this is by design. See https://developer.chrome.com/extensions/webRequest#life_cycle_footnote - it lists "Host" as a header that you will not even get, so you probably cannot also modify.
,
Oct 3 2017
,
Oct 4 2017
phistuck@: > I think this is by design. If it is by design then I guess both HTTP://google.com and HTTPS://google.com should be treated in the same way, while currently HTTP://google.com supports domain fronting and HTTPS://google.com doesn't.
,
Oct 10 2017
CC'ing phistuck@chromium.org as per comment #5 for further investigation phistuck@ Could you please look into this issue Thanks..!!
,
Oct 10 2017
,
Oct 10 2017
That was just my opinion. A team member would know better. It might be working for HTTP due to an implementation detail that happens to allow it and not because it was meant to work, but a team member would know.
,
Oct 10 2017
,
Oct 18 2017
Keeping appspot app running eats my free trial credits — please, triage it soon. In case all my credits are depleted: 1. In the original domain-fronting.zip you may find appspot app deployable by following [1]. 2. I attach a screenshot, demonstrating current state of affairs with chromium 61.0, firefox 56.0 and wget 1.17.1. [1]: https://cloud.google.com/nodejs/getting-started/hello-world#deploy_and_run_hello_world_on_app_engine P.S. The issue got some stars by clients of my anticensorship extension. Thank you, guys.
,
Oct 30 2017
Able to reproduce this issue on reported version 61.0.3163.79, on latest stable 62.0.3202.75 and on latest canary 64.0.3253.0 using Mac 10.12.6, Windows 10 and Ubuntu 14.04 with steps mentioned in comment#0. i.e; On navigating to https://google.com -- https://www.google.co.in/?gfe_rd=cr&dcr=0&ei=yxL3WbmWLYXy8AftrJa4CA is seen. This issue is seen from M50.[ 50.0.2661.0]. Hence considering this issue as Non-regression and marking as Untriaged
,
Nov 1 2017
Similar issue was raised in 2012 in https://bugs.chromium.org/p/chromium/issues/detail?id=158073 , but was abandoned since the mid of 2016. I offer merging this issue into 158073 and re-notifying extensions team for triaging it regarding how many stars it got recently.
,
Nov 3 2017
,
Nov 3 2017
This specific issue seems more like issue 364319 than issue 158073, really, because google.com (and friends) is using HTTP/2 (almost formerly known as "SPDY").
,
Nov 5 2017
https://crbug.com/364319 is a good focused description of the issue we have here, but it is marked as blocked by https://crbug.com/158073, so I guess we all wait with bated breaths for comments by devs in 158073. |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by ligim...@chromium.org
, Sep 28 2017