1

//update 1 - there came some good replies (sadly mostly as comments instead of direct answers) - look further down for additional edit

I know this is a hot topic for the past few years, and although I would say I know quite some stuff about transport encryption (from the client to the server) I didn't yet got what's all about this "end-to-end" stuff. From as far as I could dig up information it's about securing the communication channel between the communication endpoints - maybe over several other connections - and maybe not in real time. Although TLS and S/MIME are topics I'm well familiar with I couldn't get my head around end-to-end.

So, please correct me if I'm wrong - I don't fully understand it yet:

"end - to - end" means securing the channel between two communication end points - this means if I have Alice and Bob (as often used in crypto) Alice and Bob are not necessary only linked by one connection like a client using TLS to connect to a server but maybe by several links like Alice connected to server A - which then is linked to server B to which Bob is connected (pretty much like IRC with multiple servers). In this case e2e means that Alice and Bob communicate over the IRC network without any of the servers being able to read the message unlike the case if Alice and Bob would only use transport encryption from their clients to the server but not e2e.

Ok, so when I stick to IRC: When both are online at the same time they could just do a TLS handshake over IRC (and spam others with their encrypted messages) - and although this shouldn't be possible by other security protections - how could Alice prove to Bob she's the real Alice and how could Bob prove to Alice he's the real Bob (prevent MITM)? Some rogue entity sitting between them at any point could just do a simple MITM. I read about this Alice and Bob sharing fingerprints out of band (so, in the IRC example: maybe by e-mail - if both know the correct e-mail-address of the other). Or maybe meeting in person and exchange fingerprints by scanning QR codes on their phones. But how to do it without out-of-band (if possible at all)?

And how about when both are offline? How would they establish a handshake to share a common secret (and some authentication data to prove the messages)? I'm lost about this topic and although tried to search for information I couldn't find any specific example showing how it's done (in any way - couldn't find any about doing it securely). Any help appreciated.

//edit 1: So, over time I got a better understanding about end-to-end and possible ways to implement it. First of all I learned that E2E is more of a concept rather than some specific protocol or such. Guess that's an important lesson to learn about that topic instead of just TLS wich is a clear defined protocol with known implementations. Next I learned that one has to think a bit out of band when it comes to verify that the one who I want to exchange messages with really is the one and not someone else. If you can't meet in person (one of the main verifications in weboftrust and pgp/gnupg) one (or both) can share their keys (and/or fingerprints) over several ways like random mailing lists, random comments on random blogs. An attacker would need to either controll all of them (unlikely) or successfully MITM the connection of at least one of the participants and by this break TLS' countermeasures to prevent exactly that. A possibility I didn't thought of before as it seems I was (and maybe still am) a bit to single-minded towards "I want some trusted instance like a CA" - if I want to get deeper into e2e I have to let lose that one.

6
  • 1
    Does this answer your question? What's the difference between end-to-end and regular TLS encryption? – multithr3at3d Apr 19 '20 at 13:12
  • @multithr3at3d: I suppose you didn't understand the question. – mentallurg Apr 19 '20 at 13:34
  • @mentallurg I guess there are multiple questions in there – multithr3at3d Apr 19 '20 at 14:10
  • @multithr3at3d: If you see here multiple questions, why do you want to close this question a a duplicate of a single question? You contradict to yourself. – mentallurg Apr 19 '20 at 14:18
  • 1
    Don't heat up on each other, but to reply to @multithr3at3d yea, it at least is some good input. I can't say if it answers MY question(s), as I may unsure what I'm really looking for, but the linked topic at least made it clear to me that "end-to-end encryption" is more like a concept rather than some specific protocol or implementation or such. – cryptearth Apr 20 '20 at 0:36
2

We call communication e2e encrypted if one side encrypts the message and it remains encrypted on the whole way to the other side, so that only the other side can decrypt it.

Fir instance, Alice encrypts an Email, so that only Bob can decrypt it. Bob sends messages ecncrypting them so that only Alice can decrypt it. The email can be relayed via multiple servers and the whole time remains encrypted. The can use pre-shared key and symmetric encryption, or one time pad (it can be hard to implement in real life, but still it is a valid option), or - much more often - they can use PKI, for instance they both can obtain S/MIME certificates issued by some trusted Certification Authority and use public key of each other to encrypt messages. The same is applicable for messengers.

You are asking about offline. It does not matter, if one side is online or offline. When Alice is encrypting a message to Bob, Bob doesn't have to be online. In case they use PKI she has to know the public key of Bob. Alice uses his public key to encrypt a message to Bob and sends it to him. When Bob comes online, he receives the message and decrypts it.

To handshake: We speak about handshake in case of TLS. Here is direct connection between both sides is needed. That's why TLS is normally use only when at leas one of both sides has a fixed IP or fixed domain name. When two people communicate (e.g. via messenger) they are in most cases in the networks of their internet providers and have neither fixed IP nor fixed domain name. Means, Alice does not know how she can reach Bob to establish a connection with him. And Bob doesn't know how he can reach Alice. In such case they just cannot establish a TLS connection to each other. They can do that only if they are in the same network which happens rarely.

In many messengers users establish connection with the server, because the server has a fixed domain name and at any time it is known how to reach the server. Alice and Bob both establish connection to server, and the server forwards messages from Alice to Bob and vice versa. One handshake happens between Alice and server, the other one between Bob and server, but no handshake between Alice and Bob.

