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?

Answer 1

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.

Answer 2

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
                   │       └───┘
                   │

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.