5 ms·

I recommend just using something like XCA [1]. Just configure your own root CA and distribute it. [1] https://hohnstaedt.de/xca/ https://hohnstaedt.de/xca/

by urda 3y ago

8organicbits 3y ago
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.
abound 3y ago
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
- 8organicbits 3y ago
  <3 Caddy. Here's my equivalent: https://docs.getlocalcert.net/acme-clients/caddy/ https://docs.getlocalcert.net/acme-clients/caddy/
- housemusicfan 3y ago
  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".
  - 8organicbits 3y ago
    > 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.
  - smarkov 3y 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.
  - soraminazuki 3y ago
    > 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.
    - shrx 3y ago
      If you don't trust your router I recommend trying out an open source firmware, like OpenWRT or DD-WRT.
  - jart 3y ago
    > 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.
  - 3y ago
- worik 3y ago
  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
bryancoxwell 3y ago
“And distribute it” feels very “draw the rest of the fucking owl”-y to me

I recommend just using something like XCA [1]. Just configure your own root CA and distribute it. [1] https://hohnstaedt.de/xca/ https://hohnstaedt.de/xca/

by urda 3y ago

I recommend just using something like XCA [1]. Just configure your own root CA and distribute it. [1] https://hohnstaedt.de/xca/ https://hohnstaedt.de/xca/

8organicbits 3y ago

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.

abound 3y ago

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

8organicbits 3y ago
<3 Caddy. Here's my equivalent: https://docs.getlocalcert.net/acme-clients/caddy/ https://docs.getlocalcert.net/acme-clients/caddy/
housemusicfan 3y ago
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".
- 8organicbits 3y ago
  > 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.
- smarkov 3y 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.
- soraminazuki 3y ago
  > 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.
  - shrx 3y ago
    If you don't trust your router I recommend trying out an open source firmware, like OpenWRT or DD-WRT.
- jart 3y ago
  > 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.
- 3y ago
worik 3y ago
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

bryancoxwell 3y ago

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