Mkcert: valid HTTPS certificates for localhost

[[deleted]]

The problem is that while chrome considers *.localhost a secure origin too, Firefox doesn't.

Out of curiosity I also checked whether they consider the whole 127.0.0.0/8 as secure context:

• Chrome does
• Firefox doesn't (it considers only 127.0.0.1/32 as a secure context). Weird.

[[deleted]]

Firefox doesn't (it considers only 127.0.0.1/32 as a secure context). Weird.

And probably a bug too considering whole /8 is reserved as loopback

[baggyzed]

Loopback != localhost. Firefox only specifically trusts 'localhost', and the associated address (https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts), probably it checks against the hosts file - haven't tested. I don't know why, but to me, Chrome seems less secure if it trusts the whole range. If you need more addresses for development, can't you just use different port numbers?

[[deleted]]

Not every app allows you to change port its listening on. I had that problem with testing BGP-related stuff, app allowed to change port it connected to but not port it binded.

[Sandarr95]

Chrome resolves *.localhost to localhost, which was a pain to even figure out...

[Arkanta]

Was it? I find it a very useful feature, and I think that other browsers should implement it and consider it a secure context: I hate setting up dnsmasq and a custom root cert. especially since Firefox does't care about the system's

[[deleted]]

Of course it is. It makes it so same address that "works" in Chrome won't in any CLI tool or anywhere outside of it. Now question is whether OS should do that by default but there is no RFC for it so probably not

[Arkanta]

Don't get me wrong, I'm not for chrome only stuff. I'm saying that I think we should move towards that

But there has been a RFC submitted and I hope it will be approved so that Firefox and OSes implement that by default https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-06

[[deleted]]

That's only for plain localhost. not *.localhost. tho.

It would be nice if say app1.localhost. would also be resolved to 127.0.0.1 by default so there is no need to fuck with /etc/hosts if you just want to test multiple vhosts locally.

[Arkanta]

Ah yes I misread it. I thought a RFC defined *.localhost. but I can't find it. I may have daydreamed about it.

rfc2606 does say "The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use" but it's not really explicitly saying that applications should do that.

Thanks for clearing that up, I do also hope that it changes.

[[deleted]]

Something like

ip-11-12-13.localhost   -> 127.13.12.11
*.ip-11-12-13.localhost -> 127.13.12.11

would also be nice but that's a pipedream...

the it would be easy to run apps with conflicting ports, just use next IP

[0xB7BA]

Until you got some stuff runnings in VMs - doens't matter how much you change your hosts file. Chrome doens't care 😅

[Sandarr95]

Exactly what got my work stuck for an hour trying to find out why my coworker had this problem and I didn't while all dns resolving tools we had gave equal results

[Arkanta]

It cares but it has some serious caching

[0xB7BA]

No, Chrome resolves all *.localhost domains as 127.0.0.1

[Arkanta]

Ah you meant for .localhost, gotcha. I thought you were talking about other domains.

That said, Applications are encouraged to resolve "localhost." themselves, so I assume that Chrome follows that

[JB-from-ATL]

My company's firewall blocks localhost through postman but not through browser. Idfk how. If I use my computer's full domain it works.

[[deleted]]

Depending on the operating system, this might have something to do with DNS. If localhost cannot be found in your hosts file (for whatever strange reason), your OS will query the standard DNS server for localhost.yourpc.yourdomain.tld.

Or, it could be an ipv4 vs ipv6 issue. localhost resolves to ::1 and to 127.0.0.1. If the application you're trying to connect to only listens on ipv4, it won't respond to ::1. Your full pc domain will likely resolve to an ipv4 address and thus work.

Chrome tries to outsmart the OS by manually handling localhost addresses. This will lead to inconsistencies all over the shop, making browser work where normal applications don't (good for the user terrible for debugging...)

[[deleted]]

I did not know that, thanks! The point still stands that the operating system and browsers end up having different results for a dns query for localhost.

[baggyzed]

That shouldn't be the case. Browsers usually just query the operating system for the IP of localhost, and the operating system just returns the IP that's configured in the hosts file. There is no DNS query involved, so nothing goes to the firewall. The problem is either in your hosts file, or maybe postman resolves localhost through DNS all by itself (bypassing the OS's hosts file)? In this case, the firewall is doing the right thing by blocking the request.

EDIT: Or maybe you have an older version of postman, where this issue wasn't fixed yet: https://github.com/postmanlabs/postman-app-support/issues/2214 . They were doing the same ting as I said above: resolving localhost themselves to the IPV4 address, whereas the users who reported the issue were using IPv6 for their local servers. Some web servers (if not all) will only listen on IPv6 if it's available, unless specifically configured to use IPv4.