If Alice and Bob use their public keys to encrypt messages to each other, then the server cannot decrypt them. But many messengers don't support that and only have encryption between ALice and server and between Bob and server. Server obtains an encrypted message from Alice, decrypts it into plain form, encrypts it for Bob and sends it. This is of course not e2e encryption.

6
  • Well, as I know S/MIME rather well (and hence reject it said to be failed (e-fail) - as e-fail is an issue of the MUA implementation (more specific that it's possible to extract data by surrounding an encrypted block with two non-encrypted), not of S/MIME itself) how about messengers without a PKI? If I want to use some messenger (no matter wich) how does it establish a secure connection between me and the other user if we both not online at the same time and the service doesn't use a PKI to generate keys and certificates for each of us? – cryptearth Apr 19 '20 at 12:31
  • @cryptearth: To messengers: Since the most of the messengers are not open source, I cannot say if any of them really implements e2e encryption. We can rather say when they don't use e2e. – mentallurg Apr 19 '20 at 13:26
  • 1
    @cryptearth: E.g. WhatsApp has a possibility to share key, e.g. by generating QR code on one phone and scanning it on another one. But we don't know how this code is used, and if it used at all. They say the use a new encryption key for each message. How do they share this key? It is not clear. If the is shared using WhatsApp App and Server, then it cannot be trusted and thus any messages encrypted with such key can be decrypted. Means, despite the message is really encrypted on the way from user A to user B, WhatsApp server has possibility to decrypt it. Thus, this is not e2e encryption. – mentallurg Apr 19 '20 at 13:29
  • Nice input - you may have an idea how sharing a key between to parties could be established/shared if they don't have a chance to meet in person to scan each others QR? What I try to ask is when not using a PKI wich at least somewhat gives some proof of identity (or at least which it should and hence how S/MIME works) when there're lets say only maybe two key pairs without any 3rd instance guarantee the identity of some entity by a certificate? Only use two key pairs can be intercepted by MITM - how to mitigate that if possible? – cryptearth Apr 20 '20 at 0:42
  • 1
    @cryptearth: Yes, it is possible also without CA. Both users generate key pairs then send public keys (pure or better as self-signed certificate) to each other. To verify that they were not replaced by the man in the middle they calculate fingerprints of their public keys and verify fingerprints using some channel that they trust. For instance, spell fingerprint via phone (not everyone may like it, but still a valid channel), send it per SMS or per Email that you trust. They don't need to keep fingerprint secret. They only should be sure that the fingerprint will not be modified on the way. – mentallurg Apr 20 '20 at 5:16
1

TLS has mechanisms to protect against MITM. In particular for your question, it provides sender authentication and integrity protection at the transport layer. So, it is providing a secure e2e transport channel. Now if applications are riding on top of TLS, say IRC for example, and you want e2e including the application layer as well, then the application itself needs to provide the necessary protections.

For offline cases, then application layer messages would be stored somewhere in transit (it depends on the application), possibly in a server in the middle or at the source or destination, until connectivity is restored. In such cases, they would need to remain encrypted and not decrypted for such storage, in order to not break the end-to-end principle.

5
  • TLS does not mean e2e encryption. It can be e2e, it can be also not e2e. Very often TLS termination point is not the application itself, and traffic between TLS termination point and application is often not encrypted. Not matter how low or high the risks are, such cases are not e2e encryption. – mentallurg Apr 19 '20 at 2:22
  • 1
    That's why I was differentiating between using TLS for an e2e transport channel vs e2e between the application at the two ends. See en.wikipedia.org/wiki/End-to-end_principle where it talks about end-to-end (with respect to the transport layer) between two endpoints. – auspicious99 Apr 19 '20 at 2:54
  • Normally it is impossible to establish a TLS connection between two people. It is possible in rare cases only, e.g. if both are in the same network and know IPs of each other. That's why when we speak about TLS we usually mean that at least one of both sides has fixed IP or domain name, which usually means that at least one side is a server, not a person. And in case of server there is usually separation between TLS termination port and the application that actually communicates, meaning there is a leg that is not encrypted. – mentallurg Apr 19 '20 at 3:10
  • 1
    I'm not disputing that. I'm just trying to differentiate between two valid concepts: end-to-end from application to application, versus end-to-end between two underlying TLS endpoints. As the OP had mentioned about TLS, it adds value to clarify the limitations of what TLS can provide as far as end-to-end. See en.wikipedia.org/wiki/End-to-end_principle and "End-to-end acknowledgment and retransmission is the responsibility of the connection-oriented Transmission Control Protocol (TCP) which sits on top of IP" -> one could talk about end-to-end even from TCP endpoint to TCP endpoint. – auspicious99 Apr 19 '20 at 3:17
  • Nah, your assumptions about TLS are not that quite easy and hence have some issues: Sure, in TLS one part is considered a server and the other a client, but that doesn't mean that it can't be used to establish e2e over a multi-hop connection - it's just a bit more complicated and requires more message round trips. TLS is not just transparent for TCP connections, but can be layered inside such. Also, my question isn't much about TLS or S/MIME but rather cases like messengers wich don't use PKI or have direct client-to-client connections. Btw: You spend too much time as a human spell checker. – cryptearth Apr 19 '20 at 12:35

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.