Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
1) I am aware of this option but obtaining the recipient's public key is unfeasible as there can be potentially millions of them. 2) I know its tricky to achieve forward secrecy in this case.. Hence the reason for me posting this question here! –  Balthazar2012 Nov 13 '13 at 10:33
The web server authenticates itself via certificate & the client uses a password based authentication mechanism. (E.g.Logging on to a bank's website) –  Balthazar2012 Nov 13 '13 at 10:41
Oh I misunderstood your question. I thought the recipient is a user as well. –  CodesInChaos Nov 13 '13 at 10:42
Apologies for being unclear.. I shall update the question.. –  Balthazar2012 Nov 13 '13 at 10:45
Your question is clear, I just didn't read carefully. I'm just too much into the secure end-to-end message corner of security. –  CodesInChaos Nov 13 '13 at 10:47
show 1 more comment

migrated from crypto.stackexchange.com Nov 13 '13 at 10:24

This question came from our site for software developers, mathematicians and others interested in cryptography.

2 Answers

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.)

share|improve this answer
add comment

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.

share|improve this answer
This doesn't answer the question. The OP is not talking about passing through the direct connection from the client. He is terminating one connection at the web server, which then connects to the manframe. –  Rory Alsop Nov 13 '13 at 15:20
@RoryAlsop: Ok, I thought he precisely wanted to avoid this decryption ("The problem with this setting is that the sensitive information is getting decrypted and encrypted again at the webserver. "), and NATing would achieve this (ie. end-to-end encryption as mentioned in the question title without intermediate decryption). –  GZBK Nov 13 '13 at 16:41
In the OPs first para:(The client should not be able to directly connect to the mainframe) –  Rory Alsop Nov 13 '13 at 19:40
@RoryAlsop: What I missed in my answer is that, if I'm right now, part of the web application resides on the web server, and some information appearing on these pages come from the mainframe (maybe some fields for instance). In such way, I see indeed no way to mix information from two such sources into a single TLS tunnel. On the other hand, would the goal really be to set-up end-to-end encryption between the client and the mainframe, without any filtering of some sort, I still see this as NATing (it still adds TCP layer security compared to direct access). –  GZBK Nov 14 '13 at 16:19
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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