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 Answers 4

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.

4
  • See this answer and this . I don't invent my own scheme, just NaCl secretbox. IO latency drops between 10-30% (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.
    – user133760
    Dec 19, 2016 at 0: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.
    – user133760
    Dec 19, 2016 at 2: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? Dec 19, 2016 at 6: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)
    – user133760
    Dec 19, 2016 at 6: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.

6
  • 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 ?
    – user133760
    Dec 18, 2016 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. Dec 18, 2016 at 15:23
  • Is there HTTPS-without-encryption (authenticating server only) ?
    – user133760
    Dec 18, 2016 at 15:26
  • @BradN There used to be the NULL ciphersuite, although I believe it is removed in TLS1.3 Dec 18, 2016 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. Dec 18, 2016 at 21:13
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)

1
  • Please edit your original post next time. Dec 19, 2016 at 16:57
-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.

9
  • 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, 2016 at 20:44
  • Whoa - a downvote and comment before I was even finished writing. That's a first.
    – SDsolar
    Dec 18, 2016 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. Dec 18, 2016 at 21:17
  • @SDsolar you hit the "Post your answer" button ...
    – schroeder
    Dec 18, 2016 at 21:47
  • Direct UDP or TCP makes a lot of sense, but then why use HTTP for that?
    – SDsolar
    Dec 19, 2016 at 1:36

You must log in to answer this question.