typicode / hotel

🏩 A simple process manager for developers. Start apps from your browser and access them using local domains
MIT License
9.98k stars 426 forks source link

Proxy stopped working on Mac #326

Open zaidhuda opened 5 years ago

zaidhuda commented 5 years ago

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)

samanthabaita commented 5 years ago

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).

jonalvarezz commented 5 years ago

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

melMass commented 5 years ago

This should be notified in the readme for now.

johndouthat commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

erikthered commented 5 years ago

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