hotel icon indicating copy to clipboard operation
hotel copied to clipboard

Proxy stopped working on Mac

Open zaidhuda opened this issue 6 years ago • 7 comments

Hotel is accessible at http://localhost:2000/ but not on http://hotel.localhost/ even though automatic proxy has been set to http://localhost:2000/proxy.pac.

macOS Mojave Google Chrome Version 71.0.3578.98 (Official Build) (64-bit)

zaidhuda avatar Dec 20 '18 04:12 zaidhuda

I have the same Google Chrome version (71.0.3578.98) and the proxy doesn't work after the last update. Try using a different browser and hotel should work (with Firefox works fine).

samanthabaita avatar Dec 20 '18 10:12 samanthabaita

I can confirm that it breaks down with Chrome. Safari/Firefox working fine

jonalvarezz avatar Dec 22 '18 16:12 jonalvarezz

This should be notified in the readme for now.

melMass avatar Jan 03 '19 19:01 melMass

I'm having the same issue with Chrome 71.0.3578.98. Going to hotel.localhost returns ERR_CONNECTION_REFUSED. Chrome Canary 73.0.3660.0 is also experiencing the same problem. Safari and Firefox are working fine. Chrome 60 and 70 on the same Mac works fine. So something happened between Chrome versions 70 and 71 to make it not work with the Hotel proxy.

johndouthat avatar Jan 03 '19 22:01 johndouthat

I set "tld" to "foobar" in hotel.conf and restarted hotel and Chrome, and now hotel.foobar works in Chrome 71. So maybe Chrome just doesn't like the .localhost TLD?

I found an article about changes in Chrome 71 and looked for anything regarding proxies. It mentions CVE-2018-18358, whose description is

Lack of special casing of localhost in WPAD files in Google Chrome prior to 71.0.3578.80 allowed an attacker on the local network segment to proxy resources on localhost via a crafted WPAD file.

Here's a write-up with some more depth: https://bugs.chromium.org/p/project-zero/issues/detail?id=1707

There is a chromium issue, but I do not have permissions to read it: https://bugs.chromium.org/p/chromium/issues/detail?id=899126

I'm not certain, but maybe it's related.

johndouthat avatar Jan 03 '19 23:01 johndouthat

I think I found the commit in Chrome for version 71: https://github.com/chromium/chromium/commit/0e2a57db78b2dca463903ab26523fe9ac1798949 which is a partial cherry pick of this commit, which has a more detailed commit message: https://github.com/chromium/chromium/commit/da790f920bbc169a6805a4fb83b4c2ab09532d91

  • localhost names (as determined by net::IsLocalhost) now implicitly bypass the proxy

See ProxyBypassRules::MatchesImplicitRules to see that *.localhost is an implicit rule.

See line 4014 and 4068 of the unit test to see that they explicitly test to ensure foo.localhost bypasses the proxy when using a PAC script

The commit message says that you can either manually configure the proxy settings (i.e. not use a PAC script) or use "<-loopback>" proxy bypass rule to reverse this behavior, but I'm not sure how to do either of those things yet.

Of course, just switching to *.foobar also works, but is not ideal

johndouthat avatar Jan 04 '19 00:01 johndouthat

I'm seeing the same issue with Firefox 65.0 on macOS 10.14.2. Setting another tld in hotel.conf works as expected.

erikthered avatar Feb 06 '19 19:02 erikthered