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

Certificates for localhost

letsencrypt.org

Post reply on HN
Print view View original

111–120 of 157 posts

Re: Certificates for localhost

#111

Post by somebee »

tootie wrote: post #41

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?

We have a need for this at scrimba.com, where we are now developing a way for people to record coding casts with access to local files and your local terminal. We want to let people record from any directory using a simple CLI (you only need to install an npm package). This will start a websocket-server locally, and then open up your browser at scrimba.com - which connects to said socket. This works in chrome since we're allowed to connect to ws://127.0.0.1, but other browsers need another solution.

MITM is not a problem, since the only communication with the socket is to read files etc from your local machine, and a malicious third party have nothing to gain, and no real way to fool you.

Re: Certificates for localhost

#112

Post by beagle3 »

Everyone here and TFA talk about 127.0.0.1 (a.k.a localhost), but the entire 127.0.0.0/8 subnet is routed to the local machine - does anyone here know how the browsers treat the other addresses?

Do they compare to 127.0.0.1? to 127.0.0.0/8? Do they consult the routing table?

Re: Certificates for localhost

#113

Post by mholt »

voltagex_ wrote: post #110
mholt wrote: post #106

Earlier quoted context omitted.

We replicate your upload after it leaves your computer (at the packet level - we can't decrypt your data, we don't even have the key for it). There were quite a few technical hurdles we had to overcome to make this work, but I gotta admit, it's really cool to see it in action. :)

I recognise that username! Hello. This does raise the question of how fast the upload will be - how's your network? Switching from Dropbox to OneDrive doubled my upload speed simply because there's better peering from my ISP to Akamai vs whatever Dropbox was using at the time.

Hi there! Our upload infrastructure is designed to scale to anywhere in the world where we decide to put up relays. That makes the speed variable depending on where you are and where the relay is. We are still testing on our staging infrastructure and haven't deployed to our production networks yet, so it's hard to say right now what our speeds will be. But I'd love to know more about what your speeds are like now and what you expect with your backup service. Could you tweet at either me (@mholt6), @relicabackup, or email support-at-relicabackup.com and I'll get back to you on that?

Re: Certificates for localhost

#114

Post by anty »

rootusrootus wrote: post #20

I was hoping for a good answer, rather than "this is hard and it will just get worse." We have an old app that my team is modernizing with this exact situation. Uses websockets now, but that's an historical thing and all the web apps were non-secure so it worked okay. Now everyone wants SSL turned on, and this puts the websocket method in jeopardy. Somebody before me decided we should switch all the inter-app communi…

Same here. We use a subdomain with HTTPS that points to 127.0.0.1, and a WebSockets-Server on our clients machines. We install the private key on each machine for this to work... yeah.

It's always a nightmare, when a browser-upgrade comes along and changes something.

Currently the following connections work:

"wss://localhost.example.com:4321/somepath", // Mac: Chrome, Safari, FF

"wss://localhost:4321/somepath", // Win: Chrome, FF

"wss://127.0.0.1:4320/somepath" // Win: EDGE, IE11, IE10

Some other combinations are possible, that's just what I know we use atm.

The worst thing is: I didn't find a way to catch connection-errors to these URLs. So I have to use timeouts, and try all of them... (or decide by User-Agent which URLs to try.)

I wish there would be some kind of standard that solves this problem.

Re: Certificates for localhost

#115

Post by zaarn »

zaroth wrote: post #12

I’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…

I usually write a special middleware in golang for this. It sits in front of the actual router and http handlers and also buffers the response so it can modify it if necessary (this is unrelated to localhost security). Off the top of my head the checks are basically:

1. Who is the remote IP? 2. What does the origin and refer header say? 3. What does it say in the host? (I always enforce a whitelist for localhost applications) 4. Analyze the other headers? Anything out of the ordinary? 5. Enforce a strict CORS policy on ALL requests, no exceptions 6. Minimize contact points if external APIs are called (separate routers, preferably on a separate port) 7. Enforce a strict CSP policy (self only, no insecure eval or anything) on ALL requests 8. If outgoing requests are required, write a portal that they must go through (ie a common http client instance) that enforces where the requests are allowed to go)

Re: Certificates for localhost

#116

Post by [deleted] »

orf wrote: post #76
zaroth wrote: post #12

I’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 the Dell system detect utility worked. Back in the day I found out that they only checked if the referring domain ended with dell.com, so 'notdell.com' passed their validation[1]. Instant easy unstoppable root RCE on a lot of dell machines from any website (it was a get request as well if I remember correctly). No built in auto update, no system tray icon, no idea if it's running. Good times. I found some…

[deleted]

Re: Certificates for localhost

#118

Post by gerdesj »

yebyen wrote: post #66
justinclift wrote: post #63

Earlier quoted context omitted.

Ahhh yeah. But that's how most OS's set things up by default, in order to meet the required specs. (bugs and implementations hiccups aside) Once the OS is up and running, manipulation of the routing tables at least _used_ to make this possible on Linux and Solaris. Not sure about FreeBSD, but that's just from memory fuzziness on my part. :)

> Traffic sent to 127.0.0.1 is guaranteed not to leave your machine This is definitely false, without any routing tables. Any unprivileged user can start an SSH tunnel listening on any localhost port above 1024, sending traffic out to wherever.

Sent to is not the same as sent from

Re: Certificates for localhost

#119

Post by piva00 »

mholt wrote: post #53
mafro wrote: post #52

Earlier quoted context omitted.

Interesting! How do you go about binding an unused port on client machines?

Use port :0 to let the OS choose one. But for now we just hard-code a port. I personally prefer this since it's easy to use and convenient to remember. But if a lot of client machines have conflicts, I guess we'll change that...

Why not just change that? You are already in the same host, you can write the port that the server bound to on startup to a file and just read that from the client.

I've implemented something similar and went through the same stage "I will wait until someone complains" and they will happen, just prevent them right now :)

Re: Certificates for localhost

#120

Post by xg15 »

cjm wrote: post #84
xg15 wrote: post #51

What I don't understand is this bit: > Fortunately, modern browsers consider “ http://127.0.0.1:8000/" to be a “potentially trustworthy” URL . [...] WebSockets don’t get this treatment for either name. It's good they at least added an exception for (verifyable) localhost access - but then why is the exception only given for HTTP? There seems to be a deliberate restriction that websockets are excluded. I find this kin…

Chrome permits access to ws://127.0.0.1 from https apps. I believe it's also making its way to Firefox, which is currently http only. Other browsers (ie/edge/safari) don't even follow this exception for http yet.

Interesting. My impression from the above bug was that they explicitly decided against keeping it open. If they reversed their position, that would be good news.

Could you give a link where this is discussed? I see crbug.com/378566 mentioned in another comment, but there doesn't seem to be a decision in there, apart from general acknowledgement that the use-case exists.

Post reply on HN