I agree with removing Startmail. Adding automatic incoming PGP encryption like what Mailbox.org provides would probably be trivial and wouldn’t replace their existing implementation, so that is an option if they wanted to meet the new criteria without overhauling their entire system.
I agree with @ph00lt0 that the TLS 1.0/1.1 thing is important.
I do actually believe downgrade attacks are still a thing. As I also DMed you China blocks TLS1.3
(China is now blocking all encrypted HTTPS traffic that uses TLS 1.3 and ESNI | ZDNET)
This actually causes that users would be using 1.2 instead. Similar could be done with TLS1.2 I do not see why ths could not work afaik MTA-STS does not prevent this unless the server does not accept the protocol.
This is in fact true, and Russia also has shown interest in it https://www.zdnet.com/article/russia-wants-to-ban-the-use-of-secure-protocols-such-as-tls-1-3-doh-dot-esni/
So I pointed out to Mailbox.org that the main issue with allowing TLS 1.0/1.1 is that it can meet a success on a MTA-STS policy that is set to enforce mode. Their secure.mailbox.org domain does not support TLS 1.3 only 1.2.
I pointed out that, Microsoft, Yahoo have disabled TLS 1.0/1.1 on their primary domains and that Microsoft, NCSC-UK, NCSC-NL, and NIST all recommend disabling these old protocols in accordance with RFC 8996.
Their reply updated with:
Thank you for your suggestion. I’ll forward this as a feature request to our product manager. He can then decide whether we include the feature. Since this can be a lengthy and complex process, I can’t keep you updated on the development. Therefore, I am closing the ticket. However, if you have any other suggestions or questions, please write to us.
I’m thinking we will re-review this in 6 months and then decide whether to make this a mandatory requirement. I really would like to avoid removing mailbox.org due to the fact they have a PGP implementation that does not require them holding the private key encrypted or otherwise.
As for Start Mail, I think we have no option to but to remove that as it’s really not zero knowledge encryption, if the encryption can be reversed at any point in which the “user vault” is open.
I am not really sure why they believe this to be a length process tbh. These are all just simple config settings. I would hope they are managable.
I gave them my email, and encouraged their product manager to reach out to me with an answer or reply to this thread. I guess we will wait and see.
I would like to hear something from them which is a little less “open ended”.
So I did get another reply from Mailbox.org:
They seem fixed on the idea that it’s better support legacy systems with weak/broken encryption at the cost of modern systems.
The problem with their approach of relying on cipher suite preference is that puts privacy in the hands of the sender not the recipient, who might demand that all email be securely sent.
They directed me towards their secure.mailbox.org feature, which I doubt it’s usefulness. It doesn’t get used by anyone with a custom domain and I imagine a lot of regular Mailbox.org users forget to tell people about it anyway, particularly as it wouldn’t be in sender address books.
Email isn’t considered particularly secure because of opportunistic encryption and is still no substitute for E2EE but I think it’s a mistake to weaken attempts to strengthen explicit TLS for legacy reasons.
If we don’t restrict this particular constraint, I think we should certainly make note of it in the description.
I guess this really does make Proton Mail deserving of being listed 1st on our website.
I checked again now, it seems to have been reversed. I didn’t have contact with them so maybe they were just testing something at that time.
It seems that Hardenize isn’t entirely reliable. I was able to see that it had TLS v1.3 with testssh.sh, drwetter/testssl.
You can run the command and export to a nice HTML document using aha. Ie:
❯ ./testssl.sh --starttls smtp mx.example.com:25 |
aha --black --title mx.example.com > mx_example.html
I am pretty sure I mentioned this problem with hardenize before, hence I use only internet.nl
In their report also it says that TLS version is “None” this may have to do something with the way Mailbox has configured things. I tend to conclude obsecurity.
But more interresting is that they use insufficient ciphers and do not prioritize good ones. From this we know that at least they do not enforce TLS1.3 as this does have a fixed set. So even if they support TLS1.3 they do not prioritize it so it’s not as useful.
Does that means that mailboxorg will be deleted from the recommendation list too because of the lack of zero-knowledge-encryption?
The only email service in that list that supports IMAP SMTP without needing an extra app is mailboxorg, and I think that’s a very important point because we are not locked to the email services official apps.
I actually changed from Startmail to mailboxorg trying to follow the criteria listed on the “Recomended email services” page.
I find both topics important, but now I don’t know what to do. I like being able to use IMAP without needing Proton Mail Bridge while using mailboxorg, but I also feel that zero-knowledge-encryption is important that ProtonMail provides.
If this is considered off-topic please remove my message but I think that is important to point this out.
EDIT: I tried searching what’s the process of Proton to encrypt incoming emails to save them to the inbox and looks the same as the one used by mailboxorg. An email arrives and it’s encrypted using the pgp public key stored in the user account. Am I missing or misunderstanding something?
Hey @dngray! I work for Hardenize’s parent company. Thanks for flagging that, I’ve brought it up to the team to look into it. We want to make sure we keep providing useful data for your email audits, so if you find anything else that we’re not showing correctly - please do PM me (and happy PM my work email, too).
We consider their automatic PGP encryption on incoming messages to satisfy this requirement.
Edit: I see you’re replying to dngray’s comment which has a confusing line about a “user vault.” Just to be clear, the “user vault” solution we had an issue with was Startmail’s, not mailbox.org’s.
I do not recommend aes-128-cbc in general
Awesome, sorry I forgot to report this I was meaning to.