Achieving End to End encryption with TLS

Question

The scenario is that a client browser (eg: a user trying to log in to a bank website) needs to be able to view certain sensitive information that resides in a mainframe sitting in the Internal network via a web/application server that resides in the DMZ (The client should not be able to directly connect to the mainframe).

In a simple setting, there will be two TLS sessions i.e. one between the client and the web server & the second would be between the webserver and the mainframe. The problem with this setting is that the sensitive information is getting decrypted and encrypted again at the webserver. So there will be a point in time when the sensitive information is in the clear on the web server.

How can I mitigate this such that the information remains confidential at the web server but can be decrypted successfully at the client's end? How can I achieve this end-to-end encryption?

Answer 1

Unfortunately you'll find that this just isn't done. As you have correctly pointed out, you do not allow the client to connect all the way through using one TLS channel, so decryption at the web server, or TLS endpoint, is a given.

So what organisations do is assess the risk and then look at other security controls over the web server. These include:

• Physical isolation
• Logical segregation
• Separated management connections
• Strong authentication
• Monitoring of admin access
• Server hardening
• etc

(There is a possible partial solution, which would be to run the webserver with encrypted RAM, encrypted disks and so on, however this leads to a serious performance impact, and still does not protect against an attacker who has gained access to the webserver.)

Answer 2

If you want a truly end to end solution for customers accessing their personal info (which resides on a mainframe in the bank's LAN) from a web service (hosted in their DMZ) you'll have to create a browser plugin for your customers.

This will require them to spend an extra minute (as a first time user) to download & install your plugin ... but they won't need administrative privileges on their computer to do so.

You'll still use 2 separate TLS sessions but they'll wrap around an end-to-end solution that will encrypt the user's data on the mainframe and decrypt that data on their client (using the plugin). You can use PGP (I prefer NaCl asynchronous crypto) as the basis for your mainframe to plugin encryption system.

edit: As an alternative, you can send your customer a device (like the ebay egg) or have them download a mobile app (like google auth) which can provide them with a time based password (the usable password is expired/replaced regularly, usually a matter of seconds, allowing a short PIN [~ 8 digits] to be secure). When your customer requests sensitive information, the mainframe will send them an encrypted ZIP file which was secured before leaving the mainframe. They would then use the current PIN provided by their authenticator device/app as a password to decrypt the data.

An even lower tech option (compared to an authenticator device/app) is to allow the customer to pick up a list of one time use PINs which they can check off as they exhaust them. You can require the customer to pick up these lists at their local branch or you can mail them to the customer. This is a form of 2 factor authentication as the customer will still have to use their password to access their online banking.

Answer 3

Basically, if I understand your need, all you want is to forward the mainframe SSL listening port so it listens on a host in the DMZ. This could be done using any NAT solution.

Answer 4

Here is an architecture that could work:

• Generate an asymmetric encryption keypair. The private key will be known only to a program running on your mainframe that is the final endpoint that retrieves the data.
  • On the web site, use a client-side JavaScript-based encryption library that can generate a symmetric encryption key of adequate strength, like AES 256.
  • The website would make the asymmetric public key available in script. Using another Javascript library to match the mainframe program's asymmetric encryption scheme, encrypt the symmetric key, before sending back to the web server. Do this over SSL for good measure of course to protect the transport.
  • The web server makes a request to the mainframe program asking for the data, and passes the asymmetrically-encrypted encryption key that the web browser generated.
  • The mainframe program uses it's private key to decrypt the symmetric key. Then it uses the symmetric key to encrypt whatever sensitive data it is retrieving, and returns this to the website, which sends it back to the client's web browser.
  • The client's web browser decrypts the payload.

This is your base model. Depending on the nature of the data, the uniqueness of requests, etc., you will probably want to spice things up further, such as by salting the symmetrically-encrypted data, determining how often to change encryption keys, etc. And to be accurate this is not 100% end to end, as we don't know the nature of your mainframe program, or if your data is encrypted at rest in the data store, but I think this gets you pretty close to your requirements, as the web server or any other hops in the middle will not be able to read the sensitive data.

There are various libraries out there implementing encryption algorithms in JavaScript for doing AES and asymmetric algos like RSA.

This architecture should cause no extra headache for your users like you might see with a solution based on client certificates or installing additional software on their machine.