Is end to end encryption over HTTP safe?

Question

If you wrap all your data in an end-to-end encrypted payload is it safe to transmit over HTTP or at worse case self signed HTTPS instead of traditional CA signed SSL?

Answer 1

In one sense yes; after all, TLS is itself end-to-end encryption (at the network level and only between two network peers, not necessarily two messaging peers, but intermediate network peers such as routers, etc. still can't read it) over insecure TCP.

On the other hand, likely no. TLS is a very complicated protocol that takes into account a lot of stuff that many other encrypted communication schemes fail at. Examples include server authentication (making sure you're using the public key of the peer you expect and not some imposter), optional client authentication (same, in the other direction), forward-secret key exchanges (optional; technically non-forward-secret exchanges are still available in TLSv1.2, but they're on the way out), cipher and protocol negotiation (not all peers support all primitives, or all modes of operation, etc.), detailed specification of handling things like padding and compression (to handle various attacks such as padding oracles and compression oracles) and IVs/nonces/key rotation (to avoid vulnerabilities due to things like overusing a single key for AES-GCM), message integrity (to avoid bit flipping attacks and similar), and replay protection. Not all of that will be relevant to all situations, but suffice it to say: getting this stuff right is hard. We're now on the sixth publicly released SSL/TLS standard version (SSL 1.0 was never released, being replaced with 2.0 before going live), and I expect TLSv1.3 will not be the last.

There exist some systems that can achieve comparable levels of security. OpenPGP is a standard for end-to-end encrypted messages (typically emails and their many parts, possibly including attachments, but it can be any kind of data) that has different conventions for authentication of public keys and isn't forward-secret (among other differences, mostly related to being asynchronous rather than synchronous) but can offer similar levels of security otherwise. Signal aims for very similar levels of security, but also has its own methods of key authentication.

What does your system look like? How do you authenticate the recipient and sender, in a way that doesn't risk exposing your key exchange to an attacker? Or do you use pre-shared keys, in which case how trustworthy is their storage and do you have a way to distinguish one node from another? Does it take into account the myriad risks of cryptographic systems in general (which hybrid cryptosystems - as nearly all that use public keys are - have the worst of)? If it's good enough - a question that is difficult even for an expert to answer, and probably totally impossible for a cryptographic layman - then sure, send your E2E-secured message over whatever transport you like. But, that's a high bar.

Answer 2

TLS itself is not E2EE - this is a myth.

SSL/TLS goals are to provide integrity of communications so the packet received by one endpoint are verifiable unmodified after the sender transmitted them - i.e. TLS provides only an integrity guarantee with the perception of confidentiality - because an 'endpoint' is intended to have the ability to decrypt, and the term endpoint is loosely defined and can include network devices along the way that do not modify the packets the expected singular 'endpoint' receives ergo network devices and the servers are endpoints that can read the plaintext data as long as the ciphertext each endpoint remains unmodified all TLS endpoints retain the integrity expectation but should never have an expectation of confidentiality.

Don't just take my word for it. In the words of ‌‌Nate Lawson; (cryptographer and software engineer who has contributed to the protocols since SSL3.0)

"Data within the session should not be recoverable by anyone except the endpoints"

This is the reason educated information security researchers and professionals avoid the term "Forward Secrecy" (specially avoid "Perfect" forward secrecy PFS) and prefer the name "Forward Anonymity" which is more helpful and provides no false sense of privacy.

E2EE and HTTP/TLS are 2 very distinct discussions and the only cross over between them is the fact the encrypted data packets are communicated (the transport method) using HTTP. Any transport method can be used for E2EE to be achieved, and some transport methods inherently provide the E2EE capability (though each party must gain assurances of key generation and key control for E2EE to be actually utiled and not just claimed to be E2EE because you use teh protocol; e.g. signal protocol offer E2EE but Signal App doesn't enable users to apply the necessary control so it's claimed to have E2EE but as a user you do not actually gain E2EE. I digress)

For E2EE there is no impact to the data whatever transport method is used, the very nature of E2EE requires your privacy to be ensured when a few factors I explained here are met.

I'll expand on the E2EE specific characteristics further:

• Each endpoint generated their own private keys
• The initiating endpoint must perform a challenge response mechanism to prove an their identity before public key is provided
• The initiating endpoint should encrypt (using the other ends public key) the exchange of their public key, for integrity assurance that only the expected endpoint holding the private key will send you messages to decrypt with your private key
• endpoints never share private keys

That is essentially how E2EE assures privacy to the initiating endpoint, there are no privacy guarantees for the receiving endpoint but they did gain identity assurance in advance.

So "Yes" HTTP and E2EE are compatible (safe), as are all transport methods, is the short answer, but it depends how you apply E2EE entirely outside HTTP