# Minimum TLS requirements (for Email Providers) **URL:** https://discuss.privacyguides.net/t/minimum-tls-requirements-for-email-providers/11830 **Category:** Site Development **Created:** 2023-02-16T15:25:38Z **Posts:** 38 ## Post 1 by @ph00lt0 — 2023-02-16T15:25:38Z > [@Relaxing Email TLS Requirements on SMTP Port 25](https://discuss.privacyguides.net/t/relaxing-email-tls-requirements-on-smtp-port-25/1938/2): > > > - A server suite preference of TLS 1.2 or later and a plan for [Deprecating TLSv1.0 and TLSv1.1](https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/). 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. --- ## Post 2 by @jonah — 2023-02-16T15:38:39Z > [@ph00lt0](#): > > This can be prone to downgrade attacks in the network! 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. --- ## Post 3 by @ph00lt0 — 2023-02-16T15:39:44Z 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) --- ## Post 4 by @ph00lt0 — 2023-02-16T15:42:27Z Some good info on this: > **[IT Security Guidelines for Transport Layer Security (TLS)](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1)** > > These guidelines are intended to aid during procurement, set-up and review of configurations of the Transport Layer Security protocol (TLS). TLS is the most popular protocol to secure connections on the Internet. An updated version of the Security... Also from UK NSCS: > **[Using TLS to protect data](https://www.ncsc.gov.uk/guidance/using-tls-to-protect-data)** > > Recommended profiles to securely configure TLS for the most common versions and scenarios, with additional guidance for managing older versions. TLDR: do not use anything below 1.2 --- ## Post 5 by @ph00lt0 — 2023-02-16T15:44:12Z 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. --- ## Post 6 by @jonah — 2023-02-16T15:48:34Z 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. --- ## Post 7 by @ph00lt0 — 2023-02-16T15:49:59Z 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_SHA384` in 1.3) [1.2] - `ECDHE-ECDSA-CHACHA20-POLY1305` (`TLS_CHACHA20_POLY1305_SHA256` in 1.3) [1.2] - `ECDHE-ECDSA-AES128-GCM-SHA256` (`TLS_AES_128_GCM_SHA256` in 1.3) [1.2] - `ECDHE-RSA-AES256-GCM-SHA384` (`TLS_AES_256_GCM_SHA384` in 1.3) [1.2] - `ECDHE-RSA-CHACHA20-POLY1305` (`TLS_CHACHA20_POLY1305_SHA256` in 1.3) [1.2] - `ECDHE-RSA-AES128-GCM-SHA256` (`TLS_AES_128_GCM_SHA256` in 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. --- ## Post 8 by @ph00lt0 — 2023-02-16T15:52:32Z Protonmail does: > **[Email test: protonmail.com](https://internet.nl/mail/protonmail.com/869720/)** > > Test for modern Internet Standards IPv6, DNSSEC, HTTPS, HSTS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI and security.txt --- ## Post 9 by @jonah — 2023-02-16T15:54:52Z ProtonMail appears to be the only provider enforcing this on port 25. [Mailbox.org](http://Mailbox.org) [appears to support TLS 1.0/1.1](https://www.hardenize.com/report/mailbox.org/1676447783#email_tls) even though [they say they shouldn’t as of 2020](https://mailbox.org/en/post/security-adjustment-and-deactivation-of-certain-mail-functions). Tutanota [appears to support TLS 1.0/1.1](https://www.hardenize.com/report/tutanota.com/1676464069#email_tls) even though [they say they shouldn’t as of 2019](https://github.com/tutao/tutanota/issues/1008). Startmail [appears to support TLS 1.0/1.1](https://www.hardenize.com/report/startmail.com/1676562253#email_tls), 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? --- ## Post 10 by @ph00lt0 — 2023-02-16T15:56:45Z I am actually surprised by this a lot. This really ain’t smart. I wonder why they have not tbh. --- ## Post 11 by @dngray — 2023-02-16T15:57:37Z > [@jonah](#): > > @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? Could do that, sure. --- ## Post 12 by @jonah — 2023-02-16T15:59:43Z Also, SimpleLogin [supports TLS 1.1 but not TLS 1.0](https://www.hardenize.com/report/8shield.net/1676562604#email_tls), and AnonAddy only [supports TLS 1.2 and above](https://www.hardenize.com/report/anonaddy.me/1676563109#email_tls). --- ## Post 13 by @ph00lt0 — 2023-02-16T16:00:40Z 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. --- ## Post 14 by @ph00lt0 — 2023-02-19T09:02:34Z 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: > **[Website test: tutanota.com](https://internet.nl/site/tutanota.com/1936462/)** > > Test for modern Internet Standards IPv6, DNSSEC, HTTPS, HSTS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI and security.txt Did you hear anything from them @dngray ? --- ## Post 15 by @dngray — 2023-02-19T09:28:27Z > [@ph00lt0](#): > > Did you hear anything from them @dngray ? Waiting to hear back from [Mailbox.org](http://Mailbox.org) and Startmail --- ## Post 16 by @matchboxbananasynergy — 2023-02-20T23:33:52Z > [@ph00lt0](#): > > Please kindly note that we acknowledge your remarks and our team will try to update it in a future update. 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… --- ## Post 17 by @ph00lt0 — 2023-02-21T09:47:37Z Agreed, but I asked them to forward it to SL so it makes sense. --- ## Post 18 by @dngray — 2023-02-28T14:59:43Z Received a reply from [Mailbox.org](http://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. > [Ensuring E-Mails are Sent Securely | Knowledge Base](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](https://github.com/privacyguides/privacyguides.org/pull/1117#issuecomment-1112307064) (although they are working on a PGP based inbox encryption like [Mailbox.org](http://Mailbox.org) have). [Mailfence](https://github.com/privacytools/privacytools.io/issues/1908#issuecomment-627154266) 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](https://en.wikipedia.org/wiki/Hushmail#Compromises_to_email_privacy) encryption. This would also allow us to address [StartMail: Add a warning explaining drawbacks of the User Vault · Issue #1433 · privacyguides/privacyguides.org · GitHub](https://github.com/privacyguides/privacyguides.org/issues/1433) which a user in our community has already picked up. --- ## Post 19 by @ph00lt0 — 2023-02-28T15:11:46Z > 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. ([Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations | NIST](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: > **[Disabling TLS 1.0 and 1.1 for Microsoft 365](https://learn.microsoft.com/en-us/microsoft-365/compliance/tls-1.0-and-1.1-deprecation-for-office-365?view=o365-worldwide)** > > Describes TLS 1.0 and 1.1 deprecation and disablement for Microsoft 365. 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.” - [https://www.microsoft.com/en-us/security/blog/2020/08/20/taking-transport-layer-security-tls-to-the-next-level-with-tls-1-3/](https://www.microsoft.com/en-us/security/blog/2020/08/20/taking-transport-layer-security-tls-to-the-next-level-with-tls-1-3/) Also you might find this article on NIST’ website about the visiblity differences in TLS1.3 interresting: > **[Addressing Visibility Challenges with TLS 1.3 | CSRC](https://csrc.nist.gov/News/2021/addressing-visibility-challenges-with-tls-1-3)** > > The NCCoE is requesting comments on a new Draft Project Description, 'Addressing Visibility Challenges with TLS 1.3.' Public comments may be submitted through March 29, 2021. 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. --- ## Post 20 by @dngray — 2023-02-28T15:28:20Z > [@ph00lt0](#): > > 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. 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. > [@ph00lt0](#): > > “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.” 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](https://www.hardenize.com/report/gmail.com/1677571816#email_tls) either, [nor does Yahoo](https://www.hardenize.com/report/yahoo.com/1677564433#email_tls) on their primary servers. --- ## Post 21 by @jonah — 2023-02-28T15:30:58Z I agree with removing Startmail. Adding automatic incoming PGP encryption like what [Mailbox.org](http://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. --- ## Post 22 by @ph00lt0 — 2023-02-28T15:38:33Z I do actually believe downgrade attacks are still a thing. As I also DMed you China blocks TLS1.3 ([https://www.zdnet.com/article/china-is-now-blocking-all-encrypted-https-traffic-using-tls-1-3-and-esni/](https://www.zdnet.com/article/china-is-now-blocking-all-encrypted-https-traffic-using-tls-1-3-and-esni/)) 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. --- ## Post 23 by @dngray — 2023-02-28T15:44:27Z 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/](https://www.zdnet.com/article/russia-wants-to-ban-the-use-of-secure-protocols-such-as-tls-1-3-doh-dot-esni/) --- ## Post 24 by @dngray — 2023-03-02T07:33:09Z So I pointed out to [Mailbox.org](http://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](http://secure.mailbox.org) domain [does not support TLS 1.3](https://www.hardenize.com/report/secure.mailbox.org/1677741880#email_tls) 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](https://datatracker.ietf.org/doc/rfc8996/). 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](http://mailbox.org) due to the fact they have a PGP implementation that does not require them [holding the private key encrypted or otherwise](https://kb.mailbox.org/en/private/e-mail-article/your-encrypted-mailbox). 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. --- ## Post 25 by @ph00lt0 — 2023-03-02T07:35:56Z 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. --- ## Post 26 by @dngray — 2023-03-02T07:38:46Z 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”. --- ## Post 28 by @dngray — 2023-03-04T06:07:44Z > [@ph00lt0](#): > > Tutanota has removed the outdated TLS support now: Are you [sure about that](https://www.hardenize.com/report/tutanota.com/1677909817#email_tls)? or is it that they said they were going to? > [@matchboxbananasynergy](#): > > That sounds like a very canned reply from a support representative who likely has little to no idea what’s being discussed. I think so. --- ## Post 29 by @dngray — 2023-03-04T06:20:09Z So I did get another reply from [Mailbox.org](http://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](http://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](http://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. --- ## Post 30 by @ph00lt0 — 2023-03-04T10:07:24Z 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. --- ## Post 31 by @dngray — 2023-03-30T14:28:24Z > [@dngray](#): > > Their [secure.mailbox.org](http://secure.mailbox.org) domain [does not support TLS 1.2 and 1.3](https://www.hardenize.com/report/secure.mailbox.org/1677741880#email_tls) only 1.2. It seems that Hardenize isn’t entirely reliable. I was able to see that it had TLS v1.3 with [testssh.sh](https://testssl.sh/), [drwetter/testssl](https://github.com/drwetter/testssl.sh). You can run the command and export to a nice HTML document using [`aha`](https://github.com/theZiz/aha). Ie: ``` ❯ ./testssl.sh --starttls smtp mx.example.com:25 | aha --black --title mx.example.com > mx_example.html ``` [https://0x0.st/HHoz.html](https://0x0.st/HHoz.html) [https://0x0.st/HHo-.html](https://0x0.st/HHo-.html) [https://0x0.st/HHoo.html](https://0x0.st/HHoo.html) [https://0x0.st/HHoH.html](https://0x0.st/HHoH.html) [https://0x0.st/HHoX.html](https://0x0.st/HHoX.html) --- ## Post 32 by @ph00lt0 — 2023-03-30T14:37:27Z 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. > **[Website test: mailbox.org](https://internet.nl/site/mailbox.org/2010707/#control-panel-11)** > > Test for modern Internet Standards IPv6, DNSSEC, HTTPS, HSTS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI and security.txt --- ## Post 33 by @RiQuY — 2023-06-20T17:13:54Z 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? --- ## Post 34 by @emailgeek — 2023-06-20T20:50:40Z Hey @dngray! I work for Hardenize’s [parent company](https://www.hardenize.com/blog/hardenize-joining-redsift). 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). --- ## Post 35 by @jonah — 2023-06-20T22:57:15Z > [@RiQuY](#): > > Does that means that mailboxorg will be deleted from the recommendation list too because of the lack of zero-knowledge-encryption? 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](http://mailbox.org)’s. --- ## Post 36 by @Laitinlok — 2023-06-21T02:17:30Z I do not recommend aes-128-cbc in general --- ## Post 37 by @jonah — 2023-06-21T17:37:04Z A post was split to a new topic: [Disroot Email](/t/disroot-email/12966) --- ## Post 38 by @dngray — 2023-06-21T08:50:19Z Awesome, sorry I forgot to report this I was meaning to.