Conversations: http upload: filename not encrypted

[DeLadoss]

When sending a file to a contact using OMEMO, the http upload method is used if available. Unfortunately, the filename is not encrypted. This is a problem since the filename can be meaningfull (e.g. kennedy_assasination_conspiracy.pdf).

[jkufner]

You can, and you should, configure your web server and XMPP server to use HTTPS. Then sharing a file will be secure even when chat is not end-to-end encrypted (which is redundant when using private trusted server).

[DeLadoss]

It is, that's not the issue.

But what if the server become compromised? The interest of the p2p encryption is not to rely on the server. If I can trust the server, encryption is useless.

At the moment, if I look in the http_upload folder on my server, I can see all the session folder. In each folder, there is a file which is encrypted but the filename is in clear text. That's a problem.

[SafwatHalaby]

Proposed solution: Put the filename in the URL hash part, similar to the way the encryption key is sent over.

For instance, if we'd like to send kennedy_assasination_conspiracy.pdf, we do this:

• Upload the pdf as 21587715.encrypted
• Send the following link to the other client:

http://fileServer.example.com/21587715.encrypted#OMEMOKEY=123&name=kennedy_assasination_conspiracy.pdf.

[timosl]

Related to #1494

[knoy]

I agree this is a serious problem and should be resolved. Filenames and filetypes can be extremely powerful metadata that shouldn't be leaked. At the same time, there should be a way for filenames to be retained after transfer. I think a viable solution would be to encrypt the filename using the OMEMO key.

SafwatHalaby:
This is not a solution and the original problem isn't resolved. The server still knows the complete filename in this scenario

[iNPUTmice]

This is not a solution and the original problem isn't resolved. The server still knows the complete filename in this scenario

not if this link is shared as an encrypted messages.

I actually think this is a good idea. will think about it a little longer though because this is putting more and more meta data in the anchor part of the url which seems a little hacky.

[SafwatHalaby]

@iNPUTmice One more thing you might want to consider: Currently, the omemo URL has no identifier at all. Making omemo identifiable should future proof this. For instance:

www.example.com/encrypted.encrypted#omemo=v1.5.2&filename=conspiracy.pdf&secret=123

...because this is putting more and more meta data in the anchor part of the url which seems a little hacky.

I don't think that's a concern. This is not a slippery slope. There really isn't much more metadata to put other than a name, version, secret, and possibly a date. It can't get worse than that.

[knoy]

not if this link is shared as an encrypted messages.

The problem is the server will still know the filename, which would be easily attainable if it's contained in the URL by looking through the access logs, regardless of how the message is sent.

Or does Conversations do some special parsing of the URL beforehand to remove any confidential parameters? If that's the case this could definitely work

[strb]

The problem is the server will still know the filename, which would be easily attainable if it's contained in the URL by looking through the access logs, regardless of how the message is sent.

The fragment identifier is by definition not part of the URL. See section 2.1 of RFC 1808. It is not supposed to be transmitted in the request. If it was, encrypting the file would be useless to begin with. The fragment identifier is where we put the encryption key as well.

Or does Conversations do some special parsing of the URL beforehand to remove any confidential parameters? If that's the case this could definitely work

Special parsing is not necessary, this is standard behavior. See RFC 3986.

[knoy]

I stand quite corrected! Learn something new about the web every day, sorry for my ignorance . I wholeheartedly endorse this idea then

[imShara]

Problem still here. Any plans to solve it? Server should not store anything readeable inside users conversations.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[dllud]

IMHO you should reconsider the usage of this stale bot to close issues.
An issue should only be closed when it gets solved or it is no longer relevant. This issue reached none of those stages.
If you wish the bot to work as a reminder please disable it from closing issues. As it is, it just forces issue reporters to make pointless comments (as this one).
I had this same discussion on a few other projects. The general agreement was that this bot creates nothing but superfluous discussions.

[licaon-kter]

There's an opposite issue BTW, so which one is it? Clear filenames or "encrypted"? Hope not "a toggle"

[imShara]

It's huge problem actually, which breaks privacy. Filenames should be encrypted without compromise

[jkufner]

However, I would really hate to loose the filenames when sending the files.

[imShara]

@jkufner, filenames should be restored when you save it. Just need to store file content and it's meta in different place.

[sreutter]

With Conversations 2.8.10 the file name is changed - i.e. the original file name is lost. I don't think that's ideal. I often receive images that have e.g. IMG_20200718_175015.jpg as file names, and that should be preserved. I would like to see the possibility in Conversations that the file is available unchanged after the transfer, including the file name. Shouldn't it be possible to name the file differently during httpupload and to restore the original name when it is downloaded to the target?

[imShara]

With Conversations 2.8.10 the file name is changed - i.e. the original file name is lost. I don't think that's ideal. I often receive images that have e.g. IMG_20200718_175015.jpg as file names, and that should be preserved. I would like to see the possibility in Conversations that the file is available unchanged after the transfer, including the file name. Shouldn't it be possible to name the file differently during httpupload and to restore the original name when it is downloaded to the target?

It's possible, but there is no XEP for this I think