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

71–80 of 157 posts

Re: Certificates for localhost

#71

Post by kilburn »

AgentME wrote: post #69
kilburn wrote: post #62

Earlier quoted context omitted.

> What exactly is that scenario? Shipping an app with a built-in web server? I've had this need a couple times. My scenario: web-based application that needs to use some usb-gadget (NFC reader for example). You cannot access the device directly because there's no (standard) Browser NFC Reader API implemented in the browsers. You need native code to access that device. Yet your entire application is web-based, and it…

>Wrong, because your web application should be using https. For security reasons, the browser will _not_ allow connections from an https-page to a non-https (or secured web sockets) server. Thus, your native app's exposed API must use https/wss too. And here is where the article's ordeal begins. The article also says that the website could make requests to http://127.0.0.1:portnumber/ and browsers will allow that eve…

It works for http requests, but not for websockets (the article also mentions that). If you want decent bidirectional communication (no polling, i.e., the kind you'd want to get reads from an NFC reader) that's not a good option.

Also, I'm willing to bet browsers will block that at some point too...

Re: Certificates for localhost

#72

Post by hamandcheese »

progval wrote: post #65
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.

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.

Re: Certificates for localhost

#73

Post by lisper »

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?

> Shipping an app with a built-in web server? Not sure I've ever seen that done.

We did it. We developed an enterprise app as a web app, but some of our customers insisted on having it run locally because of security concerns. So we just packaged up the server with a thin client and voila! What might have been a months-long re-development took a couple of hours.

Re: Certificates for localhost

#74

Post by ytjohn »

AgentME wrote: post #69
kilburn wrote: post #62

Earlier quoted context omitted.

> What exactly is that scenario? Shipping an app with a built-in web server? I've had this need a couple times. My scenario: web-based application that needs to use some usb-gadget (NFC reader for example). You cannot access the device directly because there's no (standard) Browser NFC Reader API implemented in the browsers. You need native code to access that device. Yet your entire application is web-based, and it…

>Wrong, because your web application should be using https. For security reasons, the browser will _not_ allow connections from an https-page to a non-https (or secured web sockets) server. Thus, your native app's exposed API must use https/wss too. And here is where the article's ordeal begins. The article also says that the website could make requests to http://127.0.0.1:portnumber/ and browsers will allow that eve…

But not websockets though.

Re: Certificates for localhost

#75

Post by woolvalley »

mholt wrote: post #33
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’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?

Re: Certificates for localhost

#76

Post by orf »

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 something similar with HP as well[2]. Since then I'm ok with not having this functionality used and abused too much. There is too much scope for things to go wrong, and badly so.

1. https://tomforb.es/dell-system-detect-rce-vulnerability

2. https://tomforb.es/hp-support-solutions-framework-security-i...

Re: Certificates for localhost

#77

Post by inopinatus »

eximius wrote: post #68
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…

It would be neat if you could listen to a unix domain socket and have a simple way to specify that as an endpoint for an http URI. i.e., http://[uds/path/to/uds.socket] I reuse ipv6's current syntax here just for the example. A lot of bikeshedding would be needed. It would also be ugly to expose those kinds of internals to an end user, so you'd need some additional technology on top of this to look pretty.

There is an unofficial unix: URI scheme. Browsers don't support it but system clients sometimes do, for example nginx when configuring upstream groups as a reverse proxy[1].

[1] http://nginx.org/en/docs/http/ngx_http_upstream_module.html

Re: Certificates for localhost

#78

Post by jadbox »

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…

While a huge pain the ass, it could be possible for your local app server to create a [bridged] virtual host network that routes locally for your server. It utterly ridiculous to resort to this method though. Does anyone else have an idea of a workaround?

Re: Certificates for localhost

#79

Post by aethr »

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.

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

Re: Certificates for localhost

#80

Post by aethr »

progval wrote: post #65
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.

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…

Couldn't the web app also verify that the localhost.example.com domain resolves to 127.0.0.1 before attempting a connection?
Post reply on HN