mirror of
https://github.com/chatmail/core.git
synced 2026-04-05 23:22:11 +03:00
Follow-up for https://github.com/chatmail/core/pull/7042, part of https://github.com/chatmail/core/issues/6884. This will make it possible to create invite-QR codes for broadcast channels, and make them symmetrically end-to-end encrypted. - [x] Go through all the changes in #7042, and check which ones I still need, and revert all other changes - [x] Use the classical Securejoin protocol, rather than the new 2-step protocol - [x] Make the Rust tests pass - [x] Make the Python tests pass - [x] Fix TODOs in the code - [x] Test it, and fix any bugs I find - [x] I found a bug when exporting all profiles at once fails sometimes, though this bug is unrelated to channels: https://github.com/chatmail/core/issues/7281 - [x] Do a self-review (i.e. read all changes, and check if I see some things that should be changed) - [x] Have this PR reviewed and merged - [ ] Open an issue for "TODO: There is a known bug in the securejoin protocol" - [ ] Create an issue that outlines how we can improve the Securejoin protocol in the future (I don't have the time to do this right now, but want to do it sometime in winter) - [ ] Write a guide for UIs how to adapt to the changes (see https://github.com/deltachat/deltachat-android/pull/3886) ## Backwards compatibility This is not very backwards compatible: - Trying to join a symmetrically-encrypted broadcast channel with an old device will fail - If you joined a symmetrically-encrypted broadcast channel with one device, and use an old core on the other device, then the other device will show a mostly empty chat (except for two device messages) - If you created a broadcast channel in the past, then you will get an error message when trying to send into the channel: > The up to now "experimental channels feature" is about to become an officially supported one. By that, privacy will be improved, it will become faster, and less traffic will be consumed. > > As we do not guarantee feature-stability for such experiments, this means, that you will need to create the channel again. > > Here is what to do: > • Create a new channel > • Tap on the channel name > • Tap on "QR Invite Code" > • Have all recipients scan the QR code, or send them the link > > If you have any questions, please send an email to delta@merlinux.eu or ask at https://support.delta.chat/. ## The symmetric encryption Symmetric encryption uses a shared secret. Currently, we use AES128 for encryption everywhere in Delta Chat, so, this is what I'm using for broadcast channels (though it wouldn't be hard to switch to AES256). The secret shared between all members of a broadcast channel has 258 bits of entropy (see `fn create_broadcast_shared_secret` in the code). Since the shared secrets have more entropy than the AES session keys, it's not necessary to have a hard-to-compute string2key algorithm, so, I'm using the string2key algorithm `salted`. This is fast enough that Delta Chat can just try out all known shared secrets. [^1] In order to prevent DOS attacks, Delta Chat will not attempt to decrypt with a string2key algorithm other than `salted` [^2]. ## The "Securejoin" protocol that adds members to the channel after they scanned a QR code This PR uses the classical securejoin protocol, the same that is also used for group and 1:1 invitations. The messages sent back and forth are called `vg-request`, `vg-auth-required`, `vg-request-with-auth`, and `vg-member-added`. I considered using the `vc-` prefix, because from a protocol-POV, the distinction between `vc-` and `vg-` isn't important (as @link2xt pointed out in an in-person discussion), but 1. it would be weird if groups used `vg-` while broadcasts and 1:1 chats used `vc-`, 2. we don't have a `vc-member-added` message yet, so, this would mean one more different kind of message 3. we anyways want to switch to a new securejoin protocol soon, which will be a backwards incompatible change with a transition phase. When we do this change, we can make everything `vc-`. [^1]: In a symmetrically encrypted message, it's not visible which secret was used to encrypt without trying out all secrets. If this does turn out to be too slow in the future, then we can remember which secret was used more recently, and and try the most recent secret first. If this is still too slow, then we can assign a short, non-unique (~2 characters) id to every shared secret, and send it in cleartext. The receiving Delta Chat will then only try out shared secrets with this id. Of course, this would leak a little bit of metadata in cleartext, so, I would like to avoid it. [^2]: A DOS attacker could send a message with a lot of encrypted session keys, all of which use a very hard-to-compute string2key algorithm. Delta Chat would then try to decrypt all of the encrypted session keys with all of the known shared secrets. In order to prevent this, as I said, Delta Chat will not attempt to decrypt with a string2key algorithm other than `salted` BREAKING CHANGE: A new QR type AskJoinBroadcast; cloning a broadcast channel is no longer possible; manually adding a member to a broadcast channel is no longer possible (only by having them scan a QR code)
203 lines
7.7 KiB
Rust
203 lines
7.7 KiB
Rust
//! End-to-end decryption support.
|
||
|
||
use std::collections::HashSet;
|
||
|
||
use anyhow::Result;
|
||
use mailparse::ParsedMail;
|
||
|
||
use crate::key::{Fingerprint, SignedPublicKey, SignedSecretKey};
|
||
use crate::pgp;
|
||
|
||
/// Tries to decrypt a message, but only if it is structured as an Autocrypt message.
|
||
///
|
||
/// If successful and the message was encrypted,
|
||
/// returns the decrypted and decompressed message.
|
||
pub fn try_decrypt<'a>(
|
||
mail: &'a ParsedMail<'a>,
|
||
private_keyring: &'a [SignedSecretKey],
|
||
shared_secrets: &[String],
|
||
) -> Result<Option<::pgp::composed::Message<'static>>> {
|
||
let Some(encrypted_data_part) = get_encrypted_mime(mail) else {
|
||
return Ok(None);
|
||
};
|
||
|
||
let data = encrypted_data_part.get_body_raw()?;
|
||
let msg = pgp::decrypt(data, private_keyring, shared_secrets)?;
|
||
|
||
Ok(Some(msg))
|
||
}
|
||
|
||
/// Returns a reference to the encrypted payload of a message.
|
||
pub(crate) fn get_encrypted_mime<'a, 'b>(mail: &'a ParsedMail<'b>) -> Option<&'a ParsedMail<'b>> {
|
||
get_autocrypt_mime(mail)
|
||
.or_else(|| get_mixed_up_mime(mail))
|
||
.or_else(|| get_attachment_mime(mail))
|
||
}
|
||
|
||
/// Returns a reference to the encrypted payload of a ["Mixed
|
||
/// Up"][pgpmime-message-mangling] message.
|
||
///
|
||
/// According to [RFC 3156] encrypted messages should have
|
||
/// `multipart/encrypted` MIME type and two parts, but Microsoft
|
||
/// Exchange and ProtonMail IMAP/SMTP Bridge are known to mangle this
|
||
/// structure by changing the type to `multipart/mixed` and prepending
|
||
/// an empty part at the start.
|
||
///
|
||
/// ProtonMail IMAP/SMTP Bridge prepends a part literally saying
|
||
/// "Empty Message", so we don't check its contents at all, checking
|
||
/// only for `text/plain` type.
|
||
///
|
||
/// Returns `None` if the message is not a "Mixed Up" message.
|
||
///
|
||
/// [RFC 3156]: https://www.rfc-editor.org/info/rfc3156
|
||
/// [pgpmime-message-mangling]: https://tools.ietf.org/id/draft-dkg-openpgp-pgpmime-message-mangling-00.html
|
||
fn get_mixed_up_mime<'a, 'b>(mail: &'a ParsedMail<'b>) -> Option<&'a ParsedMail<'b>> {
|
||
if mail.ctype.mimetype != "multipart/mixed" {
|
||
return None;
|
||
}
|
||
if let [first_part, second_part, third_part] = &mail.subparts[..] {
|
||
if first_part.ctype.mimetype == "text/plain"
|
||
&& second_part.ctype.mimetype == "application/pgp-encrypted"
|
||
&& third_part.ctype.mimetype == "application/octet-stream"
|
||
{
|
||
Some(third_part)
|
||
} else {
|
||
None
|
||
}
|
||
} else {
|
||
None
|
||
}
|
||
}
|
||
|
||
/// Returns a reference to the encrypted payload of a message turned into attachment.
|
||
///
|
||
/// Google Workspace has an option "Append footer" which appends standard footer defined
|
||
/// by administrator to all outgoing messages. However, there is no plain text part in
|
||
/// encrypted messages sent by Delta Chat, so Google Workspace turns the message into
|
||
/// multipart/mixed MIME, where the first part is an empty plaintext part with a footer
|
||
/// and the second part is the original encrypted message.
|
||
fn get_attachment_mime<'a, 'b>(mail: &'a ParsedMail<'b>) -> Option<&'a ParsedMail<'b>> {
|
||
if mail.ctype.mimetype != "multipart/mixed" {
|
||
return None;
|
||
}
|
||
if let [first_part, second_part] = &mail.subparts[..] {
|
||
if first_part.ctype.mimetype == "text/plain"
|
||
&& second_part.ctype.mimetype == "multipart/encrypted"
|
||
{
|
||
get_autocrypt_mime(second_part)
|
||
} else {
|
||
None
|
||
}
|
||
} else {
|
||
None
|
||
}
|
||
}
|
||
|
||
/// Returns a reference to the encrypted payload of a valid PGP/MIME message.
|
||
///
|
||
/// Returns `None` if the message is not a valid PGP/MIME message.
|
||
fn get_autocrypt_mime<'a, 'b>(mail: &'a ParsedMail<'b>) -> Option<&'a ParsedMail<'b>> {
|
||
if mail.ctype.mimetype != "multipart/encrypted" {
|
||
return None;
|
||
}
|
||
if let [first_part, second_part] = &mail.subparts[..] {
|
||
if first_part.ctype.mimetype == "application/pgp-encrypted"
|
||
&& second_part.ctype.mimetype == "application/octet-stream"
|
||
{
|
||
Some(second_part)
|
||
} else {
|
||
None
|
||
}
|
||
} else {
|
||
None
|
||
}
|
||
}
|
||
|
||
/// Validates signatures of Multipart/Signed message part, as defined in RFC 1847.
|
||
///
|
||
/// Returns the signed part and the set of key
|
||
/// fingerprints for which there is a valid signature.
|
||
///
|
||
/// Returns None if the message is not Multipart/Signed or doesn't contain necessary parts.
|
||
pub(crate) fn validate_detached_signature<'a, 'b>(
|
||
mail: &'a ParsedMail<'b>,
|
||
public_keyring_for_validate: &[SignedPublicKey],
|
||
) -> Option<(&'a ParsedMail<'b>, HashSet<Fingerprint>)> {
|
||
if mail.ctype.mimetype != "multipart/signed" {
|
||
return None;
|
||
}
|
||
|
||
if let [first_part, second_part] = &mail.subparts[..] {
|
||
// First part is the content, second part is the signature.
|
||
let content = first_part.raw_bytes;
|
||
let ret_valid_signatures = match second_part.get_body_raw() {
|
||
Ok(signature) => pgp::pk_validate(content, &signature, public_keyring_for_validate)
|
||
.unwrap_or_default(),
|
||
Err(_) => Default::default(),
|
||
};
|
||
Some((first_part, ret_valid_signatures))
|
||
} else {
|
||
None
|
||
}
|
||
}
|
||
|
||
#[cfg(test)]
|
||
mod tests {
|
||
use super::*;
|
||
use crate::receive_imf::receive_imf;
|
||
use crate::test_utils::TestContext;
|
||
|
||
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
||
async fn test_mixed_up_mime() -> Result<()> {
|
||
// "Mixed Up" mail as received when sending an encrypted
|
||
// message using Delta Chat Desktop via ProtonMail IMAP/SMTP
|
||
// Bridge.
|
||
let mixed_up_mime = include_bytes!("../test-data/message/protonmail-mixed-up.eml");
|
||
let mail = mailparse::parse_mail(mixed_up_mime)?;
|
||
assert!(get_autocrypt_mime(&mail).is_none());
|
||
assert!(get_mixed_up_mime(&mail).is_some());
|
||
assert!(get_attachment_mime(&mail).is_none());
|
||
|
||
// Same "Mixed Up" mail repaired by Thunderbird 78.9.0.
|
||
//
|
||
// It added `X-Enigmail-Info: Fixed broken PGP/MIME message`
|
||
// header although the repairing is done by the built-in
|
||
// OpenPGP support, not Enigmail.
|
||
let repaired_mime = include_bytes!("../test-data/message/protonmail-repaired.eml");
|
||
let mail = mailparse::parse_mail(repaired_mime)?;
|
||
assert!(get_autocrypt_mime(&mail).is_some());
|
||
assert!(get_mixed_up_mime(&mail).is_none());
|
||
assert!(get_attachment_mime(&mail).is_none());
|
||
|
||
// Another form of "Mixed Up" mail created by Google Workspace,
|
||
// where original message is turned into attachment to empty plaintext message.
|
||
let attachment_mime = include_bytes!("../test-data/message/google-workspace-mixed-up.eml");
|
||
let mail = mailparse::parse_mail(attachment_mime)?;
|
||
assert!(get_autocrypt_mime(&mail).is_none());
|
||
assert!(get_mixed_up_mime(&mail).is_none());
|
||
assert!(get_attachment_mime(&mail).is_some());
|
||
|
||
let bob = TestContext::new_bob().await;
|
||
receive_imf(&bob, attachment_mime, false).await?;
|
||
let msg = bob.get_last_msg().await;
|
||
// Subject should be prepended because the attachment doesn't have "Chat-Version".
|
||
assert_eq!(msg.text, "Hello, Bob! – Hello from Thunderbird!");
|
||
|
||
Ok(())
|
||
}
|
||
|
||
#[tokio::test(flavor = "multi_thread", worker_threads = 2)]
|
||
async fn test_mixed_up_mime_long() -> Result<()> {
|
||
// Long "mixed-up" mail as received when sending an encrypted message using Delta Chat
|
||
// Desktop via MS Exchange (actually made with TB though).
|
||
let mixed_up_mime = include_bytes!("../test-data/message/mixed-up-long.eml");
|
||
let bob = TestContext::new_bob().await;
|
||
receive_imf(&bob, mixed_up_mime, false).await?;
|
||
let msg = bob.get_last_msg().await;
|
||
assert!(!msg.get_text().is_empty());
|
||
assert!(msg.has_html());
|
||
assert!(msg.id.get_html(&bob).await?.unwrap().len() > 40000);
|
||
Ok(())
|
||
}
|
||
}
|