As in title, I want to know that is TLS encryption end-to-end encryption when between sender and receiver there's no any middleman? E.g.: example cases

We are sure that TLS in case 2 doesn't provide end to end encryption because proxy can read sent data. But what with case 1?

  1. Theoretically, there's no any middleman (case 1) so is this end-to-end encryption?
  2. Also, can such a direct connection (case 1) be somehow decrypted by the attacker?
  3. Should I encrypt data at the application layer better for very sensitive data even if there's no any proxy and the like?
  • This question duplicates following: How is it possible to do TLS through proxy without anyone noticing?. Briefly: HTTP protocol defines a CONNECT method which wraps TLS. TLS "does not see" that. And if a proxy attempts to play man-in-the-middle, it will have to present a certificate, which is impossible, because such certificate will not be trusted by the client.
    – mentallurg
    Oct 30, 2022 at 20:05
  • Thank you for referring to another question, but it answers only for one piece of my question.
    – Szyszka947
    Oct 30, 2022 at 20:42
  • What exactly is not answered there?
    – mentallurg
    Oct 30, 2022 at 21:19
  • Referred question answers to security of data sent by proxy while end to end encryption isn't used but TLS is (in the context of my question). It answers to one of my question, but no related others (point 1 and 3).
    – Szyszka947
    Oct 30, 2022 at 21:59
  • The receiver of the traffic is usually located a few steps/layers behind the TLS termination point. The traffic from the TLS termination point to the receiver is not encrypted. That's why TLS does not provide ent-to-end encryption.
    – mentallurg
    Oct 30, 2022 at 22:07

2 Answers 2


So, first things first: the term "end to end encryption" refers to something that does not generally apply to TLS. End-to-end encryption would be if, for example, I encrypted this post such that only you could read it, and StackExchange could not. After all, the primary communication here isn't between me and the StackExchange server, it's between me and you (for arbitrary values of "you"); the server is merely relaying the communication, rather than acting as an endpoint. As such, even though StackExchange uses TLS for all its external traffic, no portion of it is end-to-end encrypted.

TLS encrypts (and provides other protections such as integrity - no bit flips or data reordering - and replay protection) traffic between two sockets, generally owned by processes running on different machines (e.g. your web browser and StackExchange's web server). It also allows the client (the party initiating the communication) to verify the identity ("authenticate") of the server... and optionally, for the server to authenticate the client as well (this is almost never used on the public web, though it can be; your browser supports it). All communication between those two hosts is opaque; all that a middleman can see is the amount of traffic flowing each way, where it's coming from and going to, and the timing of the transmissions.

And there are middlemen, even if there's no actual man-in-the-middle attacker. Your TLS traffic travels through a bunch of devices including your home router, your modem, your ISP's modem and gateway, the Internet backbone routers, the server's ISP gateway, the datacenter router, and then finally probably TLS gets terminated at a load balancer before your traffic is forwarded - possibly inside a new TLS session - to the actual web server host. Every single one of those modems, gateways, and routers could in theory read and modify your traffic... but TLS prevents them from doing so successfully. The only party who can do that is the one that the client considers to be the server, identified using a certificate and proven using a corresponding private key.

This is potentially true even if you use a proxy! A proxy might be configured to terminate TLS - in which case it needs to be able to convince your browser (or any other client) that it's actually the destination server - or it might just relay the TLS-encrypted traffic without any ability to peek at it. With that said, TLS-terminating proxies are used for lots of stuff; your employer might have one that monitors Internet use from within the company network, and servers might have one (sometimes called a "reverse proxy") to provide DDoS protection or other services (this is how Cloudflare works).

Hopefully this clears up your confusion. It's not about whether there is a middleman - there almost always will be, unless you're communicating over local machine loopback and not using the network - it's about whether the client (e.g. browser) considers any of those middlemen to be the destination (server). The connection between the client and what it considers to be the server (which might actually just be a proxy or load balancer or similar, if those have the server's certificate and private key) is opaque to everybody else. However, it's not generally considered end-to-end encryption, because the server usually isn't the final destination of that traffic.

To answer your last question about whether you should use application-layer encryption (which - technically speaking - TLS is, but I know what you mean), the answer is almost certainly "no", but it depends on your use case. There's no reason to worry about TLS itself being breached, respectfully, if you had to ask this question, there's no chance you will implement a protocol that can withstand anybody who figures out how to breach TLS. However, if you want end-to-end encryption where even the server can't read the traffic, that's where adding another encryption layer comes in. Consider apps like Signal or WhatsApp; they use TLS between the client and server, but the actual messages are end-to-end encrypted such that the server can't read them, only the final recipient(s). If you're making something like that, then maybe you want to also use something more than TLS. For all other purposes, don't bother; it won't add anything except wasted effort and headaches.

  • I don't know if you are interested in OIDC and FAPI, but if so then I have this question referring to your great answer: Assuming client uses PAR (and client is very sensitive app, e.g. bank), really shouldn't I worry about state and nonce sent in PAR request using TLS? If state and nonce leak it will greatly make easier (but still hard) to get access to some account. From what I understood, even for such a scenario, it is enough, for example, to sign a request, without additional encryption, right?
    – Szyszka947
    Oct 30, 2022 at 19:21

In the general case, TLS provides point-to-point encryption. If there's a proxy in between, the proxy just forwards the traffic (encrypted). So in both cases (1 and 2) the encryption is between the client and the server (assuming of course that there's a CA involved that provides the related guarantees, so a mitm attack is not feasible).

So, to answer your questions:

Theoretically, there's no any middleman (case 1) so is this end-to-end encryption?

Point-to-point; it's encrypted between the client and the server. The server decrypts the traffic and the application data may move on to a different system unencrypted (this is why it's not end-to-end secure)

Also, can such a direct connection (case 1) be somehow decrypted by the attacker?

To the extend that an attacker cannot break the encryption algorithms, no (assuming that the attacker has not compromised the client or the server)

Should I encrypt data at the application layer better for very sensitive data even if there's no any proxy and the like?

I wouldn't bother, TLS is fairly secure. However, if you think that an extra layer of security (application level encryption) won't cost you in the long run (en-/decryption costs CPU cycles and RAM) then there's nothing forbidding you from doing it.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .