How do I run proper HTTPS on an Internal Network?
This question has been asked several times, I'll link a few:
- https://superuser.com/questions/791015/https-over-private-network
- https://stackoverflow.com/questions/616055/https-certificate-for-internal-use
- https://stackoverflow.com/questions/2676238/ssl-signed-certificates-for-internal-use
- Can I buy a signing-valid certificate for internal use?
However, these are old questions and I know that, at least in some respects, the answers provided are out-of-date. I'm providing my research in the hopes that I can find out what parts of it are out-dated and what are still good. I'm looking for modern answers.
The question is straightforward, but here's the situation. I've got web services that access sensitive information (for perspective: it would be bad for our company and our customers, but probably not life-threatening to either). I want to provide easy access to these systems, but security is obviously important. (Some of these services are accessed via non-browser clients, as webservices. Some are simply web pages that humans use from modern browsers.)
To that end, we're keeping the most important services accessible only internally. This way, an attacker is a) unlikely to find them accidentally, and b) has one extra obstacle to overcome.
“Security in depth”, however, would suggest that we also encrypt the traffic internally as well. This makes it even more difficult for someone inside the network to casually sniff passwords off the wire.
In the spirit of “doing my homework” I've gathered several options, some less pleasant than others. I am not entirely certain which of these are even feasible now, because I know that some of the rules have changed.
Self-signed Cert
This seems to be the “go-to” answer for this question most of the times it's asked. This provides resistance to the casual sniffing problem, but I'd have to tell all the employees “the big nasty warning page is fine, just click through it”. I've been working hard to train them to never ignore that page, and most of them wouldn't understand the nuances of “the page is sometimes ok, when you know and expect the site to be using a self-signed cert” (they tend to stop listening at the comma :) ).
Self-signed Cert, but installed and trusted on each system
This fixes the nasty page, I think, but I'd have to set it to be trusted on each and every computer that accessed it. That's possible, but undesirable.
Also, I'm not 100% certain this is even possible for internal addresses any longer. Its my understanding that modern browsers are supposed to refuse any certificate that purports to certify a machine that resolves to a non-public IP address or is not Fully Qualified.
Additionally, the process for installing system root certs on mobile devices is... basically impossible. It requires a rooted Android phone, and a relatively arcane process for iOS devices.
Set up my own CA
Basically the same problem with installed and trusted certs, but I only have to install the root cert, not one cert for every system I stand up. Still basically shuts out all the mobile devices, including the tablets managers like to use in meetings.
I'm even less convinced this would work, because the IPs will be internal and the DNS will not be Fully Qualified.
Use public certs, but for internal addresses.
We could configure fully qualified addresses (like “secret.private.example.com”) to resolve to internal addresses (like “192.168.0.13”). Then, we could use certificates for those public DNS names (possibly even wildcard certs for “*.private.example.com”).
This might or might not work, and it might not even be a good idea. Browsers might reject the cert for trying to resolve to a local address.
If it does work, it might not be a good idea. A laptop taken from our internal system to another network (possibly very quickly, via a VPN disconnect) could attempt to access secret things at local IP addresses on other networks. As long as HSTS is in force, this shouldn't be a big deal, because without our private key they won't be able to convince the client to accept the forged site and won't be able to force a downgrade to HTTP. But it seems undesirable, and it breaks the “no private addresses in public DNS” rule that (maybe?) has gone into effect recently?
So, all this to say... what's the right answer? I could just “give up” and expose the private services publicly, trusting that the encryption and application-specific authentication requirements will keep things safe. Indeed, for some less sensitive things, this is a fine course. But I worry that application-specific authentication could be buggy, or credentials compromised in other ways (people are always the weakest link), and I'd prefer there to be an additional obstacle, if at all reasonable.
