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

81–90 of 157 posts

Re: Certificates for localhost

#81

Post by rogerbinns »

pstuart wrote: post #18
rogerbinns wrote: post #16

Earlier quoted context omitted.

I'm desperate for this. The hardware product I work on can be controlled by a mobile app. It was a very deliberate decision to not make the hardware product and mobile app both have to talk to a remote server acting as a proxy between the two. But that leaves me using plain http between the two.

Couldn't you use it to coordinate NAT punchthrough?

The mobile app (or web browser) are on the same network (subnet) as the hardware device. There is no need for NAT or anything else. Zeroconf is used for discovery.

There is little threat in most home networks, but I still prefer using SSL. If we only had to support the mobile app then we could implement a solution (eg ssh style trust on first use with self signed certificates). However we also have to support regular browsers which constrains us to standard protocols and security.

Re: Certificates for localhost

#82

Post by mholt »

woolvalley wrote: post #75
mholt wrote: post #33

Earlier 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…

So how do you compare to arq backup or borg backup? Other than your choice of using a web browser tab for UI?

Great question. More details coming out soon on our mailing list and Twitter---and there's so many factors to consider---but in short, Relica:

- is designed for consumers who are not technically skilled

- works on Linux and BSD (I don't think Arq does)

- offers redundant cloud storage with up to 5 providers, and requires only a single upload of the data as compared to uploading it 5 times

- allows you to backup to local disk, friends' computers (or your own) running Relica (with authorization of course), or the cloud, which is totally managed by us so non-technical users can use it

Relica also does client-side encryption and deduplication, of course. Backups can also be restored directly with restic (open source), without requiring a reliance on Relica.

Basically, Relica is a good balance of "user-friendly" combined with features for power users.

Re: Certificates for localhost

#83

Post by rogerbinns »

matthewmacleod wrote: post #21
rogerbinns wrote: post #16

Earlier quoted context omitted.

I'm desperate for this. The hardware product I work on can be controlled by a mobile app. It was a very deliberate decision to not make the hardware product and mobile app both have to talk to a remote server acting as a proxy between the two. But that leaves me using plain http between the two.

We ended up using the WebRTC data channel to set up communication between our hardware product and mobile app. There’s still a necessity for a signalling server in between to set up the communication, and a STUN/TURN server to proxy where it’s not possible to set up direct channels. But the whole thing is super low latency and uses DTLS, so it’s a nice alternative for many use cases!

> We ended up using the WebRTC data channel ...

That is an interesting approach. Unfortunately we also have to support browsers so it doesn't look like we could use it. (You have to type in http://something to get the page that does the webrtc as far as I can tell.)

Re: Certificates for localhost

#84

Post by cjm »

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.

Re: Certificates for localhost

#85

Post by progval »

hamandcheese wrote: post #72
progval wrote: post #65

Earlier quoted context omitted.

Isn't this exactly what the blog post is saying not to do? > By introducing a domain name instead of an IP address, you make it possible for an attacker to Man in the Middle (MitM) the DNS lookup and inject a response that points to a different IP address. The attacker can then pretend to be the local app and send fake responses back to the web app, which may compromise your account on the web app side, depending on…

Only if you ship the private key with your app. Otherwise the MITM will fail certificate validation.

Oh, indeed.

Re: Certificates for localhost

#86

Post by progval »

aethr wrote: post #79
hamandcheese wrote: post #72

Earlier quoted context omitted.

Only if you ship the private key with your app. Otherwise the MITM will fail certificate validation.

How would you run a local HTTPS server without the private key?

They get one private key per user, and send it to the client's device.

Re: Certificates for localhost

#87

Post by orf »

mholt wrote: post #42
zaroth wrote: post #36

Earlier quoted context omitted.

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 he…

> 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

What about other, potentially unprivileged software running on your machine that can?

Re: Certificates for localhost

#88

Post by mholt »

orf wrote: post #87
mholt wrote: post #42

Earlier quoted context omitted.

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 he…

> 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 What about other, potentially unprivileged software running on your machine that can?

If you've got rogue software running on your machine, all bets are off.

Re: Certificates for localhost

#89

Post by skim_milk »

vbezhenar wrote: post #26

There's government CA in Kazakhstan issuing certificates for people and for some government websites. They have software for people, so their website can talk to USB tokens. This website connects to that software via secure websockets at 127.0.0.1. And they bundle private key for 127.0.0.1 issued by that CA inside that application. Is it bad? I guess there's no point to report it to them, because they are CA and deve…

I worked for a place that did something similar, they were running a server on their local machines listening to https://localhost.company.com:someport (resolving to 127.0.0.1) so their javascript frontend hosted at example.com could communicate with their local machine. It was set up so the server would only respond to requests originating from company.com. They distributed the private key for the certificate localhost.company.com which was trusted by all browsers.

What kind of risk is there to having the private key to localhost.company.com?

Re: Certificates for localhost

#90

Post by caf »

mholt wrote: post #42
zaroth wrote: post #36

Earlier quoted context omitted.

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 he…

It seems like there could be unexpected interactions with other services running on 127.0.0.1, which don't even have to be HTTP to cause problems - eg what if there's a service that echoes back the request in the response if it receives a request it doesn't understand? A remote web page could probably use that to bounce its request to your service but appear to come from 127.0.0.1.
Post reply on HN