We have a on-premise web application with frontend (Node/Express) and backend (Python/Flask), which, like every other web application I've ever worked on, provided HTTPS by using a proxy web server (in this case, Nginx) to handle the secure connection and port forwarding to the actual frontend and backend servers, which are otherwise protected from the outside by a firewall. However, a client to whom we are delivering the app insists on "end-to-end encryption", meaning that each individual server application must handle secure connections directly (never mind that is completely different from what "end-to-end encryption" usually means, though it's a bit of a red flag that they may not know what they're talking about). This means each component (frontend server, backend servers) need to be modified to use TLS certificates (in this case, self-signed), as well as connecting with HTTPS to the other components - and, if necessary, preventing errors due to the self-signed nature of the certs.

None of this was discussed in the initial terms of the project, it's only come up now that we've started delivery. I've never heard of doing things this way, it seems a bit absurd, but I don't know whether it's a thing people do and it's just new to me, or their IS rep doesn't really understand their own policy, at least as it relates to products like ours. Is there an easy solution to this I'm missing, do we just have to bite the bullet and make a bunch of code changes to support this (or lose the client), or is there just a misunderstanding and we should push back on the requirements more?

  • Have they really insisted that you can not have ssl termination on a proxy? Do they even know what that is? Can't you just argue that the proxy is a part of the application, therefore it is "end-to-end"? Mar 25, 2022 at 8:12
  • Are you sure that's what end-to-end encryption means? Often it means in a web application that intermediates between users, the web application can't decrypt the data
    – user253751
    Mar 25, 2022 at 10:41
  • Since all servers seem to be running on the same host, it might be possible to connect them via Unix sockets that you bind-mount into all containers instead of using a virtual TCP/IP network.
    – amon
    Mar 25, 2022 at 12:08
  • @RobertBräutigam Yes, apparently yes, and no - that was the first thing we tried.
    – Evan
    Mar 25, 2022 at 12:46
  • @user253751 Yes, the application doesn't have any peer-to-peer functionality so the usual definition of E2EE doesn't even apply.
    – Evan
    Mar 25, 2022 at 12:47

2 Answers 2


The only "good" solution I can see is more communication.

At a client we were able to avert a similar situation by escalation. At some point we were able to speak to the (technical) guy who was responsible for those rules (did not came up with them, but was the "responsible" person). It turns out he actually knew why those rules were in place and was therefore much more flexible for our use-case.

It is no guarantee though. At another client I made the mistake of calling a device specific key in a solution a "certificate". That triggered all sorts of rules. Such as the need to regularly renew them. Even though these were not used for encryption nor signatures. I could not talk my way out of that one unfortunately.

Anyway. My point is more discussion. Try to get around the representative who understandably has no idea about tech, and actually have someone responsible in the meeting. Someone from "security". You know, the people with anti-shoulder-surfing monitor filters and yubikeys around their neck or whatever. :)


I've never heard of doing things this way

In that case, your experience is honestly a bit limited. When I've worked for enterprise companies, they've more often than not had an "SSL everywhere" policy. It really shouldn't be very much work for a competent devops team, and it protects against the threat of internal attackers who have access to the network but not the applications so is a reasonable threat to protect against.

The SMEs I've worked with/for were a bit more varied on this, but with the advent of Lets Encrypt in the past few years, I'd say they've pretty much all moved in that direction as well.

  • 1
    Everything runs inside a virtual network via docker-compose with only the Nginx ports exposed, so the other applications aren't available except from the same host machine (and then only with docker/root permissions). Adding HTTPS to this won't change anything, as a user with sufficient access to sniff the network could easily enough change the application code to exfiltrate data anyway.
    – Evan
    Mar 25, 2022 at 8:03
  • Letsencrypt does not (and refuse to) help with servers running in the local network (such as the app server sitting behind the web server)
    – slebetman
    Mar 25, 2022 at 20:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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