Hacker News Reader

Comment by zurn | Hacker News Reader

Let's Encrypt works on internal networks too.

Fun fact: TLS doesn't require certificates, and some browsers even used to support HTTPS in these TLS modes many moons ago. See eg https://security.stackexchange.com/questions/23024/can-diffi...

View on HN

Let's Encrypt only works on public domains that happen to not route externally. I can never (or at least, should never) get LE certificates for *.pikachu.local, but that's a perfectly valid hostname for a local machine.

Ah? That's good to know!

How to set this up on a domain which is not connected to Internet? How is the check done?

It's not easy but iirc you can do it with a DNS-01 challenge, if your internal domain name is valid (doesn't have to resolve to anything though).

The problem is that I also have domains which are completely internal, not known/resolvable outside

This is probably a bad idea and I'd recommend migrating off such names as a background task.

Realistically you can't entirely deconflict these names. So you always have a risk of shadowing names from the public Internet.

The public CAs spent years in denial over this (yes they used to sell publicly trusted certs for "private" names, this is now prohibited). Create internal.example.com and things get easier. To the extent security by obscurity is worth trying it's just as available this way (split horizon DNS etcetera)

> Realistically you can't entirely deconflict these names. So you always have a risk of shadowing names from the public Internet.

It's totally save and legitimate for ycombinator to use secret.ycombinator.com on their intranet without telling anything about it to the outside internet.

Those are names you own, and a CA will happily issue you certs for those names (but Let's Encrypt won't without a DNS record saying the name at least exists)

The grandparent was, as I understand it, talking about names they don't own, for which you've no assurance somebody else won't own them (on the public Internet) tomorrow. This used to be very common, decades ago Microsoft even advised corporations to do it for their AD, but it's a bad idea.

What's with domains such as blubb.mysystem.local or foo.invalid?

.invalid and .local are reserved domains and guaranteed to never be in use on the public internet - yet I can't get certificates for them

If you could get certificates for them, so could anyone else including your adversaries, since there is no system of ownership for them. It would be like issuing certs for https://192.168.1.1

Actually that's why browsers already treat http://127.0.0.1/ and certain other local IPs as if it was via https.

For all local IP and domain space - that is 192.168/16, 10/8 and so on - it should automatically treat them as if they were safe anyway.

They're likely be part of a cafe/hotel/guest wlan or a poorly managed "intranet" full of vulnerable stuff that needs to be shielded from CSRF. That's in addition to having ambiguous addresses. So should definitely be treated as less safe.

Could you run an internal CA server instead of self signing? At least then you reduce your attack surface if you’re compromised internally.

Yes, this is what is being done today.

My point was that HTTPS is (much) more complicated than bare HTTP and this is probably one of the reasons it is not taking over the web in a storm (though progress is undoubtedly there)

It works over DNS. There is a lot written about it on the net, I don't have any specific recommended article.

I now how to do the check over DNS when the name is known outside - the problem is that I have my own internal domain not visible on Internet

You need a registered domain for this. It's a good idea for other reasons too.

Reply on news.ycombinator.com