Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Document reasoning to block DNS to 127.0.0.1

github.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Document reasoning to block DNS to 127.0.0.1

#31

Post by jeroenhd »

SahAssar wrote: post #17
jeroenhd wrote: post #8

Annoying, but understandable. There's a reason localhost gets special treatment, as do many other local addresses. Local dev sites easily form a fingerprint that you don't want trackers to be able to use. I'm not sure why this applies to first party browsing, though. In its current form ( https://github.com/easylist/easylist/blob/master/easyprivacy... ) several of these domains got the $third_party modifier which sho…

> Besides that, you can't get HTTPS for these domains (without the mess of a custom CA and even then you'll run into CT issues) Of course you can, you just cant use HTTP validation for it. Use DNS validation and it works fine.

Not if you don't control the DNS. I don't know who controls fbi.com but I sure can't get a trusted certificate for it

Re: Document reasoning to block DNS to 127.0.0.1

#32

Post by jeroenhd »

hnbear wrote: post #11
jeroenhd wrote: post #8

Annoying, but understandable. There's a reason localhost gets special treatment, as do many other local addresses. Local dev sites easily form a fingerprint that you don't want trackers to be able to use. I'm not sure why this applies to first party browsing, though. In its current form ( https://github.com/easylist/easylist/blob/master/easyprivacy... ) several of these domains got the $third_party modifier which sho…

I thought about the cert thing here too. I own a domain and internally use local.domain.com for all internal sites. Wildcard and specific names. I can generate certs using ACME/LetsEncrypt. So, everything, including test sites could be on that domain. For reference, I use PiHole and OpnSense, and internally machines in DHCP and static IPs get local.mydomain.com resolution too.

You can generate valid certificates for the domains you own and make the DNS point at anything you like. It's quite a pain for a dev setup (LE certificates only lasting three months, so long enough to forget about your setup but short enough that you'll need to keep running it).

In this specific case, it's about, a bunch of generic domains set up by other people.

In your pihole example the situation would be even better because you don't need to publish A records for the domains anywhere. That means nobody can abuse your domain for fingerprinting workarounds but you still maintain complete control.

Re: Document reasoning to block DNS to 127.0.0.1

#33

Post by pravus »

albert_e wrote: post #23
LinuxBender wrote: post #12

Earlier quoted context omitted.

I've debated that reasoning in the security field and it just goes round-and-round in circles. There are legit cases to avoid this but less about security and more about scanning tools that poorly detect attempts to the loop-back as DNS rebinding attacks vs. an actual DNS rebinding attack which requires malicious code. So avoiding this can avoid some false positives from 3rd party scanners and having to get into sill…

> park wildcard sub-domains on 127.0.0.1 that sounds like a good practice -- why is this not done more often I wonder. EDIT: on a second thought i am not so sure. I am not an expert here so I will not try to guess :)

In my experience most DNS admins abhor the idea of putting private IP addresses in public DNS space and it's simply not even an option they consider. I've used weird DNS tricks like this for years and never really encountered any issues, though. I currently have both my wireguard and private IP networks published to public DNS to make my life easier, for example.

Re: Document reasoning to block DNS to 127.0.0.1

#34

Post by xurizaemon »

jeroenhd wrote: post #30
oefrha wrote: post #18

Earlier quoted context omitted.

> you can't get HTTPS for these domains What are you talking about? Certificate insurance and DNS A/AAAA records are entirely decoupled. Use the ACME dns-01 challenge to get a cert for domains resolving to anything, including 127.0.0.1 or ::1. Alternatively you can even use http-01 or other challenges to get a wildcard cert, with subdomains pointing to localhost. I use Lets Encrypt certs for localhost and LAN every d…

Sure you can get a certificate for those domains, but not the domains you don't own. If I can get a cert for localho.st, someone made a huge mistake. You can set up a localhost redirect on your own domain no problem, and you can even use a local DNS server to make sure nobody can abuse your localhost redirect so your domain doesn't get filtered out by tools like these. However, I assume someone using fbi.com because…

For at least one of these tools / domains, local SSL is available. Details here: https://docs.lando.dev/core/v3/security.html

Re: Document reasoning to block DNS to 127.0.0.1

#35

Post by binary_ninja »

charcircuit wrote: post #3

This is not the right way to block domains that resolve to local addresses even if that was something you desired to do. If you know the IP you want to block you should just block on the IP instead of chasing down every possible address even though addresses can change at any time.

are you suggesting to block 127.0.0.1?

