Hacker News Reader

Comment by zaroth | Hacker News Reader

I say loopback address, you say 127.0.0.1. But did you know we dedicate the entire 127/8 Class A to it? That's a lot of loopback!

Another 'while I'm at it' question I've had for a while. Say you have a micro-service bound to local loopback, you don't want remote code touching it. E.g. I think the BitTorrent Sync WebUI will provide the private keys to any local loopback connection. It can't possibly be secure though, right?

View on HN

No reason it should be insecure (aside from the fact it's giving out the private keys at all). No network stack worth its salt is going to forward packets to 127/8 from outside, and while I often say routing is no substitute for firewalling, in this case there's an implicit firewall in the standards. It doesn't seem inherently any more dangerous than using a unix domain socket (still a socket), or a named pipe, or shared memory.

Actually, thought: can javascript running on a web page make AJAX requests to 127.0.0.1 and access this bittorrent sync thing? I'd think CORS would prevent it, but that might be a danger.

There's a trick of using DNS rebinding to bypass CORS and gain Javascript access to services on 127.0.0.1. Just another reason to make sure you check the Host header!

Yep. It's rather useful too. If you're simultaneously testing multiple services that expect to exclusively bind to a socket, you can set application a to listen on 127.0.0.1, and application b to 127.127.127.127. Beats stopping and restarting by a long shot.

Offhand, the BitTorrent Sync WebUI thing has a rather bad smell to it. There are ways to protect that info from getting out, but it's definitely suspect.

Can't the services just listen on different ports?

For a lot of cases, yes. For cases of things like DNS resolvers, no. There's too much stuff that requires a specific port.

Reply on news.ycombinator.com