Hacker News Reader

Comment by urda | Hacker News Reader

I recommend just using something like XCA [1]. Just configure your own root CA and distribute it.

Part of the reason I've been working on this is that the "distribute" step is quite difficult to do at scale across an ever changing set of operating systems and devices. Using a free public CA like Let's Encrypt let's you avoid that challenge since it's trusted out of the box everywhere.

“And distribute it” feels very “draw the rest of the fucking owl”-y to me

Doesn't that require being able to add your root CA on each device you access the application from? That can be a chore in some cases, esp when you want to share the application with others.

For services I host on my Tailscale/Headscale network, I just use DNS challenges. With Cloudflare and Caddy, it's as straightforward as adding:

tls { dns cloudflare {env.CLOUDFLARE_AUTH_TOKEN} }

to the site's configuration in the Caddyfile

<3 Caddy. Here's my equivalent: https://docs.getlocalcert.net/acme-clients/caddy/

This is a poor solution to a non-problem. 99% of "private networks" don't need HTTPS for most things, full-stop. Those that do, the correct solution is to deploy a private CA and use internal DNS. The implication being you do not trust your network. So the solution is to.....use public DNS and Let's Encrypt garbageware and leak details of your internal network so you can pretend you're now more secure because the cafeteria menu is hosted over HTTPS? Save the black hats some time and just email them the Visio of your core network.

If you don't have access to install the root certificate then by definition you don't control the private network, simple as that.

> when you want to share the application with others

This is literally the definition of no longer a "private network".

> 99% of "private networks" don't need HTTPS for most things, full-stop.

The encryption HTTPS provides isn't important if you trust your network. However server authentication is important if your devices move between networks (phone, laptop, etc). Applications don't know you switched networks, they just want to connect and will happily send sensitive data to an attacker if you ever connect to a malicious network. There was an example of `git push` leaking the entire commit history mentioned on HN not too long ago.

> use public DNS and Let's Encrypt garbageware and leak details of your internal network

Wildcard letsencrypt + internal DNS means you don't leak anything and you don't have to deal with the awkwardness of installing certificates.

> This is a poor solution to a non-problem. 99% of "private networks" don't need HTTPS for most things, full-stop.

The problem with your security model is that you assume your private network is flawless. Do you really think you can trust every device that connects to your network to be secure? Including your Wi-Fi router? Because I don't, even for devices I personally bought. Even less so in a corporate setting.

If you don't trust your router I recommend trying out an open source firmware, like OpenWRT or DD-WRT.

> use public DNS and Let's Encrypt garbageware and leak details of your internal network

I've seen certbot take 1+ hour to install on GCE micro VMs because it's so bloated. I've tried implementing the ACME protocol to avoid needing to use it, but it's one of the most byzantine processes I've seen. Let's Encrypt takes so much leverage from the edge to give us something that costs a latte. It's how freedom dies.

This is rescurrecting the mythical "secure internal network". It's been tried, a lot, and found wanting.

Yes you need to install the Root CA into each device's root of trust.

Inconvenient? Maybe. Security rubs against the grain of convenience, true

Reply on news.ycombinator.com