6 ms·

> It's why Tor Browser restricts access to localhost by default. This problem was already predicted and considered by Tor developers back in 2014, see ticket #1

> It's why Tor Browser restricts access to localhost by default. This problem was already predicted and considered by Tor developers back in 2014, see ticket #10419 Sorry to invoke the meme, but Opera did it first[0], in Opera 9.50 (2008). I don't have a good reference to hand, but [1] is a developer complaining about this. [Edit: [2] covers the feature in some detail.] Opera also blocked access to private IP addresses (so there were three tiers: public IPs, private IPs, localhost; higher tiers could communicate with lower ones, so the block was only unidirectional). IE10+/EdgeHTML-based-Edge (and I know there was some talk about blocking this in Chromium-based Edge) also blocks it, so that too is prior art to the Tor change. [0]: https://w3cmemes.tumblr.com/post/62942106027/if-you-can-think-of-it-its-999-likely-opera https://w3cmemes.tumblr.com/post/62942106027/if-you-can-thin... [1]: https://stackoverflow.com/questions/1836215/access-to-127-0-0-1-by-default-in-opera-10 https://stackoverflow.com/questions/1836215/access-to-127-0-... [2]: https://web.archive.org/web/20140302021701/http://my.opera.com/securitygroup/blog/2012/07/03/operas-cross-network-protection https://web.archive.org/web/20140302021701/http://my.opera.c...

gsnedders 6y ago
To add more about why current browsers don't do this: One is clearly that you need to communicate the requesting IP deep enough into the network stack to the point where you get the DNS response (if there is one), which means there's a fair bit of work to ensure this is done everywhere; Another is it's known to break corporate websites (https://internal.bigcorp.com/ https://internal.bigcorp.com/ on a public IP expecting to be able to access private IPs on their intranet), and smaller browsers are reluctant to lose corporate users by changing long-standing behaviour; Then there's the WebRTC question: if two users on the same local network start a WebRTC call, do we want all this traffic to go to via first point where the public IP is known? For the majority of users the answer is no. And as long as that's possible, there's a (very limited) means of local communication. (But if it's limited to only things that respond to the WebRTC handshake, we're already in a much better place!)
- loeg 6y ago
  Outside of DNS, the other reasons are about local networks, not 127.0/8. There's no good reason to permit port-scanning 127.0/8.
  - gsnedders 6y ago
    Still need to know where the top-level page is loaded from, though: you do want to allow requests from 127/8 to "localhost".
  - nucleardog 6y ago
    So remove "port scanning" since the only difference between port scanning and "legitimate" connection attempts is rate. Should websockets be able to connect to the local machine? In some cases that could be useful (even if something the kinds of people visiting this site might be uncomfortable with). E.g., a local daemon that listens for a websocket connection and a public web page that's used for managing it. I don't think it was implemented this way, but think something like Battlefield 3's matchmaking: the user visits the online service and finds a match to join, and when they want to join it passes the relevant information to the game via websocket. I imagine stuff like this has been implemented in at least a couple cases that you'd break just wholesale blocking connections to 127/8.
    - neop1x 6y ago
      It can ask user explicitly like it asks for microphone. It is not common for a website page to need access to the local network services as it is to record microphone or request location data. So it's browser fault IMO.
- vbezhenar 6y ago
  In Kazakhstan we have e-government website. This website allows users to use crypto-tokens to access government services (every citizen can get a digital certificate representing his identity). This website used to run Java applet. This applet was signed and it could access restricted APIs to access USB device. So website talked to applet and applet talked to USB device to sign data. After major web browsers disabled Java applets, they implemented another approach. Now user must install a software which runs a web server on 127.0.0.1. This webserver listens on a specific port and uses web socket to communicate. So government website now uses JavaScript to connect to 127.0.0.1:12345 using websocket. And then it uses that connection to interact with USB device. So an ability for external website to connect to 127.0.0.1 actually is essential for this use-case. My guess is that there are plenty of other websites which use local web server to interact with locally installed software. I know at least one another such a website: Blizzard website. It runs web server in its game launcher and website can communicate with it. PS also they have to install custom trusted certificate because browser requires wss from https and there's no easy way to get a legitimate certificate for that kind of use.
Kipters 6y ago
UWP apps block requests to localhost too for the same reason

gsnedders 6y ago

To add more about why current browsers don't do this: One is clearly that you need to communicate the requesting IP deep enough into the network stack to the point where you get the DNS response (if there is one), which means there's a fair bit of work to ensure this is done everywhere; Another is it's known to break corporate websites (https://internal.bigcorp.com/ https://internal.bigcorp.com/ on a public IP expecting to be able to access private IPs on their intranet), and smaller browsers are reluctant to lose corporate users by changing long-standing behaviour; Then there's the WebRTC question: if two users on the same local network start a WebRTC call, do we want all this traffic to go to via first point where the public IP is known? For the majority of users the answer is no. And as long as that's possible, there's a (very limited) means of local communication. (But if it's limited to only things that respond to the WebRTC handshake, we're already in a much better place!)

loeg 6y ago
Outside of DNS, the other reasons are about local networks, not 127.0/8. There's no good reason to permit port-scanning 127.0/8.
- gsnedders 6y ago
  Still need to know where the top-level page is loaded from, though: you do want to allow requests from 127/8 to "localhost".
- nucleardog 6y ago
  So remove "port scanning" since the only difference between port scanning and "legitimate" connection attempts is rate. Should websockets be able to connect to the local machine? In some cases that could be useful (even if something the kinds of people visiting this site might be uncomfortable with). E.g., a local daemon that listens for a websocket connection and a public web page that's used for managing it. I don't think it was implemented this way, but think something like Battlefield 3's matchmaking: the user visits the online service and finds a match to join, and when they want to join it passes the relevant information to the game via websocket. I imagine stuff like this has been implemented in at least a couple cases that you'd break just wholesale blocking connections to 127/8.
  - neop1x 6y ago
    It can ask user explicitly like it asks for microphone. It is not common for a website page to need access to the local network services as it is to record microphone or request location data. So it's browser fault IMO.
vbezhenar 6y ago
In Kazakhstan we have e-government website. This website allows users to use crypto-tokens to access government services (every citizen can get a digital certificate representing his identity). This website used to run Java applet. This applet was signed and it could access restricted APIs to access USB device. So website talked to applet and applet talked to USB device to sign data. After major web browsers disabled Java applets, they implemented another approach. Now user must install a software which runs a web server on 127.0.0.1. This webserver listens on a specific port and uses web socket to communicate. So government website now uses JavaScript to connect to 127.0.0.1:12345 using websocket. And then it uses that connection to interact with USB device. So an ability for external website to connect to 127.0.0.1 actually is essential for this use-case. My guess is that there are plenty of other websites which use local web server to interact with locally installed software. I know at least one another such a website: Blizzard website. It runs web server in its game launcher and website can communicate with it. PS also they have to install custom trusted certificate because browser requires wss from https and there's no easy way to get a legitimate certificate for that kind of use.

Kipters 6y ago

UWP apps block requests to localhost too for the same reason