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

Should you use Let's Encrypt for internal hostnames?

shkspr.mobi

Post reply on HN
Print view View original

131–140 of 198 posts

Re: Should you use Let's Encrypt for internal hostnames?

#131

Post by ClumsyPilot »

cassianoleal wrote: post #109
Macha wrote: post #69

Earlier quoted context omitted.

I don't go that extreme - my employer is free to install their own root CA on devices they own and supply. I understand some startups are a bit more "Go get your own computer". I think if they paid for it, it's still their device, but once you pay for it out of your own cash, yeah, mdm or root certs are a no go.

Right. I should note that I'm a contractor and I always bring my own tools, which includes the computer. That said, I still prefer to use my own device where I can. It's got the tools I use, configured how I like them, and I'm very familiar with all its quirks which means I have less context switching. I have worked for clients with tighter regulation controls where I was required to use designated devices for certai…

I find having a separate machine has it's advantages, the problem is when IT start managing it they typically so not udnerstand developers and 'standard users' like accountant has totally different needa

Re: Should you use Let's Encrypt for internal hostnames?

#132

Post by ttyprintk »

marcosdumay wrote: post #125
jon-wood wrote: post #117

Earlier quoted context omitted.

One of the examples given wasn't a server name, it was leaking potentially confidential information via the domain olympics-campaign.staging.example.org - in many environments its fine if people know project names, but NDAs are a thing, and you could end up in hot water if you accidentally leak a partnership between two companies before it's been announced.

Well, if instead of making a lot of effort in hiding your names you just didn't, you wouldn't use a name like that. Every single person that connects to any of your networks (very likely the sandboxed mobile one too) can find that name. Basically no place hides it internally. There is very little difference between disclosing it to thousands of the people that care the most about you and disclosing it to everybody on…

The other examples are better. Say a never-before-seen name appears, cisco520.internal.foo.bar. Suddenly, a well-formed email appears, “Re: Cisco Support Ticket #7779311” about some additional steps to provision your new appliance. It is trivial to automate that phish by crawling the CT log.

Re: Should you use Let's Encrypt for internal hostnames?

#133

Post by ClumsyPilot »

My life experience has taught me that it's better to have an imperfect, but simple solution with known limitations (in this case LetsEncrypt), than an ideal solution that you can't configure correctly and do not fully understand (internal CA for a small team).

The former give you known limitations, the latter work fine for a while and you get a great feeling, and then disaster strikes out of the blue.

The same problem plagues IoT solutions and home networking - there are no industry-accepted frameworks to enable encryption on Lan like we do on the real internet. Thrre is no way to know that I connect to my home router or NAS when i type in it's address.

This is an area where we have kind of failed as an industry

Re: Should you use Let's Encrypt for internal hostnames?

#134

Post by ratorx »

Spivak wrote: post #79
YPPH wrote: post #68

Earlier quoted context omitted.

Root certificate stored on offline HSM and intermediates on secure infrastructure. FIPS compliance. (Relatively) reliable revocation services. [See note 0] The result is security of issuance, that is near complete confidence that certificates will only be used for controlled domains (not necessary if you want to MITM of course). Also, ACME is generally easier and more reliable than other certificate rollover processe…

I mean sure but an org doesn’t really need that much security. If you’re not taking that much care with your API keys and db passwords then you probably don’t need it for certs either. Keep your root CA offline and in an air gapped backup, issue team specific intermediates with med length and keep your endpoint certs short. You need as much security on your CA as the accounts in your org with the authority to replace…

That reasoning goes back around. If you don’t need that much security and are fine with exposing internal hostnames via CT logs, then Let’s Encrypt can be nicer (no internal CA to maintain).

It’s just that very specific bit in the middle, where you don’t want to expose the internal hostnames but don’t need top-tier security where having a private CA is worthwhile (assuming outbound internet connectivity to Lets Encrypt is allowed).

Re: Should you use Let's Encrypt for internal hostnames?

#135

Post by spapas82 »

walrus01 wrote: post #122

I run my own internal CA. Would not recommend to anyone that they use publicly-valid letsencrypt certs for internal hostnames, since certificate issuance transparency logs are public and will expose all of the hostnames of your internal infrastructure.

The article answers that: use wildcard certs instead

Re: Should you use Let's Encrypt for internal hostnames?

#136

Post by rusk »

I read somewhere a while ago that LE are working on what’s called “intermediate CA” [0] which would solve the problem. Apparently from a regulatory standpoint there are some questions around abuse that need to be answered before they can go ahead. The basic idea is that you can issue your own certificates based on the LE CA that is already recognised by the browsers.

EDIT [0] https://community.letsencrypt.org/t/does-lets-encrypt-offer-...

Re: Should you use Let's Encrypt for internal hostnames?

#137

Post by memer »

ratcline wrote: post #119
marcosdumay wrote: post #104

I will never understand the obsession people have with hiding their private server names. If somebody gets any access to your local network, there are plenty of ways to enumerate them, and if they can't get access, what's the big deal? I get that you may want to obfuscate your infrastructure details, but leaking infrastructure details on your server names is quite a red flag. It should really not happen. (Instead, yo…

It's mainly mitigating exposure. Some possible vulnerabilities would be social engineering(i.e. it'd be easier to send a targeted phishing URL to gain recon on an employee of a company if you know an internal domain), or injection into a public facing service that has access to internal services.

So, security through obscurity?

Re: Should you use Let's Encrypt for internal hostnames?

#138

Post by hatchnyc »

marcosdumay wrote: post #104

I will never understand the obsession people have with hiding their private server names. If somebody gets any access to your local network, there are plenty of ways to enumerate them, and if they can't get access, what's the big deal? I get that you may want to obfuscate your infrastructure details, but leaking infrastructure details on your server names is quite a red flag. It should really not happen. (Instead, yo…

I think many of us, myself included, have been conditioned to be paranoid—just because I can’t think of/don’t know of any way some data could be abused doesn’t mean I’m going to make it public.

Re: Should you use Let's Encrypt for internal hostnames?

#139

Post by walrus01 »

spapas82 wrote: post #135
walrus01 wrote: post #122

I run my own internal CA. Would not recommend to anyone that they use publicly-valid letsencrypt certs for internal hostnames, since certificate issuance transparency logs are public and will expose all of the hostnames of your internal infrastructure.

The article answers that: use wildcard certs instead

I'd put using wildcard TLS for all your internal stuff in the category of unacceptably weird and unnecessary risk

Re: Should you use Let's Encrypt for internal hostnames?

#140

Post by paxys »

marcosdumay wrote: post #104

I will never understand the obsession people have with hiding their private server names. If somebody gets any access to your local network, there are plenty of ways to enumerate them, and if they can't get access, what's the big deal? I get that you may want to obfuscate your infrastructure details, but leaking infrastructure details on your server names is quite a red flag. It should really not happen. (Instead, yo…

It is a perfectly valid concern. Internal domain names can contain confidential information. They become vectors for attack (especially if running vulnerable software). Obfuscation doesn't mean perfect security but it still goes a long way towards it.
Post reply on HN