4

This is for end-to-end app, where the server is just 'dumb' temporary storage. I'm considering using plain HTTP (no TLS) to transmit ciphertexts due to the following reasons:

  • Security of a single encryption algorithm is well studied, while stacking multiple ones is unknown (e.g. NaCl() vs. AES(NaCl())
  • Simplicity (at rest == in transit)
  • Increased server load (zero-copy sendfile(2) vs. copying to RAM for TLS encrypt).

What risks do I have using a setup like this:

  • Two channels:
    • HTTPS for authentication/metadata/receive one-time token,
    • HTTP to transmit ciphertexts.
  • Client uses GET/POST http://example.com/?token=one-time.
    Body: ciphertext (chunked in AEAD mode), flexible size (can be large)
  • Server validates token (to prevent reuse) then streams ciphertext to/from disk.
  • Client receives and decrypts ciphertext (to detect modification, truncation, etc.)

4 Answers4

1

It sounds like you're trying to invent some sort of "DropBox" clone.

Security of a single encryption algorithm is well studied, while stacking multiple ones is unknown (e.g. NaCl() vs. AES(NaCl())

I think this does not apply. I can not make a hard mathematical argument here, but for independent encryptions, with completely unrelated keys, the strength of the compound encryption can NOT go down at all. And will be at LEAST as strong as the weaker of the two encryptions. That's all. It's just preventing the simple addition of two key lengths. Worst case you end up with the lower of the two key lengths in the stack. That's for independent keys only. Which we can assume for a combination of at-rest encryption and TLS-session-key encryption. (Correct me if I'm wrong, Sec:SE.)

Simplicity (at rest == in transit)

I think this is will be greatly offset by the complexity of your own authentication/signature scheme.

Increased server load (zero-copy sendfile(2) vs. copying to RAM for TLS encrypt).

I think the impact on latency and throughput will be negligible. Maybe not even measurable. I'd insist on a benchmark. (-> See https://istlsfastyet.com/ )

And again: No idea how much of an impact the auth scheme will have.

Server validates token (to prevent reuse) then streams encrypted archive files to/from disk.

This means that the server is NOT dumb storage anymore.

Instead what about setting things up like a mirror for a Linux distribution? Signed archives on dumb (S)FTP? Since you do client side verification anyway.

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
  • See [this answer](https://security.stackexchange.com/a/18095) and [this](https://blog.cryptographyengineering.com/2012/02/02/multiple-encryption/) . I don't invent my own scheme, just NaCl secretbox. IO latency [drops between 10-30%](https://blog.plenz.com/2014-04/so-you-want-to-write-to-a-file-real-fast.html) (due to `sendfile()`), RAM increases linearly with concurrent read. Note that it drops NOT because of TLS. Also no matter what, server always have to authenticate client for write, the linux repo too. –  Dec 19 '16 at 00:58
  • not sure why you change the tag from E2E to cloud-storage. Server only acts as centralized intermediary here, buffering msg for offline clients. –  Dec 19 '16 at 02:03
  • @BradN: sorry. Spur of the moment here, maybe. Didn't sound like classical-end-to-end-encryption to me. Maybe I misunderstood what you are trying to do. It's not like your own dropbox, but rather like your own OTR-ish instant messaging server? But not for chat and instead for files? – StackzOfZtuff Dec 19 '16 at 06:16
  • Detail is unimportant, dont want to distract from main question "ciphertext in plain transport". However: symmetric encryption, message size is flexible (chat vs files is just small vs large) –  Dec 19 '16 at 06:33
0

When you do end-to-end encryption, the channel to send the ciphertexts back and forth is already considered insecure. The only reason why you might want to have and SSL/TLS tunnel wrapped around the ciphertexts is to validate the server's identity, which depending on your case, might not be necessary.

You can even go one step further and send the data straight over TCP (or UDP if it fits). This saves some overhead. In fact some chat apps do exactly this (Telegram). Obviously this implies you have to take care of authentication and message privacy yourself.

Yorick de Wid
  • 3,346
  • 14
  • 22
  • Thanks, I worried since so many E2E apps wrap with TLS. Feel like I missed something obvious. Do you know whether middleboxes / corporate firewall / antivirus tend to 'ruin' HTTP nowadays ? –  Dec 18 '16 at 15:18
  • @BradN The thing is, it feels like a paradox, doing end-to-end encryption all the while not checking the identity of the server. However there is really no 'need' for it. Take in account that at worst messages do not get received because the server was hijacked. You can use HTTP as a fallback when TCP does not work. – Yorick de Wid Dec 18 '16 at 15:23
  • Is there HTTPS-without-encryption (authenticating server only) ? –  Dec 18 '16 at 15:26
  • @BradN There used to be the NULL ciphersuite, although I believe it is removed in TLS1.3 – Yorick de Wid Dec 18 '16 at 15:28
  • @SDsolar No you don't, please take some time to actually assert the situaition. It doesn't matter whether the communication was spoofed, copied or altered in this case. – Yorick de Wid Dec 18 '16 at 21:13
  • I think about it today and come up with my own answer, would be glad to hear your opinion. –  Dec 19 '16 at 16:10
0

After going through different attack models, I found two possible risks:

  1. Slow retrieval (Denial of Service)

    MiTM on the HTTP channel can fake slow transmission, denying user of quality service.

  2. Corrupt Messages Handling

    Using HTTPS
corrupt packets    → MiTM
corrupt ciphertext → corrupt parties (can be the server)

Using HTTP
no way to distinguish since packet == ciphertext

    Knowing that distinction is valuable, so the program can do the right action (e.g. retry later once channel is secured, or discard message rightaway)

-3

Lastpass does something similar, and it would work just as well on plain HTTP as it does in their implementation.

They use HTTPS for authentication, as specified in the OP.
All your passwords are transmitted and stored using their encryption algorithm.

All the encryption and decryption is done on your own PC, so they do not have a server load imposed by the encryption process.

Where they differ from this post is that they do continue to also use HTTPS for the communications and authentication.

It is not clear why one would want to avoid HTTPS. And since the OP says to use HTTPS for authentication, then why not continue to use it for the rest of the session. With modern processors, there is very little server load imposed by using HTTPS.

The biggest risk in using HTTP is in a replay attack where the lastpass database could become corrupted or lock you out.

I believe they have the best model for secure communications and storage.

Yes, it would work on plain HTTP except for the authentication.

Hope this helps.

SDsolar
  • 977
  • 1
  • 6
  • 25
  • 1
    You don't address the risks and spend a little too much time talking about Lastpass' situation (which does not appear to be relevant to the risks the OP asks about). – schroeder Dec 18 '16 at 20:44
  • Whoa - a downvote and comment before I was even finished writing. That's a first. – SDsolar Dec 18 '16 at 20:51
  • 1
    @SDsolar Your post makes no sense. The Lastpass case is very different from E2EE communication. Also there are most certainly reasons why you want to limit HTTPS, think speed, performance and TTFB. IM chat is notably slower with HTTPS than using for example TCP or UDP only. – Yorick de Wid Dec 18 '16 at 21:17
  • @SDsolar you hit the "Post your answer" button ... – schroeder Dec 18 '16 at 21:47
  • Direct UDP or TCP makes a lot of sense, but then why use HTTP for that? – SDsolar Dec 19 '16 at 01:36
  • I don't understand what you mean by speed, performance and TTFB. – SDsolar Dec 19 '16 at 01:39
  • The fact that TLS has to transfer bytes from disk to memory slows down IO and eat up RAM. The TLS processing itself is negligible. Any plain transport (UDP/TCP/HTTP) is an improvement. –  Dec 19 '16 at 02:19
  • @BradN any plain transport also has to transfer bytes to from disk to memory, network hardware can't do DMA from disk. the gain vs tls it that there's no memory-to-memory en/de-cryption step needed – Jasen Dec 19 '16 at 04:29
  • The en/de-cryption is negligible, copying from kernel to userspace is the problem. Recently Netflix bring the TLS [down to kernel space](https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf). –  Dec 19 '16 at 04:43