2

Firefox recently launched its file share service, Send. It promises end-to-end encryption: the file to share is encrypted in the sender's browser and decrypted in the recipient's browser using a key embedded within the shared URL.

A URL to share a file is formatted as below:

https://send.firefox.com/download/03837dac3928b1d1/#lIFX1W1S2oXSwJF0QgMe_A

I suppose that one part of the URL represents the location of the file on Mozilla's servers and the other one is the encryption key. However, from a valid URL, whichever part I change I get an error "That link has expired". Thus I couldn't figure out if my guess was correct.

Anyway, my question is about how confident I can be with that end to end encryption. That mechanism is smart but I noticed that I was able to get back the link of any of my shares from my firefox account on any device. That means that the whole link is somehow stored in my account on Mozilla's servers.

If so, it is technically feasible for Mozilla to decrypt every shared file. Am I missing something? Does any one has a good understanding about how Firefox Send really works and if it is safe to rely on that end-to-end encryption mechanism?

Thanks a lot.

1

I wondered the same thing and landed on this question. Oh well, I can try to do my own research.

Mozilla documented the encryption used here and to explain it in simpler terms:

Uploading

  1. Your app/browser generate an encryption key
  2. The key is used to generate 3 additional keys: one for the file encryption itself, one for the metadata and one signing key
    • If you set a password, the password and the encryption key are combined in a secure manner to create the signing key instead
  3. The file and metadata get encrypted
  4. Encrypted data and the signing key are sent to Mozilla
    • Note that due to the way the signing key are generated, it is not possible to compute back the original encryption key used to generate the any of the keys
  5. Mozilla send you the URL of the file (without the part after #) and a token. This token can be used to delete the file.
  6. Your app append # sign and the encryption key

Downloading

  1. You enter the download page. Every browsers do not submit the part after # to the server. (They're usually used for anchor links which are link to another section of the same page)
  2. Mozilla send your app a "nonce" (number used only once) or basically some random garbage data
  3. Since you have the encryption key after the #, the app generate all 3 keys as in uploading steps 2. You'll get the exact same keys as the uploader.
  4. The app sign the server-provided nonce with the signing key
  5. The app send the signed nonce to Mozilla
  6. Since Mozilla also have the same signing key, they also do step 4 on their side as well and expect it to match the one that you send. This step ensures that either
    • You know the correct encryption key
    • or if the file is password protected, you know the password
  7. Once you've verified that you know the key (without even revealing the key to server), Mozilla send you the encrypted metadata.
  8. The app decrypt this metadata on your computer and show you details
  9. You click download
  10. The app download the encrypted files and decrypt it on your computer

So, to answer your questions:

I suppose that one part of the URL represents the location of the file on Mozilla's servers and the other one is the encryption key. However, from a valid URL, whichever part I change I get an error "That link has expired". Thus I couldn't figure out if my guess was correct.

From downloading steps 6, if you cannot prove that you know the correct encryption key then Mozilla will refuse to send you the file.

Anyway, my question is about how confident I can be with that end to end encryption. That mechanism is smart but I noticed that I was able to get back the link of any of my shares from my firefox account on any device. That means that the whole link is somehow stored in my account on Mozilla's servers.

This part is not written in the document I linked. I look around the source and found that they upload the list of uploaded files to your account. This data is encrypted I believe with similar process to file encryption.

I looked around and it seems the encryption key is generated locally. I'm not sure how the key is synced though.

If so, it is technically feasible for Mozilla to decrypt every shared file. Am I missing something? Does any one has a good understanding about how Firefox Send really works and if it is safe to rely on that end-to-end encryption mechanism?

A big disclaimer here is that I'm not an encryption expert and you may want to ask crypto.se's opinion on this.

If you ask me, I think the encryption process here is pretty solid and the algorithms used are industry standard. There's no way for Mozilla to decrypt every single files without brute forcing each and every key used, one per file.

However, you should be aware of the extra features that you have to trust that Mozilla are doing their jobs:

  • Password is verified only by server. If you happen to obtain the encrypted files and the encryption key then you can decrypt the data without knowing the password. Normally this wouldn't be a problem as the server don't send you the encrypted files unless you have proven that you know the password. However, Mozilla themselves have access to the encrypted file so the encryption key is the only protection here.
    • Considering that most user-provided passwords are weak, generating a random, strong encryption key is better than using the password to encrypt data directly.
  • Expiration are not possible to implement in a cryptographically secure manners, since you cannot get the true current time in a math function. So, you'll have to trust that Mozilla do remove your expired files.

Note that Firefox Send open source server supports AWS as storage backend. I'm not sure what Firefox used in their public service, but if it is AWS then you'll have to trust AWS on both issues above as well.

| improve this answer | |
  • Oh yes, very clear, many thanks! I missed the fact that the anchor was not transmitted.. – Nicolas Garnier Dec 17 '19 at 16:10

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.