1

I'm developing a web application that runs on a server local to the same network as the client- basically, instead of a central web server, each customer site will have its own server hosted on the network. The server is CentOS and the clients will be any web browser.

I would like to encrypt the communications between the web browser and the server on the network so that it is difficult for others on the network to see the communications between the client and the server. However, since the client is not going to be accessing the server via a public URL, my understanding is that I cannot use a signed SSL certificate, leaving me open to SSL certificate injection attacks.

I also don't have control over the network these systems are being installed in, so I cannot reliably do MAC filtering or IP range filtering (although these are largely ineffective anyway so that is no big loss).

My questions are: 1. Am I understanding this properly, or am I able to use SSL after all? If so, how? 2. Other than an SSL certificate, what options do I have? I would rather not resort to rolling my own encryption as that would have to be implemented in JavaScript, which would leave me open to an attacker just rewriting the encryption code as its being delivered to the browser.

Thanks for your help/comments!

jssblck
  • 167
  • 1
  • 5
  • How much do you care? PCI compliance requires critical systems to be segregated from general use networks afaik... If you can't do that, then why bother? I mean... You could write a paper (or a dozen) on this topic... http://en.wikipedia.org/wiki/Man-in-the-middle_attack#Defenses_against_the_attack – Daniel Widrick Oct 02 '14 at 00:01
  • 1
    If you are considering implementing crypto in javascript before considering SSL or IPSec, you are probably not prepared to implement crypto in javascript. – DTK Oct 02 '14 at 00:27
  • Good point, DTK. I would have been using CryptoJS or an equivalent, but even so. JS encryption is definitely not something I want to rely on. – jssblck Oct 04 '14 at 00:19

3 Answers3

4

However, since the client is not going to be accessing the server via a public URL, my understanding is that I cannot use a signed SSL certificate, leaving me open to SSL certificate injection attacks.

That is nonsense. There is no requirement that certificates signed by trusted CAs must only be used on publicly-accessible URLs.

Other options? IPSec, OpenVPN, etc. But honestly, getting SSL set up with a trusted certificate is likely your fastest and most simple option. Give your customers the ability to upload their own key/certificate to the server, then they can decide if they want to use a private CA or a public one.

EEAA
  • 109,363
  • 18
  • 175
  • 245
  • Yes, with the caveat: public CAs are in a position of trust. Since he does not own the domains which will be listed as the SubjectCN/SubjectAN on the solution he ships, he will not be able to enroll the certificate for his clients; they will not sign them for someone who is not owner of a domain (and I doubt they would make him a delagate for CA purposes). If one will, they need to be shut down by browser and OS manufacturers ASAP, since that would violate the trust they hold and endanger the whole public internet. Easier might be to serve as his own CA and issue his customers certificate. – DTK Oct 02 '14 at 00:25
  • 1
    Yes, that's a given. With applications like this, though, it's commonplace to give the customer the ability to provide their own certs. Doing so moves the onus of certification procurement from the vendor to the customer, and that is a good thing. – EEAA Oct 02 '14 at 00:26
  • Agreed, it is a good thing in many ways. The developer owning the enrollment process does have some business advantages, as well as some incredibly hairy business exposures. caveat machinator – DTK Oct 02 '14 at 00:30
  • I like this idea the best- thanks for your input. I never even considered having the client use their own certificate. – jssblck Oct 04 '14 at 00:17
1

If you have some control over configuration of the client devices, you could serve as a certifying authority, either using the OpenSSL command, Red Hat/Fedora Dogtag PKI or the CA role for an Active Directory Domain Server.

Create a CA under your control, ask the customers to install the certificate from your CA in their clients' trusted CA store (http://technet.microsoft.com/en-us/library/cc772491.aspx for Windows clients, or use something like Puppet or CFEngine to install your root certificate into /etc/ssl/certs/ca-certificates.crt and the NSS db for Linux).

When you ship the solution to your customers, provide them with a certificate to install in the web server inside your solution (provide them instructions, usually not hard), with the fully-qualified hostname of the server in the SubjectAlternateName in the certificate.

If you need more details, let me know.

DTK
  • 1,718
  • 10
  • 15
  • SSL will be far-and-away the easiest solution. – DTK Oct 02 '14 at 00:21
  • One other thing: by acting as your own CA, you can use this as leverage for paying ongoing maintenance. Set a 366 day expiration on the certificate, and only renew/reissue it if the maintenance contract is up-to-date. – DTK Oct 02 '14 at 00:26
  • 1
    There's not a chance in hell I'd agree to deploy some other organization's CA Cert into the trust store across my machines, nor would I expect any competent admin to allow such a thing. – EEAA Oct 02 '14 at 00:29
  • I've seen the practice semi-regularly in Fortune-rated companies that communicate with vendors and governmental entities over a private network (non-internet-facing), with appropriate contractual controls. This is not a sysadmin/technical question, it is a trust, INFOSEC and contract/relationship question. In some cases, there are governmental and quasi-governmental agencies that dictate this as terms of doing business. – DTK Oct 02 '14 at 00:35
  • 1
    I'm sorry that some organisations have senior managers who don't understand what they're ruling on. But whether you install a single certificate, or an entire CA, from an external agency, the number of machines that must be touched, and the frequency of the touch, are the same: but whilst they both solve this issue, the security implications of the latter are **vastly** more problematic than those of the former. I'm with EEAA, here. – MadHatter Oct 02 '14 at 08:13
  • @MadHatter I think you misunderstand, there are some cases where in order to do business, one must play by another entity's rules. To do work with or for the DoD (esp. by way of DISA) all nodes need to trust "US DoD CCEB Interoperability Root CA 1" (and I think there is a new SHA-256 root coming). To be a bank, one needs to interoperate with the FRB, which means you must trust the Fed's root on your boundary device (& possibly devices further into your network). As a member of IT or INFOSEC personnel, you cannot just tell your company "close up shop, we won't work with the 800# gorilla" – DTK Oct 04 '14 at 15:05
  • Leaving aside most of what you say (I disagree with a lot of it, but this is neither the time nor the place), you're justifying your decision to behave like an 800lb gorilla by noting that other 800lb gorillas do it. Have you weighed yourself recently? It may be that my organisation decides to accept installing a governmental CA root as a pre-requisite to doing business with the government, but **you're not the government**, and people may well not take foolish things from you that they would take from other organisations. Best to ask them to do something sensible, if you have the choice. – MadHatter Oct 04 '14 at 18:01
1

Besides using SSL to access websites, you can use 802.1x to provide encrypted communications on your LAN in general. Doing this is a little more complex than can be explained in one post, but it generally involves setting up a host authentication method on the LAN.

The typical use case for this particular technology is enforcing that only IT-sanctioned hosts can be connected to the network, but it has the additional (strong) advantage that everything on the wire is encrypted.

Here is a resource that gives a serviceable explanation: http://services.geant.net/cbp/Knowledge_Base/Security/Documents/gn3-na3-ufs_133.pdf

Be aware that this is usually a major project. If all you want to do is encrypt communication with and provide for the authentication of your particular internal webapp, just use TLS (with a certificate signed from a public root, if you want and you are using a publicly delegated domain that you control internally, or with your own local PKI if not).

Falcon Momot
  • 25,244
  • 15
  • 63
  • 92