1

I am trying to set up some kind of secure client to web server connection that takes place entirely on local area networks, but I'm having trouble understanding what the recommended best practice is.

Here is my situation: I have many web servers that are each running on their own LAN, and clients will access the web server from within that same LAN. I want to secure all the client-server connections (via HTTPS or anything else) on every LAN that has my web server running on it. The web server does not need to be reachable from the public internet. There will be a backend API running on the same machines that needs to be reachable from public internet, but I do not necessarily have to use HTTPS to secure this (however, would be nice if I can solve both problems with the same solution). I cannot distribute trusted certificates to clients, but I can control DNS and DHCP on the LANs (although I want to avoid this as much as possible). I also own a domain name that I can obtain a trusted certificate for.

I have identified several options, but I'm not sure which ones are even possible and I'm certain that there must be a recommended best practice for this kind of set up. I need someone to tell me what the best practice is and why.

Option 1: Every web server gets the same certificate for the same domain name, and the DNS servers on each LAN resolve the domain name to the appropriate local address.

Option 2: Every web server gets a different certificate for a slightly different domain name (aaa.yyy.com, bbb.yyy.com, ccc.yyy.com, etc.), but they are all handled under the same wildcard certificate. The DNS servers on each LAN resolve the domain name to the appropriate local address as in Option 1. Not sure if this works any differently than Option 1.

Option 3: Every web server gets a different certificate for an entirely different domain name (www.aaa.com, www.bbb.com, www.ccc.com, etc.). This domain name would be specified by the user, and the web server would be able to go ask a CA for a certificate on the fly. Not sure if this works any differently than Options 1 or 2.

Option 4: I create a CA on every LAN, and distribute the CA root certificate to every client. This is not really an option in my set up, but I'd still like to know if it's the recommended best practice.

Option 5: Each web server self signs its own certificate and browser warnings are produced in the clients. Also not really an option in my set up.

Option 6: Use some other type of encryption on top of HTTP. This avoids the DNS configuration hassle, but doesn't prevent man in the middle attacks. Is this standardly used for connections to obfuscate plaintext passwords and whatnot before HTTPS is enabled by a user on the web server GUI?

|improve this question
  • Will these servers be reachable from the public internet? – Purefan May 17 '16 at 13:47
  • No, the web server will not be reachable from the public internet. However, there will be a backend API running on the servers that will be reachable from the public internet. I'll edit my original post to add this info. – jondavidford May 17 '16 at 13:51
  • 1
    why not ipsec ? – Neil McGuigan May 17 '16 at 17:13
  • @NeilMcGuigan interesting suggestion, but I'm not familiar with the details of IPsec and would appreciate some elaboration. I'm unsure exactly where the IPsec would be implemented. Is it possible to only implement IPsec between the web server and client, or does IPsec have to be implemented for all connections on that LAN? – jondavidford May 17 '16 at 17:44
  • Is it a concern if server in one LAN spoofs another? e.g. The administrator of the server in LAN 1 connects his server to LAN 2 in order to spoof the server there? That is the case for having separate certificates for each LAN, and possibly a different CA if the clients on each LAN do not want to trust the servers in other LANs. – SilverlightFox May 18 '16 at 15:48
1

The security is security, no matter the network zone. Yes, there are not so much potential attacckers for LAN-only server, but it's not just leveraged, but hightened by the network speed : one lan attacker on strong/stable/guaranteed 1Gbps speed can try as many passwords, as 100 attackers from the WAN/WWW/Web with unstable connection speed, for example. Use exactly the same techniques and criteria as for a public web server and you will be just fine. I'm using the next checklist working with web servers:

  • Only 256 bit strong ciphers
  • Explicitly disable old, weak and export ciphers
  • Make a DH params at least 4096 bit long and specify them by pointing to a file
  • Make your cert with 16384 key, SHA512 hash. You can use it as a single-domain-name certificate, and you can optionally make it signed by a trusted CA.

The way when you use one cert and routing clients via DNS seems to be proper one for you, but option4 with your own CA seems to be a way more secure(and laborious, sadly) because you will be able to get a client certificate to every client in your network: it will prevent a lot of "my-pass-stolen" cases. But if you'll be implementing Option4, make a single CA for all of your lan's - it will reduce a work amount not touching the security it provides.

|improve this answer
  • Thanks for your response. Of course I must use standard cipher lengths and encryption algorithms in any case. Could you elaborate why option 4 is way more secure than option 1? – jondavidford May 17 '16 at 14:01
  • @jondavidford a client certificate that you're giving th the client personally in real life(that's how it works fine) is a 2nd authenticating factor. And even if a password was stolen - a certificate on a smartcard(SC) or usb key is locked "deathproof", so it is truly "something you have"(as the meaning of 2nd auth factor). You can use the USB key or SC to store additional things, like OpenPGP keys, and make an email secure, for example. <to be continued> – Alexey Vesnin May 17 '16 at 14:11
  • @jondavidford <continuing>: Option1 is server-side cert + authentication by one factor(login+pass). You can try, of course, to have a workaroung like a Google Authenticator App, but it's an additional security factor, not a main one that strengthen the auth. Opt4 is making you sure that it's a user you're thinking of, because the certificate can not be taken out of the USBkey/SC, and this is a main strength gain. Additional bonuses are ensimplified authentication, signatures, e.t.c. – Alexey Vesnin May 17 '16 at 14:15
  • It seems like you are talking about a method to ensure that the server is talking to a valid client (is that accurate?), which I do not care that much about. I want a method for the client to know it is talking to a valid server and that the connection is secure. In other words, username/password are good enough for me to validate a valid client, but I don't want someone to be able to view the username/password or other application data in plaintext if they are sniffing packets on the network. – jondavidford May 17 '16 at 15:04
  • @jondavidford not just valid client, but also to the client you can pinpoint to a physical person being sure that you're right. If you need just to be sure of valid server and nothing more - use strong SSL and Opt1. To protect 100% from net sniff - precisely from "active sniff" by performing MitM - you must use Opt4 with handshakes disabled, i.e. the data are traveling through network encrypted by the keys both parties know preliminary. – Alexey Vesnin May 17 '16 at 15:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.