This can be prone to downgrade attacks in the network! Something certain governments do to be able to get more data out of TLS requests. We should really not allow anything that does not run on 1.2 at least. There is actually no good reason to not run on 1.3 entirely. I am not aware on any issues besides that TLS 1.3 is blocked in china.
As far as I am aware, this is still the case with a ≥ TLS 1.2 requirement. If there is a failure during TLS communication the message will be retried without TLS at all by most implementations.
well yeah the server should refuse connections without 1.2 or higher. It communicates this in the handshake so the endpoint knows this (and therefore should not retry)
Some good info on this:
Also from UK NSCS:
TLDR: do not use anything below 1.2
On my own infrastructure I do not allow for any connections that do not have 1.3 and I have never heard of any issues because of this. I am only active in Europe so there is that, but I would urge to at least require 1.2. Anything below is really a bad idea.
2 Likes
I’m going to evaluate how many of our providers currently do this. I just checked my personal email, and well over 99% of received emails were received with TLS 1.2, and the remaining were unencrypted, not TLS 1.0 or 1.1.
If we’re splitting this we can also define the requirements for cipher suits in TLS1.2.
TLS1.3 enforces good ciphers so that can be left.
Good:
-
ECDHE-ECDSA-AES256-GCM-SHA384(TLS_AES_256_GCM_SHA384in 1.3) [1.2] -
ECDHE-ECDSA-CHACHA20-POLY1305(TLS_CHACHA20_POLY1305_SHA256in 1.3) [1.2] -
ECDHE-ECDSA-AES128-GCM-SHA256(TLS_AES_128_GCM_SHA256in 1.3) [1.2] -
ECDHE-RSA-AES256-GCM-SHA384(TLS_AES_256_GCM_SHA384in 1.3) [1.2] -
ECDHE-RSA-CHACHA20-POLY1305(TLS_CHACHA20_POLY1305_SHA256in 1.3) [1.2] -
ECDHE-RSA-AES128-GCM-SHA256(TLS_AES_128_GCM_SHA256in 1.3) [1.2]
Sufficient:
-
ECDHE-ECDSA-AES256-SHA384[1.2] -
ECDHE-ECDSA-AES128-SHA256[1.2] -
ECDHE-RSA-AES256-SHA384[1.2] -
ECDHE-RSA-AES128-SHA256[1.2] -
DHE-RSA-AES256-GCM-SHA384[1.2] -
DHE-RSA-CHACHA20-POLY1305[1.2] -
DHE-RSA-AES128-GCM-SHA256[1.2] -
DHE-RSA-AES256-SHA256[1.2] -
DHE-RSA-AES128-SHA256[1.2]
and no others.
Copied from internet.nl who on their part did from the Dutch NCSC documents listed above.
1 Like
Protonmail does:
ProtonMail appears to be the only provider enforcing this on port 25.
Mailbox.org appears to support TLS 1.0/1.1 even though they say they shouldn’t as of 2020.
Tutanota appears to support TLS 1.0/1.1 even though they say they shouldn’t as of 2019.
Startmail appears to support TLS 1.0/1.1, I can’t find any deprecation plans on their end (but that’s fine w/ me since I want to delist them for unrelated reasons anyways).
@dngray you’ve emailed these providers before, I wonder if you might want to check and see why this is still the case, and if they have any stats on how many emails are being received with TLS 1.0/1.1 if they claim to need it on port 25 for backwards compatibility reasons?
I am actually surprised by this a lot. This really ain’t smart. I wonder why they have not tbh.
Could do that, sure.
2 Likes
Also, SimpleLogin supports TLS 1.1 but not TLS 1.0, and AnonAddy only supports TLS 1.2 and above.
i actually have been testing all this before moving from my own email server to proton.
I also remember now also being annoyed about simplelogin I did report this to them also. I have a visionary account so lemme reach out again to them.
Proton just got back to me:
Please kindly note that we acknowledge your remarks and our team will try to update it in a future update.
Tutanota has removed the outdated TLS support now:
Did you hear anything from them @dngray ?
Waiting to hear back from Mailbox.org and Startmail
That sounds like a very canned reply from a support representative who likely has little to no idea what’s being discussed.
Here’s hoping…
Agreed, but I asked them to forward it to SL so it makes sense.
Received a reply from Mailbox.org
Thank you very much for your message. We had already blocked the two protocols for transport encryption, but in practice we had to realize that this is unfortunately not yet practical, because we also want to accept mails for our customers. We therefore prefer to accept messages that are poorly encrypted than not encrypted because no transport encryption standard could be negotiated. Please note that in the case of mail communication, the sender and the recipient must always agree on a protocol and we always accept the highest standard in any case. When it is not possible to agree on a protocol the mail will be send in plain text.
If you really want to be sure and send the messages exclusively over encrypted channels, I recommend you to use our secure addresses here.
https://kb.mailbox.org/en/private/e-mail-article/ensuring-e-mails-are-sent-securely
I don’t think the TLS 1.0/1.1 thing is important if they are already doing a server suite preference.
I sent them an email and asked about their user vault. They confirmed that it’s not really zero knowledge encryption as it is “server-side encryption”. They don’t currently have any plans to change that. It appears the LUKS system mentioned in the whitepaper was developed by an external team and they continue now to develop it in-house. I’m not too sure we can continue to recommend Start Mail alongside the other products because we did add the zero-knowledge requirement some time ago. It is worth noting we removed Disroot (although they are working on a PGP based inbox encryption like Mailbox.org have). Mailfence also isn’t listed for the same reason. I emailed them again on 9th March 2022, and they still haven’t got that ready.
As for WKD, they said their developers are enthusiastic about along with importing own keypairs and allowing adjustment of the algorithm from the 3072 DSA/ElGamal keys that are generated. Currently it is not possible to use RSA 4096bit or ed25519/cv25519 private keys with Start Mail, unless you use an email client. While that is an option, it means that Start Mail really isn’t any better than Fastmail, Migadu or other providers we don’t list.
I think for PGP providers we must:
- Make WKD a requirement, without key discovery people aren’t likely to use PGP.
- Require encryption in the client, we really don’t want to be encouraging Hushmail-like encryption.
This would also allow us to address StartMail: Add a warning explaining drawbacks of the User Vault · Issue #1433 · privacyguides/privacyguides.org · GitHub which a user in our community has already picked up.
I don’t think the TLS 1.0/1.1 thing is important if they are already doing a server suite preference.
I have to disagree on this. Cipher suits are not the only problem of these outdated protocols.
F.x. the pseudo random functions in TLS 1.1 (and i believe also TLS 1.0) are using MD5 and SHA-1. There is no known exploit on this, but I think I do not need to explain why this is a bad idea. Much worse is that TLS1.1 and lower do not suppport modern cryptography so therefore using so can be used in downgrade attacks and this will reduce the security of the user. Because of this and other issues NIST recommends disabling TLS 1.1 and TLS 1.0. (https://www.nist.gov/publications/guidelines-selection-configuration-and-use-transport-layer-security-tls-0)
Also Microsoft has scheduled disabling these so this really should not be causing issues. Microsoft is known to support shit forever for convience:
Also to quote Microsoft again:
“The new TLS version also improves privacy by using a minimal set of cleartext protocol bits on the wire, which helps prevent protocol ossification and will facilitate the deployment of future TLS versions. In addition, in TLS 1.3, content length hiding is enabled by a minimal set of cleartext protocol bits. This means that less user information is visible on the network.”
Also you might find this article on NIST’ website about the visiblity differences in TLS1.3 interresting:
This is why I go as far as saying we probably should urge organisations to only support TLS 1.3. If you want to maximize privacy this is the way to go.
2 Likes
Which is fair, and on that note it’s worth noting “downgrade” attacks to plaintext really aren’t a thing anymore with MTA-STS policies set to enforce mode. We wouldn’t want an enforce policy being met with substandard encryption.
Fair point, and that’s not just enterprise customers.
As of October 31, 2018, the Transport Layer Security (TLS) 1.0 and 1.1 protocols are deprecated for the Microsoft 365 service. The effect for end-users is minimal. This change has been publicized for over two years, with the first public announcement made in December 2017. This article is only intended to cover the Office 365 local client in relation to the Office 365 service but can also apply to on-premises TLS issues with Office and Office Online Server/Office Web Apps.
Also worth noting that Gmail does not support TLS 1.0/1.1 either, nor does Yahoo on their primary servers.