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

131–140 of 157 posts

Re: Certificates for localhost

#131

Post by icebraining »

justinclift wrote: post #63
phlo wrote: post #54

Earlier quoted context omitted.

No, 127.0.0.1 should never appear on any network, and no network device should ever route it. The earliest documentation I was able to find is in RFC 1122 [1] from 1989, but according to RFC 6890 [2], the principle dates back to 1981. [1] https://tools.ietf.org/html/rfc1122#section-3.2.1.3 [2] https://tools.ietf.org/html/rfc6890 (table 4)

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. :)

Yeah, but that would rather involve being on the other side of the airtight hatchway (having root).

Re: Certificates for localhost

#132

Post by captn3m0 »

I run my local apache server with a wildcard certificate for *.captnemo.in. Works perfectly. I forward `$port.in.captnemo.in` -> localhost:$port via Apache for some common ports and can access all my local servers easily over HTTPS.

I can expose some specific service by changing the DNS to my local WLAN ip address (have a script for this that updates the DNS entry in cloudflare).

Re: Certificates for localhost

#133

Post by ajnin »

progval wrote: post #86
aethr wrote: post #79

Earlier quoted context omitted.

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.

Which "compromises" the key, according to current Certificate Authorities policies. Once again the problem boils down to CAs being the sole "anchors of trust" in the current certificate system.

Re: Certificates for localhost

#134

Post by eximius »

inopinatus wrote: post #77
eximius wrote: post #68

Earlier quoted context omitted.

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

But that doesn't specify protocal then, does it?

I.e., http://unix:/path would be very not backwards compatible

Re: Certificates for localhost

#135

Post by krehl »

andrewmd5 wrote: post #59
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.

We built a PKI on top of Lets Encrypt to deliver certificates to all of our users for Rainway: https://rainway.io/technology/ Similar to Plex, users run our software on their PC and then our web based client can connect to it from elsewhere. It’s mainly used as a fallback if WebRTC fails ( https://blog.rainway.io/real-time-communication-for-everyone... ). If there is interest, happy to do a blog post.

No post body was provided.

Re: Certificates for localhost

#136

Post by TorKlingberg »

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…

Well, this is the reason why everything round-trips to a cloud service now.

Re: Certificates for localhost

#137

Post by justinclift »

icebraining wrote: post #131
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. :)

Yeah, but that would rather involve being on the other side of the airtight hatchway (having root).

Good point. :)

Re: Certificates for localhost

#138

Post by vbezhenar »

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.

What prevents you from using letsencrypt? They issue wildcard certificates now. Is there tight limit on number of subdomains?

Re: Certificates for localhost

#140

Post by orf »

mholt wrote: post #104
Ajedi32 wrote: post #98

Earlier quoted context omitted.

Not necessarily. It could be running in a sandbox, or as unprivileged user, and accessing your app's API over localhost would allow for privilege escalation.

I see your point. But in my book, that's still rogue software. And that's a terrible sandbox. :)

I see your point, but you're saying:

> Yeah, we don't trust just anything that comes in on that socket

Well, you are, you're trusting it came from a browser so the Origin header is correct, right?

Post reply on HN