Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

techprowd.com

Post reply on HN
Print view View original

41–50 of 94 posts

Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

#41

Post by cassianoleal »

Xylakant wrote: post #12
cassianoleal wrote: post #11

Earlier quoted context omitted.

> Is the fact your internal server 'gubbins.mydomain.com' exists, or even that it exists on 10.0.41.43 really much use? Pretty much this. What does it matter if you know certain hostnames or internal IPs on my network? It's all firewalled anyway, and if it wasn't it would be trivial to find them out on your own...

It may be of interest for attackers that have no visibility into your network and make cross site attacks against you easier. For example, if I know that your router is available at router.network.internal, I might just try and see if your browser is logged in and send you a link to a page that starts making requests against that interface. Enumerating network resources can certainly be done via other ways, but DNS i…

Interesting but 192.168.0.1 or 192.168.1.1 would probably cover 80% of that use case.

This is just security by obscurity. It doesn't add much if you already implement actual security in the form of firewalls, network segregation, etc.

Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

#42

Post by tialaramex »

creztoe wrote: post #26
pm90 wrote: post #8

Earlier quoted context omitted.

In this case, I don’t think there is a gateway involved at all. I believe Let’s encrypt is verifying the authors domains by (essentially) querying their selected DNS provider to prove ownership over a domain, which resolved to a private IP. So iiuc there is no split horizon, it’s just that the sites would only work for the author.

I think you are half correct. The gateway has nothing to do with verifying the file during a DNS challenge. However, the IP of the machine requesting the cert IS saved with that cert information and made public. Let's encrypt will even warn you during the verification process.

The IP of the machine requesting the certificate is recorded by Let's Encrypt, but it is not (ordinarily) made public and certainly isn't (as you can see by inspecting it for yourself) saved with the certificate information.

ISRG is required to keep enough information about the issuances they make to allow them to usefully diagnose problems after the fact. Ideally when we discover a problem it will be possible for the issuer to go back and figure out which (if any) previously issued certificates were affected so that these certificates can be revoked if appropriate.

But although they had at one point planned to publish more of this information, they do not in fact do this routinely.

Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

#43

Post by iso1210 »

haik90 wrote: post #7
aforwardslash wrote: post #3

Keep in mind, adding local entries to your external DNS will expose internal details of your network, such as hostnames and IPs. Same goes for Let's Encrypt, due to Certificate Transparency logging.

for the domain problem I use wildcard dns. for IP I dont think lets encrypt logging the ip address publicly (let me know if I wrong about it), since I use dns-01 I can generate SSL from anywhere.

> for IP I dont think lets encrypt logging the ip address publicly (let me know if I wrong about it), since I use dns-01 I can generate SSL from anywhere.

Yes, if you override DNS (or just provide it) internally then the IP is hidden. The hostname is still leaked though - for example Geodynamics limited have server names of the format fvdcsev01 and fvdccit03 -- https://crt.sh/?id=2381703940

Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

#45

Post by MertsA »

pm90 wrote: post #8
mjevans wrote: post #5

Earlier quoted context omitted.

You'd actually end up with a 'split horizon' setup wherein LetsEncrypt (and the public) see those DNS names with the external gateway's IP and ping that for the validation files. Your options at that point are a central 'well known' directory that different hosts can write to (I recommend sshfs), different directories on one host that are checked for any valid file in any of them (by default) or by hostname match in…

In this case, I don’t think there is a gateway involved at all. I believe Let’s encrypt is verifying the authors domains by (essentially) querying their selected DNS provider to prove ownership over a domain, which resolved to a private IP. So iiuc there is no split horizon, it’s just that the sites would only work for the author.

The host names wouldn't even need to resolve at all outside of the local network. Only the challenge subdomain _acme-challenge.foo.bar.org so certificate transparency will of course expose the existence of foo.bar.org but it wouldn't need to expose anything at all about those DNS records if you wanted to restrict them to only the local network.

Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

#46

Post by iso1210 »

