Is encryption in transit distinct from end-to-end encryption?

Question

I asked a question about HTTPS encryption as it relates to developing a web app here. On the face of it that question has now been closed twice for not being focused enough, but if the meta discussion is anything to go by, it's more realistically because of my wrong assumptions about the topic. An exchange in the comments with another user revealed this:

There is no such thing as "just encrypted in transit", that's simply a confusion from you. You are confused about how HTTPs works, which is the reason for this question and its many misconceptions. Good luck in the future :)

This goes against what I've always assumed, so I did some further research and it seems that at least some people consider HTTPS to be encryption in transit, and consider encryption in transit to be distinct from end-to-end encryption.

So which is true? Is encryption in transit a completely different concept to end-to-end encryption, or are they the same thing?

In the context of TLS (including TLS used with HTTPS) between a client and a server, the request is encrypted at the client, and decrypted at the server. So, the request is encrypted *in transit* between the client and the server, and it is encrypted from *end-to-end* being that the client is one endpoint, and the server is the other endpoint. The same happens in reverse when the server sends the response back to the client. However, the plaintext is readable at both endpoints being that encryption and decyption take place at these endpoints. — mti2935, Feb 24 '22 at 15:23
Does this answer your question? [What's the difference between end-to-end and regular TLS encryption?](https://security.stackexchange.com/questions/157292/whats-the-difference-between-end-to-end-and-regular-tls-encryption) — multithr3at3d, Feb 24 '22 at 15:41
@multithr3at3d I'm more asking about "end-to-end" vs "encryption in transit" as concepts rather than anything specifically to do with HTTPS. — Hashim Aziz, Feb 24 '22 at 15:49
The linked answer is not specific to HTTPS or certain protocols either. In general, if the data is not encrypted at all times before reaching the recipient, it is not end-to-end encrypted. — multithr3at3d, Feb 24 '22 at 15:52
@multithr3at3d The linked question doesn't even mention encryption in transit and neither did your answer to it up until your edit 10 mins ago. Considering that I'm asking specifically about what encryption in transit is and how that differs from E2E it seems like a different question to me. — Hashim Aziz, Feb 24 '22 at 16:02
Consider a single wire (i.e. no routers/switches in between) where you have A connected to B. If A sends an encrypted message to B this is encryption in transit. If Even is able to tap into the wire she won't be able to read the messages, that's why we use encryption-in-transit. Now Say A and B communicate via a server S. A sends an (encrypted) message M to S, and S sends M to B. End-to-end encryption here means that `S` is not able to decrypt `M`. The term end-to-end only makes sense when you have a middleman between the two endpoints. — GACy20, Feb 25 '22 at 10:14
For the context in which the initial question and comments were made, it is very important that the communication asked about was *directly* between the client and server. The misconception was which parts are covered by transit / ends and that both *practically* amount to the same thing *in that situation*, not whether in-transit and end-to-end are different things in general. — MisterMiyagi, Feb 25 '22 at 14:26
IMO, this is a poor choice of terminology – I'd expect "encryption in transit" to be used in contrast with "encryption at rest", while "end-to-end" would normally be used with "hop-by-hop" instead. — user1686, Feb 25 '22 at 15:38

score 42 · Answer 1 · answered Feb 24 '22 at 19:18

To visualize A. Hersean's answer:

       End-to-End     In-Transit
      ┌───┐        │       ┌───┐
Client│   │ hello  │ Client│   │ hello
      └─┬─┘        │       └─▲─┘
        │   uryyb  │         │   uryyb
      ┌─▼─┐        │       ┌─▼─┐
Server│   │ uryyb  │ Server│   │ hello
      └─┬─┘        │       └───┘
        │   uryyb  │
      ┌─▼─┐        ├────────────────────
Client│   │ hello  │
      └───┘        │       ┌───┐
                   │ Client│   │ hello
                   │       └─┬─┘
                   │         │   uryyb
                   │       ┌─▼─┐
                   │ Server│   │ hello
                   │       └─┬─┘
                   │         │   uryyb
                   │ Client┌─▼─┐
                   │       │   │ hello
                   │       └───┘
                   │

A. Hersean · Accepted Answer · 2022-02-28T08:19:43.083

34

Some definitions:

Encryption in transit means that data is encrypted while transiting from one point to another. Typically between one client and one server.
End-to-end encryption means that data is encrypted while in transit from its original sender and the intended final recipient. Typically between one client to another client, the routing servers only see the encrypted data without being able to decrypt it.
Encryption at rest is when data is stored encrypted. Depending on the context, this can be on the client, the server, both of them or only one of them.

HTTPS (and TLS) only provide encryption in transit. It is not suited for end-to-end encryption. A second layer of encryption on top of HTTPS is usually used to provide end-to-end encryption.

edited Feb 28 '22 at 08:19

answered Feb 24 '22 at 15:45

A. Hersean

10,046
3
28
42

5

As I understand, based on @belkarx's diagram, "In-transit" encryption can be considered secure if the server is trusted to handle the decryption, but "End-to-end" encryption is the type that presumes the server could be attempting a Man in the Middle attack? – Alexander The 1st Feb 25 '22 at 05:16
4

@AlexanderThe1st Yes. Security always comes down to trust at some point. We always have to trust someone or something to do what it is supposed to do and only that, no less, no more. How much do you trust a server, its handlers, its backups, its software, the legal authorities who could get an access, its physical security against illegal access? Do you trust there's only one server seeing the decrypted content? So much trust you do not need with end-to-end encryption. – A. Hersean Feb 25 '22 at 08:28
What if there's no second client? When you connect to an e-commerce site, the client and server are the two ends, and HTTPS is end-to-end encryption. – Barmar Feb 25 '22 at 15:18
1

My thought was that 'encryption in transit' means that there is a server in the middle between two communicating parties that decrypts the information. Think of a chat app where you encrypt the data, the server decrypts it and re-encrypts it to send to other participants in the chat. When you are actually communicating *with* a server as in a request for a web page, the server *is* the final recipient for your message and I would consider that end-to-end encryption. – Jason Goemaat Feb 25 '22 at 16:02
4

@JasonGoemaat If I'm sending a message to another user (or multiple users), that user is the final recipient. The server is just a proxy. This is where the difference between in transit and end-to-end matters. – jaxad0127 Feb 25 '22 at 16:07
Also note that, the end points in the TLS doesn't necessarily one entity, on the other hand end-to-end is designed for one entity, – kelalaka Feb 25 '22 at 17:11
Encryption At Rest does not necessarily mean End To End. The former simply means that the server _stores_ the data encrypted when it's not in use by the server. In these sorts of cases, it's only kept safe and private if someone steals the hard drives. Whoever owns the server **still** has full access. – RDragonrydr Feb 25 '22 at 19:31
1

@Barmar In general when you connect to an e-commerce site you connect to a third-party CDN that has their private key and forwards traffic to their actual servers. That’s not end-to-end. HTTPS _can_ be end-to-end but often isn’t, and the user has no easy way to tell. – Mike Scott Feb 26 '22 at 16:07
In order to be effective E2E encryption, the data should be encrypted at rest on the destination device as well, otherwise another application may easily read that decrypted data, if it is stored in persistent memory. – ryanwebjackson Feb 26 '22 at 20:04
@ryanwebjackson That might be ideal, but in many cases it's not practical. Data often needs to be searchable, and it's not generally possible to search encrypted data. – Barmar Feb 26 '22 at 23:28
Not to muddy up the comments, but I would argue that if that's necessary it can be unencrypted at that point in time. Some applications do work this way, so there is precedent for it. Nosajimiki also references this concept in their answer. – ryanwebjackson Feb 27 '22 at 20:10

hft · Answer 3 · 2022-02-25T17:56:08.747

Is encryption in transit distinct from end-to-end encryption?

This is like asking: "Is a vehicle distinct from a car?"

The word "is" can function as a copula, and does not necessarily mean two things are equal.

A car is a vehicle. This means a car is a type of a vehicle. It does not mean that a car equals a vehicle.

End-to-end encryption is a type of in-transit encryption.

So which is true? Is encryption in transit a completely different concept to end-to-end encryption, or are they the same thing?

Neither are they the same thing, not are they completely different. See the above discussion of the word "is."

The other answers have already explained how end-to-end encryption is differentiated from other types of in-transit encryption.

In particular, client-to-server encryption is usually not called "end-to-end encryption." The term "end-to-end encryption" is usually reserved for encryption from one client all the way to the another client, where the server in between does not see the decrypted traffic.

Nosajimiki · Answer 4 · 2022-02-25T20:37:34.453

Depends a bit on what industry you work in.

In-Transit means that the data is encrypted from the time it leaves one device and arrives at another, but end-to-end is a bit harder to nail down.

By some definitions End-to-End means that the data is encrypted from the time it leaves a starting device and when it arrives at another. Or it could mean it is encrypted when it leaves one application and arrives at another. Or it could means it is encrypted from the point it is sent by one client up until it is received back by that or another client having at no point been decrypted in its handling by any servers in between.

Since, the exact meaning of end-to-end encryption has evolved quite a lot over the years, not all experts agree on where this line lies, espceially with all the different use cases that could apply. There are a ton of different systems out there which some security experts claim are E2EE that other security experts claim are not. So, while your favorite recreational app may claim E2EE, it does not mean it would pass the same E2EE standards expected of a HIPPA or PCI compliant system.

* In some setups, part of a network may act as a proxy that decrypts and processes traffic before forwarding it to its final destination. In these cases it is common to re-encrypt the data before relaying it on to where it is going, but this still creates a point of vulnerability where that proxy exists.

** By loser definitions of E2EE, once the data arrives at your device you are done, mission accomplished. However, by more strict standards of E2EE, your end-point is considered the application and not the device. In strict E2EE the data must only be decrypted in the application's isolated memory (enclave) to prevent certain kinds of malware from sniffing/tampering with it locally. Once the data is in your application's isolated memory, it becomes safer to decrypt than doing it in one application, and trying to pass it to another because malware on your device can still perform a MiM attack on data being transferred between two applications.

*** In some cases, (particularly where a server is considered the end-point) the data is not and can not be decrypted at all, but simply stores it in its original encrypted or hashed state. Though some might argue that this is just a long term mid-point as opposed to a true end point, so again, semantics and use cases are not always going to be the same.

So, as you can see, there is some over lap where the two could be one in the same, but in most cases, End-to-End takes extra steps to ensure persistent encryption in your communications that In-Transit Encryption does not.

Barmar · Answer 5 · 2022-02-25T17:24:56.663

2

It depends on what the "ends" are in the application.

If you're using a peer-to-peer application (e.g. messaging or email) that makes use of an intermediate server, TLS can be used between each client and the server; this is encryption in transit. It's also possible for the application to encrypt and decrypt the message itself, with the server just passing this through transparently; this is end-to-end encryption.

But there are also many applications that are just client-server. For instance, when you use an online banking application, one end is your phone or browser, the other end is the bank's web server. In this case, you use TLS to encrypt this connection, and it's both in-transit and end-to-end encryption.

Often what's considered an "end" is a matter of abstraction levels and perspective. For example, from the perspective of the banking customer, the web site is an end by itself. But it's often the case that a complex web site is implemened using numerous devices: webserver, database servers, load balancers, etc. The TLS connection may terminate at the load balancer, or it may pass it through to the webserver. There will also be independent communication between the webserver and the database server.

edited Feb 25 '22 at 17:24

answered Feb 25 '22 at 15:26

Barmar

584
3
9

Your bank app example only holds if there are a lot of other controls to enforce the end-to-end nature of the encryption. You can't make that a blanket statement simply because TLS is in use. – schroeder Feb 25 '22 at 16:42
1

I'm not sure what you mean. When you go to an HTTPS URL, the browser and server use TLS automatically, and that encrypts the communication. – Barmar Feb 25 '22 at 16:47
But that's not E2E encryption. You can't claim that TLS is E2E by itself. See all my comments on the answer below. – schroeder Feb 25 '22 at 16:50
2

I'm treating all the equipment at the service provider end as a black box. So if there's a load balancer, that's conceptually part of the "server". – Barmar Feb 25 '22 at 16:57
1

... so the LB is the "end"? There's simply no need to redefine and extend the term like this. It's not accurate and it only confuses the issues. TLS is not E2EE. – schroeder Feb 25 '22 at 17:04
I consider this just an "implementation detail", not much different from the type of database that's used. You have to pick your level of abstraction. – Barmar Feb 25 '22 at 17:08
I've updated the answer to explain this concept somewhat. – Barmar Feb 25 '22 at 17:25

score 2 · Answer 6 · answered Feb 26 '22 at 00:39

I’m going to answer this simply: the terms imply different use cases.

End to end implies personal devices at each end.

In transit implies just the opposite, that there is at most 1 personal device involved.

But note that these are implications, not definitive statements about the terms, someone may describe a user to user connection as in transit or a user to server as end to end.

MisterMiyagi · Answer 7 · 2022-02-25T15:03:21.020

1

Both in-transit and end-to-end describe different concepts which are thus obviously not identical. Encryption in-transit is between the "nodes" of communication, whereas encrypting end-to-end is over the entire range of communication.

 |--transit-|  |-transit--|

Client <-> Server <-> Client

 |----- end-to-end ------|

However, there is an overlap if the transit happens to be directly between the ends of communication.

This is the case when the ends of communication are the client and server of an HTTPS connection, for example because the two exchange data via POST. In this case, the transit between server and client and the ends of server and client describe the exact same range.

 |--transit-|

Client <-> Server

 |end-to-end|

Being aware of this edge case is important because it means trying to gain better security in such a case by "switching" from in-transit to end-to-end encryption is a red herring.

edited Feb 25 '22 at 15:03

answered Feb 25 '22 at 14:43

MisterMiyagi

119
4

1

You've made a logic error that involves redefining the concepts to create a false equivalence. You then create a technical recommendation that does not survive scrutiny. – schroeder Feb 25 '22 at 14:51
@schroeder Thanks for the feedback. Would you mind pointing out which concepts I have redefined? – MisterMiyagi Feb 25 '22 at 14:52
Yes. if you can control ***both*** the client and the server, ***and*** can control all aspects of the encrypted communication channel, then you have an equivalence to E2E encryption *in that context*. But that is not the typical context and you can't expand that to a general recommendation. I offer CDNs, load balancers, and TLS terminators on the server side, and TLS inspection on the client side. These break your 'in-transit' model where they do not break E2E models. – schroeder Feb 25 '22 at 14:55
@schroeder I was under the impression that I made it clear the equivalence holds *only* in that context. I'm open for suggestions on how I can make it more clear if need be, but I have to disagree that I am making a general recommendation. – MisterMiyagi Feb 25 '22 at 14:58
"Being aware of this edge case is important because " -- if this edge case is so contrived, then, no, it is not important at all. You need to assess your needs despite the *incidental* network context. If you need E2E, don't go guessing that you have a direct connection and that it will always be a direct connection. So, your advice is generalised and based on a specific context that doesn't change. – schroeder Feb 25 '22 at 16:39
@schroeder That "contrived" edge case is exactly [where OP is at](https://stackoverflow.com/questions/71228164): A) They have client <-> server covered by HTTPS. B) They have found assertions that E2EE is "better" than in-transit. C) Therefore, they assume E2EE *between client and server* will give them more range than the in-transit range they already have, and thus push *past the client* that is one end of E2EE to remove information they have given to the user. Preventing misunderstanding of generalised advice is *exactly* why this answer focuses on that case. – MisterMiyagi Feb 25 '22 at 18:12

Is encryption in transit distinct from end-to-end encryption?

7 Answers7

Depends a bit on what industry you work in.

Linked