Live data from Hacker News

Easy HTTPS for your private networks

getlocalcert.net

51–60 of 126 posts

Re: Easy HTTPS for your private networks

#51
post #45

Earlier quoted context omitted.

I've been pretty frustrated with how private CAs are supported. Your private root CA can be maliciously used to MITM every domain on the Internet, even though you intend to use it for only a couple domain names. Most people forget to set Name Constraints when they create these and many helper tools lack support [1][2]. Worse, browser support for Name Constraints has been slow [3] and support isn't well tracked [4]. P…

Your private root CA can only be used maliciously if it's compromised. If you use certificate transparency to publicly leak all your local network administrative activities, then you won't need to worry about someone compromising your network because you've already compromised yourself.

Compromise of private CAs isn't always difficult. People store unencrypted keys on SharePoint or send them in email along with the password. There's also cases of rogue IT department staff using the private CA intended to be used for `*.corp` to MITM employee Internet traffic, so "compromise" isn't needed for harm to occur. For companies that do it right, yeah, the concern is minimal.

I think the risk of leaking internal domain names is real, but overblown. If you find a vulnerable internal service via CT logs you still need to connect to the private network to exploit it. If you're connected to the private network, you could have enumerated subdomains many other ways. Early knowledge of vulnerable subdomains can speed up an attack or target selection, but this is still a two step process. Most subdomains are pretty boring anyway; it's not surprising to learn that $corp has subdomains like webmail, wiki, etc. These names don't leak version or brand information.

I was playing with the idea of doing CT log poisoning, where you register and renew certificates for decoy subdomains along side your real subdomain names. If you add enough noise, CT logs are no longer useful for enumerating private subdomains.

Re: Easy HTTPS for your private networks

#52
post #25

Or, it's super easy to roll your own using letsencrypt. 1. Buy your own public domain (such as companyname.dev) 2. Setup a LetsEncrypt wildcard certificate with DNS validation 3. Update your /etc/hosts to something like `127.0.0.1 companyname.dev` We have this working with multiple developers, each renewing their certificates themselves. Works great, it's simple, and don't need to trust an extra third party.

Last time I checked, those wildcard LetsEncrypt certs take more work to get, like passing a DNS-based TXT record challenge. Then once you have the wildcard certs, they only last 3 months. Once obtained, they can manually be copied into the LAN using a tool like wormhole. There's a lot of manual steps here which are far harder than how certbot will auto-renew certs when in the cloud - usually requiring no manual inter…

All the steps are automatable though. I know cause I built it into my own server engine.

This service looks like the same thing. I guess if you're limited to certain then you can only do what it does, but I'm guessing there's lots of alternative software that'll do the DNS challenge if you look.

Re: Easy HTTPS for your private networks

#53
post #16

This is unnecessary It is straightforward to create your own Root CA and use it to sign certificates for your private network, using openssl. Ensure that you implement the V3 extensions with @altnames, for the certificates you issue, with a "DNS => " (or you can use an IP address instead of FDN. I have not experimented with that). .local domain names work fine If you do not implement "@altnames" the certificate will…

I've been pretty frustrated with how private CAs are supported. Your private root CA can be maliciously used to MITM every domain on the Internet, even though you intend to use it for only a couple domain names. Most people forget to set Name Constraints when they create these and many helper tools lack support [1][2]. Worse, browser support for Name Constraints has been slow [3] and support isn't well tracked [4]. P…

Let me put it this way;

You might get away with installing your RootCA on your in-office PCs that you own.

Good luck though getting me to install it on my (external contractor) laptop or my (employee) phone, or my (hosted) VMS machines. -you- may plan to only use the CA for good, but I don't trust you (and by extension all your IT staff, present, past, and future) to be angels.

Re: Easy HTTPS for your private networks

#54
post #39
post #33

Earlier quoted context omitted.

Caddy can act as a proxy for those services. It's ridiculously easy to set-up. mongo.mydomain.com { reverse_proxy 127.0.0.1:27017 }

> but for non-HTTP traffic? Doesn't this only work for HTTP too? It may work with MongoDB because it talks HTTP through TCP 27017, but PostgreSQL, for example, has a proprietary protocol on TCP 5432.

I think you need the layer4 module to get this working.

https://caddyserver.com/docs/modules/layer4

Re: Easy HTTPS for your private networks

#55

Somewhat related - I made a bridge server [1] that lets ACME clients use standard RFC2136 to solve DNS-01 challenges for internal names without them needing credentials for the actual DNS backend (Route 53 in my case). [1] https://github.com/schlarpc/rfc2136_bridge/blob/main/src/rfc...

I did exactly the same for our local-cloud products.

Our local-cloud program connects to our "certificate server", and asks for a name/ip combination.

Our certificate server gets it using API access to our "local-cloud" domain. The local machine receives it.

So the end user does not have the Domain credentials. They have credentials to our cert server, but those have very limited value (and would need to be decrypted first.)

Re: Easy HTTPS for your private networks

#56

Earlier quoted context omitted.

I've been pretty frustrated with how private CAs are supported. Your private root CA can be maliciously used to MITM every domain on the Internet, even though you intend to use it for only a couple domain names. Most people forget to set Name Constraints when they create these and many helper tools lack support [1][2]. Worse, browser support for Name Constraints has been slow [3] and support isn't well tracked [4]. P…

Let me put it this way; You might get away with installing your RootCA on your in-office PCs that you own. Good luck though getting me to install it on my (external contractor) laptop or my (employee) phone, or my (hosted) VMS machines. -you- may plan to only use the CA for good, but I don't trust you (and by extension all your IT staff, present, past, and future) to be angels.

Exactly. It's one of the reasons I use separate VMs per client when I freelance. I want to install the cert, so I don't see the cert warning messages or accidentally click through a real MITM attack, but never on the host OS. That could let the client MITM all sorts of stuff like my email to other clients if Thunderbird syncs at a client site.

Re: Easy HTTPS for your private networks

#57
post #9

Earlier quoted context omitted.

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…

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 caf…

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

Re: Easy HTTPS for your private networks

#58
I really hope DANE will become more popular (and widely supported) some time. Works great on air gapped networks without the need for a publicly trusted CA or Let's Encrypt. No ACME daemon to monitor, just put your public key in a DNS record an forget about it.

Re: Easy HTTPS for your private networks

#60

Cool, but as others said fairly easy to do on your own already. Sort of related but a problem I have been trying to solve is, how to create a trusted certificate for a new device on a private network automatically without any configuration? For example, imagine you are turning up a new router or switch with a Web UI for management. Traditionally this is served on http initially and you can optionally install a cert a…

Sounds like BRSKI [1].

[1]: https://datatracker.ietf.org/doc/rfc8995/

Post reply on HN