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

21–30 of 157 posts

Re: Certificates for localhost

#21

Post by matthewmacleod »

rogerbinns wrote: post #16
BillinghamJ wrote: post #13

The 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.

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!

Re: Certificates for localhost

#22

Post by thatha7777 »

I suspect that the default reading of this text means "add your localhost.crt to the system's locally trusted roots" (or worse, "import the root certificate [to your locally trusted roots]"). Although there are methods to "install localhost.crt in your list of locally trusted roots" so that it's only visible to your application, I'm concerned about the naive reading of the post.

I would be very concerned to find that a random application like Spotify, is installing root certificates on my machine, as that would allow them to MITM any connection that doesn't have some kind of key pinning.

Although not exactly the same case, because the driver's shenanigans had no legitimate use, while Spotify does have a legitimate use, an audio driver caught installing a CA root certificate was reported as a CVE vulnerability: https://www.kb.cert.org/vuls/id/446847

Re: Certificates for localhost

#23

Post by vbezhenar »

thatha7777 wrote: post #22

I suspect that the default reading of this text means "add your localhost.crt to the system's locally trusted roots" (or worse, "import the root certificate [to your locally trusted roots]"). Although there are methods to "install localhost.crt in your list of locally trusted roots" so that it's only visible to your application, I'm concerned about the naive reading of the post. I would be very concerned to find that…

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!

Re: Certificates for localhost

#24

Post by vbezhenar »

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…

Theoretically you should be able to use ws://127.0.0.1 from https context but I'm not aware if it's already well supported in the browsers.

Re: Certificates for localhost

#25

Post by schoen »

456hdsaq234g wrote: post #9

Ive found many of these, and reported them to the vendors. Sometimes they are happy (swag!!!), sometimes they are not. This is a great article that explains the issue and work arounds. Your friend is strings blah | grep PRIVATE KEY Run it over your fav bins today!

Note that you can also report it to the issuing CA if the vendor doesn't take action, and the CA will revoke the certificate.

Re: Certificates for localhost

#26

Post by vbezhenar »

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 developers. It's not browser CA, it's some kind of "private" CA (users must import their certificate as a trusted root to work with their website and software).

Re: Certificates for localhost

#27

Post by comex »

thatha7777 wrote: post #22

I suspect that the default reading of this text means "add your localhost.crt to the system's locally trusted roots" (or worse, "import the root certificate [to your locally trusted roots]"). Although there are methods to "install localhost.crt in your list of locally trusted roots" so that it's only visible to your application, I'm concerned about the naive reading of the post. I would be very concerned to find that…

That was with a CA certificate, though. AFAIK, as long as the certificate marked as trusted does not have the CA flag set, and isn’t a wildcard cert for “*” or something silly like that, it can only be used to impersonate the specific domain(s) named in the certificate. Thus, even if the certificate is in the system global trust cache, it wouldn’t allow anyone to “MITM any connection that doesn't have some kind of key pinning”, only connections to that site. However, I can’t rule out that trusting a certificate for “localhost” for which an attacker knows the private key could still cause some sort of security vulnerability, though I’m not sure what exactly it would be.

Re: Certificates for localhost

#28

Post by vbezhenar »

Macha wrote: post #15
gruez wrote: post #3

Earlier quoted context omitted.

from TFA: >It’s possible to set up your own domain name that happens to resolve to 127.0.0.1, and get a certificate for it using the DNS challenge. However, this is generally a bad idea and there are better options.

I read that as being about the actual public DNS, not your own local hosts file?

Malicious network could forge DNS responses and direct user into fake server. HTTPS should protect user, because face server can't own proper certificate for that domain. But if private key is leaked, this attack could work.

Re: Certificates for localhost

#29

Post by judge2020 »

Relevant discussion regarding Activision/Blizzard's use of the domain "localbattle.net" (pointing to 127.0.0.1) for localhost communication with the agent:

Reddit: https://www.reddit.com/r/heroesofthestorm/comments/7lb8vq/he...

Blizzard response: https://us.battle.net/forums/en/bnet/topic/20760626838

Re: Certificates for localhost

#30

Post by rcfox »

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…

> But I could never quite satisfy the nagging feeling that the localhost server could adequately be secured against outside network requests being routed to it, or as TFA mentions, inside network requests being routed away from it to an outsider!

Wouldn't that be solved by binding your listener to 127.0.0.1 (as opposed to 0.0.0.0 or your actual IP)? Sending a request to 127.0.0.1 shouldn't be able to send anything to the network.

Post reply on HN