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!

3
  • 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... en.wikipedia.org/wiki/… Oct 2 '14 at 0: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 2 '14 at 0: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.
    – kitified
    Oct 4 '14 at 0:19
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.

4
  • 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 2 '14 at 0: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 2 '14 at 0: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 2 '14 at 0:30
  • I like this idea the best- thanks for your input. I never even considered having the client use their own certificate.
    – kitified
    Oct 4 '14 at 0: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.

7
  • SSL will be far-and-away the easiest solution.
    – DTK
    Oct 2 '14 at 0: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 2 '14 at 0: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 2 '14 at 0: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 2 '14 at 0: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 2 '14 at 8:13
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).

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.