←back to thread

563 points joncfoo | 1 comments | | HN request time: 1.015s | source
Show context
8organicbits ◴[] No.41205729[source]
My biggest frustration with .internal is that it requires a private certificate authority. Lots of organizations struggle to fully set up trust for the private CA on all internal systems. When you add BYOD or contractor systems, it's a mess.

Using a publicly valid domain offers a number of benefits, like being able to use a free public CA like Lets Encrypt. Every machine will trust your internal certificates out of the box, so there is minimal toil.

Last year I built getlocalcert [1] as a free way to automate this approach. It allows you to register a subdomain, publish TXT records for ACME DNS certificate validation, and use your own internal DNS server for all private use.

[1] https://www.getlocalcert.net/

replies(12): >>41206030 #>>41206106 #>>41206231 #>>41206513 #>>41206719 #>>41206776 #>>41206828 #>>41207112 #>>41208240 #>>41208353 #>>41208964 #>>41210736 #
yjftsjthsd-h ◴[] No.41206513[source]
Do you mean to say that your biggest frustration with HTTPS on .internal is that it requires a private certificate authority? Because I'm running plain HTTP to .internal sites and it works fine.
replies(6): >>41206577 #>>41206657 #>>41206669 #>>41208198 #>>41208358 #>>41210486 #
lysace ◴[] No.41206577[source]
There's some every packet shall be encrypted, even in minimal private VPCs lore going on. I'm blaming PCI-DSS.
replies(5): >>41206652 #>>41206686 #>>41206797 #>>41207668 #>>41207971 #
bruce511 ◴[] No.41206652[source]
The big problem with running unencrypted HTTP on a LAN is that it's terribly easy for (most) LANs to be compromised.

Let's start with the obvious; wifi. If you're visiting a company and ask the receptionist for the wifi password you'll likely get it.

Next are eternity ports. Sitting waiting in a meeting room, plug your laptop into the ethernet port and you're in.

And of course it's not just hardware, any software running on any machine makes the LAN just as vulnerable.

Sure, you can design a LAN to be secure. You can make sure there's no way to get onto it. But the -developer- and -network maintainer- are 2 different guys, or more likely different departments. As a developer are you convinced the LAN will be as secure in 10 years as it is today? 5 years? 1 year after that new intern arrives and takes over maintainence 6 weeks in?

What starts out as "minimal private VPC" grows, changes, is fluid. Treating it as secure today is one thing. Trusting it to remain secure 10 years from now is another.

In 99.9% of cases your LAN traffic should be secure. This us the message -developers- need to hear. Don't rely on some other department to secure your system. Do it yourself.

replies(4): >>41207245 #>>41207321 #>>41207535 #>>41212678 #
1. gorgoiler ◴[] No.41207245[source]
Well said. I used to be of the mindset that if I ran VLANs I could at least segregate the good guys from the evil AliExpress wifi connected toasters. Now everything feels like it could become hostile at any moment and so, on that basis, we all share the same network with shields up as if it were the plain, scary Internet. It feels a lot safer.

I guess my toaster is going to hack my printer someday, but at least it won’t get into my properly-secured laptop that makes no assumptions the local network is “safe”.