tialaramex wrote: post #39
iso1210 wrote: post #33

Earlier quoted context omitted.

I'm thinking more that if you create your own CA and trust it as a root CA, you are responsible for the security of that CA - it can be used against you. This is especially problematic if I want someone else to trust my certs in their browser, I'm asking them to trust any certificate I generate, including google.com, mybank.com, etc.

I don't want to trust your certificates in my browser, even if you invent all sorts of sophisticated technical hoops to jump through I have no reason to believe you actually did all that hoop jumping. Get certificates for the names you want from a PKI we both trust. The only one that's likely to be applicable is the Web PKI, which is what was done in this article. For some other purposes, where the Web PKI isn't appl…

Yes, I generate a client cert and give it to you, that's not a problem - you aren't trusting the cert at all.

I can secure my servers with my own CA, again that's fine - I trust myself.

If you want to verify my servers signed from my CA though you would need to trust my CA.

Currently that means you would need to import my CA's root certificate. That's bad, it's also the way many corporations work, I've had third party suppliers try to get me to trust their own internally generated root certificates too.

A better solution would be for the user to be able to import a root certificate for use for a set purpose. I'm happy to take foobar inc's certificate to authenticate *.foobar.inc, but not to trust anything else.

For some reason browsers don't allow that - it's all or nothing.

Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

#47

Post by Xylakant »

cassianoleal wrote: post #41
Xylakant wrote: post #12

Earlier quoted context omitted.

It may be of interest for attackers that have no visibility into your network and make cross site attacks against you easier. For example, if I know that your router is available at router.network.internal, I might just try and see if your browser is logged in and send you a link to a page that starts making requests against that interface. Enumerating network resources can certainly be done via other ways, but DNS i…

Interesting but 192.168.0.1 or 192.168.1.1 would probably cover 80% of that use case. This is just security by obscurity. It doesn't add much if you already implement actual security in the form of firewalls, network segregation, etc.

I agree that it's certainly not a substitute for a proper security setup, but it definitely makes an attackers life easier - up to the point where it may get interesting to automate this. So as always, it's a tradeoff. Both options may be acceptable (and I've run a setup where I'd have internal names exposed on public DNS for years), but you need to be aware of the tradeoff to make that judgement.

Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

#48

Post by samgranieri »

phrygian wrote: post #32

I use step-ca [0] for these sort of things and it works brilliantly. I barely see the point of having external DNS servers resolving your internal infrastructure. [0] https://smallstep.com/certificates/

I thought about that but passed because I didn't feel like telling all my browsers to trust that new CA. Yes, that's incredibly lazy.

I bought a real domain name, told my UBNT USG that was the domain for my network, set up the dns servers to use digital ocean, used jetstack's cert-manager [0] to acquire the a wildcart cert using DNS01 instead of HTTP01, and use kubed [1] to synchronize the TLS cert across namespaces. One key thing to consider is that you really should ensure that you use the staging let's encrypt server to test out issuance and see your browser complain about warnings before you switch to production let's encrypt.

Honestly, I don't mind that the cert requests for my domain show up in a CT log.

[0] https://cert-manager.io/

[1] https://cert-manager.io/docs/faq/kubed/

Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

#49

Post by samgranieri »

varbhat wrote: post #22

Instead of using hacky fragile methods , use https://github.com/FiloSottile/mkcert to automate setting up local CA and making it trusted.

I love that program and use that only on my laptop when I'm doing web development paired with nginx and dnsmasq.

I do have to set an environment variable so nodejs trusts it.

Re: Automatic SSL Certificates for internal IP's for home k8 setup using LetsEncrypt

#50

Post by samgranieri »

Schwan wrote: post #21

Its TLS and not SSL. Its TLS for a long time now... And yes be aware that through this, it works fine but you are also exposing your internal infrastructure details through dns. I'm not seeing a big issue, just be aware of it.

Just setup a wildcard cert, apply that to wherever, and you limit how much you expose your internal infra.
Post reply on HN