1

I am looking into allowing user of our website to upload their file directly to GCE storage without sending the file to our server.

But we want the file to first be encrypted before saving it on GCE. The client does not need access to the file nor the encryption key it generated once it is done with the upload.

Therefore, what I am thinking about is:

  • client (javascript running in browser) generate a random symmetric key, encrypt the file and upload it to GCE
  • client send the key to the server and destroy it

Communication between client & servers is of course over https.

Questions:

  • Is this approach secure? If not, why?
  • Would it be better to use a hybrid encryption? Using a public-key to encrypt the newly generated symmetric key before sending it to the server. If so, what's the benefit?

Correct me if wrong, but I would prefer to avoid only using asymmetric encryption since we may encrypt rather large file and I believe asymmetric encryption does not perform well in that case.

Thanks

Improve this question
4
  • "Is this approach secure? If not, why?" It depends against what you want to defend. Who has access to the GCE disk? Are your users vetted or is your website public (anyone can have an account)? How do you store the received keys on your server?
    – korrigan
    Mar 2, 2018 at 15:40
  • A simple way to defeat your system is capturing the key at the point of creatuion, i.e. on the client's system. Users can retain access to the uploaded files easily. Can your own users be adversaries? Maybe... maybe not...
    – korrigan
    Mar 2, 2018 at 15:41
  • @korrigan website is public and everyone can get an account. The GCE disk is own by our company (which own the server as well). Client only have permission to write to a specific file (created when they want to upload a file). There is a key generated by file, and the key will be store in MySql with the file path and the userid. I am not worries about the security/permission on the server itself. What I don't want is for the key to be leaked in some way.
    – Marc Simon
    Mar 2, 2018 at 16:35
  • The users cannot be adversary imo. The user upload the file themselves (therefore have access to it). Since there is one key by file it's not an issue for us.
    – Marc Simon
    Mar 2, 2018 at 16:38

3 Answers 3

Reset to default
1

So you're encrypting a file to upload to a third party service, then sending the key to your own server. Let's take a look at your proposed options for sending the key:

  1. Send it over TLS
  2. Encrypt it with your server's public key, then send it over TLS

So what you want to know is if option 2 is better than option 1.

Can TLS be bypassed?

If an attacker can't get past TLS then both options are fine, so let's assume they can (eg sslstrip, using social engineering to get you to trust their TLS certificate, etc). If the attacker can get past TLS, that sucks. How much that sucks depends on the type of attacker.

Passive attacker

If a passive attacker can read your TLS traffic, they've undermined the confidentiality, but they're unable to alter the traffic in any way. In this case, using assymetric encryption to encrypt the file key before sending it to your server would protect it.

Active attacker

An active attacker can read your traffic, but they can also modify it. In this case, you're hosed. They can simply alter the JavaScript to have the client upload the file to their own server before encrypting it, and perhaps still encrypt it and upload it to the third party service so no one notices anything wrong.

Which is more likely?

If someone is in a position to read your TLS traffic, they must either have your certificate's private key (which is very bad), or they've intercepted the key exchange, which means they're probably an active attacker.

Is there a better option?

If you're worried about the safety of your TLS connection, the solutions are HPKP and HSTS (although beware of caveats).

Conclusion

In a web context, trying to use JavaScript to improve the security of your connection is generally doomed to fail. Do as much as you can to make sure your TLS connection is secure and just use that.

Improve this answer
5
  • Thanks for your detailed answer. It seems like opt 1 or 2 therefore offer the same kind of security, And if the attacker can get past TLS, this is probably the least of our concern. If we consider TLS cannot be bypassed. Would you see any issue to send the symmetric key directly ?
    – Marc Simon
    Mar 2, 2018 at 16:39
  • @MarcSimon Yes I would just send it directly, I'll add that to the post.
    – AndrolGenhald
    Mar 2, 2018 at 16:58
  • In what scenario can an attacker decrypt TLS traffic and not encrypt it again.
    – McMatty
    Mar 3, 2018 at 1:24
  • @McMatty Perhaps traffic that was logged and the private key was later obtained? Or if the attacker with the private key somehow gets sent a copy of the live traffic?
    – AndrolGenhald
    Mar 3, 2018 at 2:57
  • 1
    Many times, an MITM (with an APT and similar) simply can't perform active attacks. For example, if you compromise a router (not SOHO router) in a large AS, you probably have just barely enough processing power to intercept TLS. These things often have only 32 MiB of memory, or a little more. The real thing they're good at is hardware-accelerated packet switching. You can easily crash those poor systems by trying to inject traffic, especially if you try to use regular expressions.
    – forest
    Mar 3, 2018 at 3:32
1

Firstly I'd like to propose an edit to your question.

"The client WILL not have access to the file once it is done uploading it."

to 

"The client SHOULD not have access to the file once it is done uploading it."

You should always consider that a malicious actor could retrieve your data from storage and consider if your assets are appropriately protected if that happens.

Considerations here are that you should never expose an encryption key to anyone that you do not want to have access to the data.

You should consider how secure and how random your random key generator is, that anyone with access to the javascript can see how it works and could potentially predict keys and also that you are then sending this key over to the server which could be visible to certain MITM attacks.

You are much better off in this case using asymmetric encryption, encrypting on the client side with the public key and allowing decryption only with your scret private key

Improve this answer
7
  • "you are then sending this key over to the server visible to any MITM attack" - He said the connection to the server uses TLS
    – AndrolGenhald
    Mar 2, 2018 at 14:43
  • Yes, and if someone has trusted the right certificates on the target machine, an MITM attack is possible. Ever used Fiddler?
    – iainpb
    Mar 2, 2018 at 14:50
  • I would hardly call that "any MITM attack", you would have to explicitly trust an attacker's certificate.
    – AndrolGenhald
    Mar 2, 2018 at 14:53
  • This is going off topic. My argument is it is possible a malicious actor,could trust a cert on the machine and see HTTPS traffic and that threat should be considered to see if it is relevant.
    – iainpb
    Mar 2, 2018 at 14:57
  • I'm arguing that your threat vector isn't realistic, how is that off topic?
    – AndrolGenhald
    Mar 2, 2018 at 15:00
0

Nope - if you are encrypting a file and sending it up via TLS you are gaining nothing here.

By encrypting with a symmetric key which you send with the file you are essentially mailing a safety deposit box with the key taped to it.

Also relying on the client is shifting security responsibility from yourself to your users. Are their browsers patched? Have they got any browser extensions installed that could be compromised? Is there an XSS vulnerability in your site that allows the browser to get hooked?

If there is a requirement for these files to be encrypted you handle that on your server and not in the browser. If you don't have a requirement for the files to be encrypted on the cloud with a key - then don't tact on the encryption instead just ensure connections are TLS 1.2

Improve this answer
1
  • The file and symmetric key are going to different servers, the goal apparently being to avoid having to trust the file storage server.
    – AndrolGenhald
    Mar 3, 2018 at 3:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .