24

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?

8
  • 4
    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 at 15:23
  • 9
    Does this answer your question? What's the difference between end-to-end and regular TLS encryption? Feb 24 at 15:41
  • 1
    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. Feb 24 at 15:52
  • 1
    @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. Feb 24 at 16:02
  • 1
    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 at 10:14

7 Answers 7

32

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.

11
  • 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? Feb 25 at 5: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 at 8:28
  • 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. Feb 25 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 at 16:07
  • 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 at 16:07
42

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

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.

6

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.

enter image description here

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

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

7
  • 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 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 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 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 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 at 17:04
2

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.

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.

6
  • 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 at 14:51
  • @schroeder Thanks for the feedback. Would you mind pointing out which concepts I have redefined? Feb 25 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 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. Feb 25 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 at 16:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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