undefined | Better HN

0 pointstimvisee7y ago0 comments

The client encrypts the file that is uploaded, along with some metadata. The key is appended to the share URL provided by the URL, in the fragment/hash, and is never sent to the remote server. Only people having the URL including the secret will be able to download and decrypt your shared file. See https://github.com/mozilla/send/blob/master/docs/encryption....

0 comments

bjt2n39047y ago

Thanks for the info. Let me see if I understand this correctly.

Browsers don't send the anchor tag (ie: with GET requests). FF Send takes advantage of this by using the anchor tag to store the key for decryption.

That is kinda novel. You still need to trust the upload client to not leak the key, but I see that you've written a CLI version. Interesting! Thanks for the response.

timviseeOP7y ago

You got it! The only thing you'd have to worry about is malicious JavaScript on the Firefox Send website which I believe would be highly unlikely. And of course, you must keep your link secret.

Yes, such a CLI tool would help protect you against a MITM with malicious JavaScript.

Piskvorrr7y ago

Unlikely but possible. Two words: browser extensions.

1 more reply

NKCSS7y ago

It's not a new idea, the megaupload successor first did it as far as I can remember

simias7y ago

Indeed, the website serves you the crypto code but it runs totally on the client so it's perfectly safe and could in no way be backdoored.

More seriously, did they do anything to fix this obvious design flaw? If they want to fish a key they can just serve you a modified JS file and retrieve the key. Unless of course you chose to audit the JS served every time you browse the website.

1 more reply

coolspot7y ago

Yes, the mega.co.nz . End-to-end encrypted dropbox analog.

solarkraft7y ago

It's cool, but not exactly novel. Mega has done it this way for years.

philsnow7y ago

Anybody who can catch the link in transit can get the file. Emailing these links with the decryption key right in the fragment is going to allow any party in between the sender and the receiver to fetch the file. (If the file is set to only allow downloading once, the receiver can at least let the sender know that it got intercepted.)

So you have to send the link through some previously-negotiated secure channel. At that point, why not just send the file through that channel? Is it because signal/whatsapp/etc don't allow large files or because the interface is cumbersome?

Legogris7y ago

Absolutely. Security and secrecy are not binary, though, it's a spectrum. There are many things where you would mostly want to avoid dragnet attacks and undetected intrusion but don't have concerns for targeted attacks like the one you are describing.

I think this fills the gap for when you want to share not-critically-secret stuff with non-technical people and would today likely send it over something like e-mail, Drive or Dropbox.

philsnow7y ago

I don't disagree. I've been thinking about how I would write the announcement copy explaining to non-technical users how the links should also be treated as secret and how email is not encrypted in general. It's a hard problem.

1 more reply

SubiculumCode7y ago

Right. If I were really really concerned one would encrypt it locally then send...which you could do in ff send.

bjt2n39047y ago

True, but I don't think I'd use this website for anything I'm that concerned about. At that point, I'd encrypt it myself with something like gpg or openssl on the command line.

This fills a handy gap for a lot of people with smaller needs.

philsnow7y ago

> I'd encrypt it myself with something like gpg or openssl on the command line.

> This fills a handy gap for a lot of people with smaller needs.

You point out exactly the problem: the people who are technical enough to deal with GPG's UX competently are also technical enough to evaluate whether they should put a particular document through this Send service.

I don't think nontechnical people have "smaller needs".

timviseeOP7y ago

Yes. I would like to add though, that you can set an optional password as well. Without it the link would be useless. You can share it through a different channel.

air77y ago

That's cool, but it's still the same party providing both the storage mechanism, and the JS that encrypts the content on the client-side. You have to trust them that they are not "peeking" at the keys you are generating using their code in your browser.

mrmanner7y ago

But at least you only need to trust them now, and not every incarnation of them in the future =)

SubiculumCode7y ago

Not to mention that onr could always encrypt it themselves then use ff send

jszymborski7y ago

This is where WebCrypto in browser extensions begins to get interesting, I think.

jszymborski7y ago

I use a similar mechanism on my website https://expiring.link

I'm working on documenting the code now before I release on GitHub, but it works on the same premise :)

WebCrypto is mana from the gods...

srecio7y ago

Won't most people just share the links over email? With the decryption key in the url I don't see very good security guarantees here

j / k navigate · click thread line to collapse

0 comments

bjt2n39047y ago

Thanks for the info. Let me see if I understand this correctly.

Browsers don't send the anchor tag (ie: with GET requests). FF Send takes advantage of this by using the anchor tag to store the key for decryption.

That is kinda novel. You still need to trust the upload client to not leak the key, but I see that you've written a CLI version. Interesting! Thanks for the response.

timviseeOP7y ago

You got it! The only thing you'd have to worry about is malicious JavaScript on the Firefox Send website which I believe would be highly unlikely. And of course, you must keep your link secret.

Yes, such a CLI tool would help protect you against a MITM with malicious JavaScript.

Piskvorrr7y ago

Unlikely but possible. Two words: browser extensions.

1 more reply

NKCSS7y ago

It's not a new idea, the megaupload successor first did it as far as I can remember

simias7y ago

Indeed, the website serves you the crypto code but it runs totally on the client so it's perfectly safe and could in no way be backdoored.

1 more reply

coolspot7y ago

Yes, the mega.co.nz . End-to-end encrypted dropbox analog.

solarkraft7y ago

It's cool, but not exactly novel. Mega has done it this way for years.

philsnow7y ago

Legogris7y ago

I think this fills the gap for when you want to share not-critically-secret stuff with non-technical people and would today likely send it over something like e-mail, Drive or Dropbox.

philsnow7y ago

1 more reply

SubiculumCode7y ago

Right. If I were really really concerned one would encrypt it locally then send...which you could do in ff send.

bjt2n39047y ago

True, but I don't think I'd use this website for anything I'm that concerned about. At that point, I'd encrypt it myself with something like gpg or openssl on the command line.

This fills a handy gap for a lot of people with smaller needs.

philsnow7y ago

> I'd encrypt it myself with something like gpg or openssl on the command line.

> This fills a handy gap for a lot of people with smaller needs.

I don't think nontechnical people have "smaller needs".

timviseeOP7y ago

Yes. I would like to add though, that you can set an optional password as well. Without it the link would be useless. You can share it through a different channel.

air77y ago

mrmanner7y ago

But at least you only need to trust them now, and not every incarnation of them in the future =)

SubiculumCode7y ago

Not to mention that onr could always encrypt it themselves then use ff send

jszymborski7y ago

This is where WebCrypto in browser extensions begins to get interesting, I think.

jszymborski7y ago

I use a similar mechanism on my website https://expiring.link

I'm working on documenting the code now before I release on GitHub, but it works on the same premise :)

WebCrypto is mana from the gods...

srecio7y ago

Won't most people just share the links over email? With the decryption key in the url I don't see very good security guarantees here

j / k navigate · click thread line to collapse