I'm having a hard time understanding the use case here. Using a domain name for loopback IP and generating a cert will work fine for internal use. They're saying it's a security hole because you may need to distribute that private key to users. What exactly is that scenario? Shipping an app with a built-in web server? Not sure I've ever seen that done. And could you not solve it with certificate pinning?
Certificates for localhost
41–50 of 157 posts
Re: Certificates for localhost
#42Earlier quoted context omitted.
> I’ve always liked the concept of a localhost’d web app talking back to a localhost web server. We're doing exactly this prime-time with Relica: https://relicabackup.com (sorry, not much on the landing page yet, but we have emailed out some info about the UI already [1]). That technique will allow us to distribute backup software that works the same for macOS, Linux, BSD, and Windows, right away; screenshot: [2]. An…
Thank you, yes, I think architecturally there are great advantages to splitting up an app like a client/server even when designed primarily to be accessed over localhost. Obviously the “server” API is extremely sensitive and I think you have to assume it is effectively exposed to the outside world, even with a 127.0.0.1 binding and a firewall. I guess if you make localhost users literally login and establish a sessio…
Yeah, we don't trust just anything that comes in on that socket. For example, we implement standard CSRF mitigations like checking Origin/Referer headers. We also don't use DNS at all in the local frontend/backend interactions and require the Origin to be exactly "127.0.0.1" (or the IPv6 equivalent) which is what we bind to.
(Edit: I just looked it up again and I'm 99% sure that web pages can't override the Origin header, especially when making cross-origin requests.)
Re: Certificates for localhost
#43Browsers are solving this by making localhost trusted over http (so webcam, notifications, and other privileged features work work), but here's a more specific guide to getting localhost https working on MacOS - using Keychain and a single command to export the created cert into PEM for your local webserver:
Re: Certificates for localhost
#44I'm having a hard time understanding the use case here. Using a domain name for loopback IP and generating a cert will work fine for internal use. They're saying it's a security hole because you may need to distribute that private key to users. What exactly is that scenario? Shipping an app with a built-in web server? Not sure I've ever seen that done. And could you not solve it with certificate pinning?
HTTP/2 requires https in most (all?) browsers these days. If you’re measuring load times locally this can be a bit of a problem.
Re: Certificates for localhost
#45Earlier quoted context omitted.
Blizzard application installs root certificate: https://news.ycombinator.com/item?id=15982161 I can say that I wasn't even aware about it, it installs absolutely silently. So if you care about it, check it from time to time, because that random application may install it at any time!
It's not a root certificate in the CA sense. It can't sign new certificates and is only for the browser to communicate to the https server running on the same computer. The key isn't even distributed anywhere. It's generated locally and then marked trusted so the browsers don't show warnings. Checking the list of certificates from time to time is a good idea, although I wonder if anyone really does that very often wi…
I agree, but for me their reasoning was weak and I would opt-out of this feature, because it's not even relevant for me. I don't like when someone messes with my trusted certificate store. And they installed that certificate absolutely silently, I learned about it from hacker news.
Re: Certificates for localhost
#46I’ve always liked the concept of a localhost’d web app talking back to a localhost web server. It seems like a great way to get the cross-platform ease of use of developing the UI without having to do everything in browser, so you can optimize the heavy lifting and don’t end up with an Electron app pulling 8Gb of RAM and 100% Of 16 cores. But I could never quite satisfy the nagging feeling that the localhost server c…
This is how, for example, Beats Updater and 1Password browser extensions work on macOS, as I understand it.
Re: Certificates for localhost
#47An absolute joke how many loops one needs to go through to do this very basic thing. Hell, this command line is longer than the code required to start a web server in some programming languages.
In fairness, shorter than `python3 -m http.server` is an awfully low bar.
Re: Certificates for localhost
#48I’ve always liked the concept of a localhost’d web app talking back to a localhost web server. It seems like a great way to get the cross-platform ease of use of developing the UI without having to do everything in browser, so you can optimize the heavy lifting and don’t end up with an Electron app pulling 8Gb of RAM and 100% Of 16 cores. But I could never quite satisfy the nagging feeling that the localhost server c…
git-annex, which uses a web server on localhost for the Assistant UI, uses this process:
- generate a random token
- start the server configured to only accept requests that contain that token
- generate an HTML file that redirects to a local address passing that token, with read permissions only for the current user
- run the browser with that file as argument
In theory, this should prevent external requests, as well as from other users in the same machine.
Re: Certificates for localhost
#49The Plex approach to this kind of problem is pretty interesting: https://blog.filippo.io/how-plex-is-doing-https-for-all-its-... Unfortunately I haven't seen it being done elsewhere. It'd be nice if LetsEncrypt or similar could provide this for more generic everyday use.
As discussed in crbug.com/378566, Chrome currently allows connecting to unsafe WebSockets on localhost. So just use a WebSocket to communicate from your HTTPS hosted page to your local server.
And yes, you definitely should whitelist access based on the origin header.
Re: Certificates for localhost
#50> Traffic sent to 127.0.0.1 is guaranteed not to leave your machine. ...
Isn't that a widely held, but incorrect, assumption?
eg People with reasonable knowledge of IPv4 on *nix can still route 127.0.0.1 traffic out through an external interface?
From memory, people used to do that when attempting to bypass various firewall/filter rules on other hosts for a locally attached network.
Maybe things have tightened up/changed in the last few years?