Re: Document reasoning to block DNS to 127.0.0.1

#36

Post by arun-mani-j »

josephcsible wrote: post #4

This is the explanation given by the person who committed this change: > Is a security issue, imagine if you're running a webserver on a site decided to access it from outside, whether to fingerprint you or act nefariously. There should be no reason why a third-party access localhost. But do tell me, why we should we trust sites accessing localhost. It makes no sense to me. Unless someone knows of a better reason, I'…

I was also confused on what's happening until I read this comment: https://github.com/easylist/easylist/issues/16372#issuecomme...

> Stupid example of why it may matter: say you installed LAMP on your computer several years ago, you're not using PHP frequently, and you haven't kept it up to date (so it probably contains a few nasty security vulnerabilities), but it still opens up on boot and listens on localhost.

> Now you open some website, it accesses 127.0.0.1, check for the LAMP vulnerability and exploit it if found. Congratulation, you have been pwn3d.

Interesting but very rare scenario?

Re: Document reasoning to block DNS to 127.0.0.1

#37

Post by adamckay »

Alupis wrote: post #21
josephcsible wrote: post #4

This is the explanation given by the person who committed this change: > Is a security issue, imagine if you're running a webserver on a site decided to access it from outside, whether to fingerprint you or act nefariously. There should be no reason why a third-party access localhost. But do tell me, why we should we trust sites accessing localhost. It makes no sense to me. Unless someone knows of a better reason, I'…

I've got to ask - if you're doing local dev or whatever, what's so hard about turning ublock off for your dev site? The logic seems ok for "out in the wild" cases - but ublock still let's you override stuff if you know what you're doing.

At a previous job I worked on a web-based file sharing app, and to share individual files we used a generic share icon from the font awesome project with appropriate labels.

We got a bug report from someone in the company that the share icon was missing, and after investigating we saw the other icons (for edit and delete) were visible but not sharing. Long story short, they used an adblocker with a setting to block social media sharing links (Facebook likes, Twitter follows, etc) and it was also removing our icon.

In this instance, maybe it'd be fine to turn it off for localhost and keep it on for staging but still...

Re: Document reasoning to block DNS to 127.0.0.1

#38

Post by tentacleuno »

pravus wrote: post #33
albert_e wrote: post #23

Earlier quoted context omitted.

> park wildcard sub-domains on 127.0.0.1 that sounds like a good practice -- why is this not done more often I wonder. EDIT: on a second thought i am not so sure. I am not an expert here so I will not try to guess :)

In my experience most DNS admins abhor the idea of putting private IP addresses in public DNS space and it's simply not even an option they consider. I've used weird DNS tricks like this for years and never really encountered any issues, though. I currently have both my wireguard and private IP networks published to public DNS to make my life easier, for example.

I allow it. I use A records to set individual subdomains of my personal domain to individual Tailscale IPs. Then, when Tailscale is connected, all is well. Is this worth a telling off?

Re: Document reasoning to block DNS to 127.0.0.1

#39

Post by sonuku »

Alupis wrote: post #21
josephcsible wrote: post #4

This is the explanation given by the person who committed this change: > Is a security issue, imagine if you're running a webserver on a site decided to access it from outside, whether to fingerprint you or act nefariously. There should be no reason why a third-party access localhost. But do tell me, why we should we trust sites accessing localhost. It makes no sense to me. Unless someone knows of a better reason, I'…

I've got to ask - if you're doing local dev or whatever, what's so hard about turning ublock off for your dev site? The logic seems ok for "out in the wild" cases - but ublock still let's you override stuff if you know what you're doing.

Generally you want to use what your users use. Running common adblock lists as a dev can help identify /weird stuff/ early.

Plus genuinely the privacy list is good. Just not when it stops the ability to build good.

Re: Document reasoning to block DNS to 127.0.0.1

#40

Post by lopkeny12ko »

I must be in the minority here thinking this move makes total sense.

Once I had to apply a firmware update to a device (don't remember what it was). I had to install some vendor's software but surprisingly the instructions said to then visit a public URL like fwupdate.vendorswebsite.com, which indeed applied the update to my physically connected device.

I dug into it and turns out the software launches a local web server listening on localhost which exposes an API that the website accesses over plain CORS HTTP to localhost. This web server talks to the device connected over USB.

This felt like an egregious breach of privacy--public websites should not be allowed to arbitrarily exchange data with locally-bound servers. Even though this was the intended design of the firmware update process, my browser really should not have let this occur by default without my explicit opt-in.

Post reply on HN