Email relaying opportunistic encryption technologies #603
Labels
No Label
🔍🤖 Search Engines
approved
dependencies
duplicate
feedback wanted
high priority
I2P
iOS
low priority
OS
Self-contained networks
Social media
stale
streaming
todo
Tor
WIP
wontfix
XMPP
[m]
₿ cryptocurrency
ℹ️ help wanted
↔️ file sharing
⚙️ web extensions
✨ enhancement
❌ software removal
💬 discussion
🤖 Android
🐛 bug
💢 conflicting
📝 correction
🆘 critical
📧 email
🔒 file encryption
📁 file storage
🦊 Firefox
💻 hardware
🌐 hosting
🏠 housekeeping
🔐 password managers
🧰 productivity tools
🔎 research required
🌐 Social News Aggregators
🆕 software suggestion
👥 team chat
🔒 VPN
🌐 website issue
🚫 Windows
👁️ browsers
🖊️ digital notebooks
🗄️ DNS
🗨️ instant messaging (im)
🇦🇶 translations
No Milestone
No Assignees
1 Participants
No due date set.
Dependencies
No dependencies set.
Reference: privacyguides/privacytools.io#603
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
While most of us agree that PGP is the best way secure the contents of email, this sometimes is not possible and opportunistic TLS is still required to secure collection of email metadata when it is being relayed.
I think with our email table we should reward and try to motivate email providers (approach them) to adopt technologies which help secure transparently encryption between email servers and prevent downgrade attacks such as SPF, DKIM, DMARC, DNSSEC, DANE, MTA-STS RFC 8461 (September 2018) and SMTP TLS Reporting RFC 8460 (September 2018). We could reward them with a "gold, silver and bronze" star for adopting these technologies. For example for a Gold star everything would need to be supported (including both DANE and MTA-STS), we would have to determine the exact criteria still.
We should ultimately be encouraging these providers to join the StartTLS-Everywhere PolicyList run by the EFF. See their FAQ for more details.
Encryption Testing
testssl.sh --starttls smtp example.com | aha --black --title "(smtp) example.com:587" > smtp.example.com.htmlnmap --script ssl-enum-ciphers -p 465 example.comSPF/DKIM/DMARC
Some background:
Why you should use DANE and MTA-STS
Some Initial tests
https://www.hardenize.com/report/mailbox.org/1542685973
https://www.hardenize.com/report/protonmail.com/1542685980
https://www.hardenize.com/report/tutanota.com/1542685984
https://www.hardenize.com/report/disroot.org/1542685841
https://www.hardenize.com/report/posteo.de/1542685991
https://www.hardenize.com/report/mailfence.com/1542685995
https://www.hardenize.com/report/runbox.com/1542685998
https://www.hardenize.com/report/startmail.com/1542686000
https://www.hardenize.com/report/kolabnow.com/1542685876
https://www.hardenize.com/report/neomailbox.com/1548419015
Good idea.
The names could be something like "Great security", "Very good security", and "Good security". I suggest adding a reason behind each badge/star, explaining what's good/bad. Similar to how the
*is used here, but we'd use numbers.Ah yeah that wasn't literal, I hadn't really thought about the award would be called. But yes you're right.
Yes I will define that over the coming days here, then I'll approach each of them and ask if they're looking at improving things and let them know about the intention to add it to privacytools.io. At the moment none of them would probably get a gold star.
The RFCs for MTA-STS and TLS-RPT are still very new so these changes won't go in for a while and I want to let them have a reasonable amount of time to do it.
Edit from dngray: Remove "good" category, as we will only recommend great providers.
I think the preliminary categories will be and will be based on, domain security, SMTP encryption and authentication.
I have decided I think we should only have two categories, Good and Great. Something with 'poor' security should never be recommended and therefore should be removed.
Good and Great both require to be on the StartTLS-Everywhere Policy List, currently only mailfence.com, startmail.com and kolabnow.com are not but meet the requirements to be added.
Great
Domain Security:
SMTP:
Authentication and Policy:
No errors for the following:
pmay benone,quarantineorreject.Other TLS RFCs:
Must have a plan for:
Providers to be removed
No domain control
SMTP:
Opportunistic TLS failed Unforgivable errors include:
ECDH_anonorDH_anonNeither DANE or MTA-STS+TLS-RPT
Authentication and Policy:
Other TLS RFCs:
Other Warnings
We should also encourage them to make sure they have no security errors on their WWW. Many users access email via a web interface eg:
Application Security
Note I left off Expect-CT currently a draft.
Any feedback would be appreciated I'll begin contacting the providers in a week for their thoughts on this.
We can remove some but either way the ratings should be something like Good/Very good/Great as to not sound like we're recommending shitty providers.
Agreed.
Out of the providers we recommend I only use ProtonMail, so I don't know if we do this already, but we should only recommend providers with client-side encryption. Simply having SMTP TLS while claiming to encrypt things on the backend isn't good enough.
I have change it to "Good" and "Great" the "Providers to be Removed" list well those things I don't think are really negotiable. I shall wait to see what their input is on that.
Realistically I think the only providers that should get removed are the ones that have no plans to fix anything and don't want to talk to me about it. I would then be starting to look at them as unmaintained. Part of running an email provider is to stay current with the RFCs that the rest of the industry uses. This has primarily been the argument used against federated and decentralized protocols in the past but we all know the dangers of having everything centralized 😉. What I am hoping is that the providers realize that they are being compared against each other.
I don't believe this issue should be hurried as it may take time for them to implement some of these things (MTA-STS for example is new). They also may already have a timeline on when they want to do it with testing as some of these things require careful planning eg DNSSEC and DANE and can have pretty bad consequences if you 'do it wrong' ie The DANE fail list and DANE - Common Mistakes.
The unfortunate fact is PGP is really only good for protecting the contents of an email. Client-side encryption isn't always possible either and will often be disabled by users in a pragmatic world where they want a copy of the email to in the recipient's inbox and not a https link to the email.
There are two sides of the argument as well, regarding client-side encryption. Some say that JavaScript client-side encryption enhances the surface area hugely and a provider could serve you a faulty JavaScript applet which in turn sends them back an un-encrypted copy. The only way to really be certain of that is to make sure they are in countries where the law does not allow that kind of weakness (although some countries may do it anyway clandestinely). As a result of this some believe that E2E encryption should ONLY be available in mail clients ie things like Enigmail or clients that use OpenKeychain. Fortunately the AutoCrypt spec makes this much more user friendly.
As a result of this I decided to avoid this argument in this issue. No email provider can 'prevent' you from using PGP. Fastmail wrote a good piece about why they don't offer pgp, though they are not one of our providers listed for geographical reasons, they are however dead right in their reasoning.
Opportunistic TLS is the only way to protect the metadata which user is sending emails to whom (PGP doesn't encrypt that).
In the coming days I shall be reaching out to each one of the providers to get their thoughts on it. I am sure that privacytools.io has driven some customers towards them I am interested in their plans.
I have also asked Hardenize for a list of domains to whitelist so that some of the providers that are currently rate limiting can whitelist those domains.
True. Only a locally stored app, built from/hashchecked with a peer reviewed source would solve this.
There are many providers which are outside US and support SMTP TLS. I think the best metric to look at is implementation/willingness to implement more security features.
Another thing that I think we will add to the list is while not related to relaying I think is still very important the connection from the client to the MTA is just as important. We should encourage providers who provide STARTTLS only to support Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access RFC 8314 - January 2018.
Essentially port 25 being plain text SMTP, and 465 was supposed to be for SMTPS (explicit SSL/TLS). Anyway back in 1998 they decided to revoke that and go with STARTTLS on 587 which of course is susceptible to downgrade attacks.
Since then though providers like Gmail and others still did SMTPS on 465 despite IANA re-assigning the port. Now that RFC 8314 exists port 465 should be offered for SMTPS.
I observed 3 categories of providers, ones which do STARTTLS only(❌), ones which offer SMTPS(✔️) and ones which use some other secure method of connection(✔️).
SMTPS Support ✔️
STARTTLS Only ❌
Some other secure method ✔️
Another requirement we should add is an intent to deprecate and reject the use of TLS 1.0 and 1.1 in accordance to the current draft https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate that date should be no later than March 2020 or when that draft turns into an RFC (whichever comes first). That draft will be following the history of RFC6176 and RFC7568.
It should be noted at this point both gmail.com and outlook.com only allow TLS 1.2 for many of their relays.
Google also only allow the use of
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256while Outlook only allow the use ofTLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, both being really good options, it is interesting to see them not allow many other ciphers in the TLS 1.2 suite.On a side note, this is how it looks from the client submission side of things. I doubt any email servers would be running on software that is 7+ years old that are internet facing. That would be utterly irresponsible as none of that stack would be supported. Old antiquated systems would likely transmit to a modern relay before exiting the network and entering the wider Internet.
Browser support
Google has a specific criteria for the suite preferences which I think we should also adopt:
Hardenize does currently check for this.
All servers must also have a Server Suite Preference of TLS 1.2 or later defined.
Marketshare research
Looking at users that cannot do TLS 1.2 connections:
The University of Warwick in Coventry has disabled these protocols and provide some information about impact:
Some global statistics:
I'm going to update the Great/Good category to say that a DMARC policy must be included but may be not enforced ie
pmay benone,quarantineorreject. One of the providers has pointed out to me this causes issues with mailing lists.https://dmarc.org/wiki/FAQ#Is_there_special_handling_required_to_receive_DMARC_email_from_mailing_lists.3F
We may decide once arc-spec is finalized and turned into a RFC to revisit this.
https://en.wikipedia.org/wiki/Authenticated_Received_Chain
https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/
(Custom = means custom domain support)
[1] Rule exists, not enforced
[2] Custom software: https://tutanota.com/faq/#imap
[3] Reconfigure server to use forward secrecy and authenticated encryption
[5] Poor configuration, even allows for SSLv3 connections! Many bad, or broken ciphers supported!
[6] Waiting on support from Key-Systems
[7] Waiting on support from NS1 verification
[8] Respected on outgoing messages only
@tya99
I really appreciate the effort put into compiling this! Would it be possible to add client-side encryption to the table?
Do you mean end-to-end encryption like PGP?
The reason this is not added is because no provider "stops" you from using PGP.
I do recognize some decide to handle that server-side but that comes at the cost of giving those providers your private keys, and all the public keys in your keyring which really defeats the purpose of end-to-end encryption. I discussed this in the bottom of https://github.com/privacytoolsIO/privacytools.io/issues/603#issuecomment-440197954.
I don't feel we should penalize providers who refer users to installing a mail client that provides pgp encryption as opposed to offering it themselves.
The latter part of that message refers to legislation such as the Assistance and Access Bill that recently came into force in Australia. The specific part which is explained rather nicely in this article.
While we don't recommend any providers "in Australia" as they are a member of the Five Eyes it is only a matter of time until other countries follow suit and try to do something similar. If you look around the world, Europe included there has been a clear increase in adoption of authoritarianism.
If the provider has no ability to decrypt your messages because they do not hold the private keys, cannot serve up malicious code to steal them, then there's basically nothing they can do to "comply" with one of these orders. Hopefully this will stop/slow further degradation and chipping away at civil liberties if it will all be for nought anyway.
It would also seem that the security services are keen to exploit key distribution ie the GCHQ's "ghost participant" idea. https://www.justsecurity.org/62114/give-ghost-backdoor/
@tya99 Thank you for the reply, I should have been more specific. There are at least two different features that are useful, neither of which involve the vendor controlling the private key.
I do not agree that any of these things would be discouraging one from using client-side encryption as any other client-side PGP can clearly be used on top of it. The Mailbox.org feature seems particularly nonintrusive and useful.
Mailbox is the only one which has that option. They also have an option to email @secure.mailbox.org. When someone emails this alias TLS is mandatory. If the remote server is unable to initiate a TLS connection Mailbox won't let it fallover to an unencrypted connection.
ProtonMail has their custom bridge software which encrypts the mail before it is sent to the ProtonMail. It is only for paying customers.
Tutanota simply doesn't allow IMAP/SMTP and forces you to use their app, or use webmail. This would bother me if I wanted to make an cold storage backup. You can never really know if a provider is going to just "cease to exist".
Unfortunately there is no RFC besides RFC4880. The smaller providers don't provide this kind of encryption because it requires engineering specialized software which is expensive. I don't believe this is a good course at all and anything we recommend really should be an RFC. I do understand the source for Tutanota and parts of ProtonMail are open, but without being standardized and being heavily integrated with their other product it is unlikely anyone will adopt it.
These providers are marketing this software as a reason why you should pick them exclusively. The purpose of this research isn't to provide those providers with more customers. I believe that is dangerous and makes them a higher value target by state adversaries as it centralizes email. I think a better approach would be an engineered standard like what FastMail has done with JMAP or ARC.
At the moment Mailbox, Posteo and Disroot all support DANE, MTA-STS and TLS-RPT and would certainly be my top picks.
I would like to see Tutanota and ProtonMail at least support these. Tutanota only does DANE, which means that when you send email/receive email from Gmail/Outlook users it won't be able to make use of MTA-STS. As mentioned in this link in my original post, a provider really needs to do both.
At the end of this I will be providing a transparency score. Some providers have been very forthcoming with information, while others have been silent or provided nothing but the regular customer service "thank you for your inquiry, but we cannot provide any more information" spiel.
This was also an interesting read https://www.ctrl.blog/entry/protonmail-vs-mailbox
We have been talking to overhaul the email page and ad an criteria list like we did with the vpn page, this would most likely solve the issue.
Yes, I have just updated the table to include Soverin, they look to be a fairly good provider across the board from what I can see. Also it seems Protonmail has now deployed MTA-STS and TLS-RPT so that's good too.
It should be noted this now became finalized as of July 2019: https://tools.ietf.org/html/rfc8617
I think from now on we will start to see providers adopting this especially as Google is doing verification for their users.
Updated, looks like proton mail is now fully compliant with our best category. We've got quite a few now in there (5 providers).
@blacklight447-ptio @JonahAragon I like what you've done with the VPN section.
I think we should wait until March 2020 (in line with TLS 1.0 and 1.1 deprecation in main browsers) before publishing as that is a tentative date I told providers we would look at revising that section. Protonmail only recently upgraded their services, so it's possible others may follow suite soon too.
I am going to request an update from the mail providers and let them know we're thinking of shortening the list (like the VPN list) to just the ones which are now compliant. At the time of writing this number now stands at 5 different providers.
I am thinking we might add a bonus badge for providers that support JMAP now that the standards have been published RFC 8620 and RFC 8621.
Currently there's not much in the way of client support although I expect that to change now that the standards are finalized. K-9 has said that they are looking at implementing support soon https://github.com/k9mail/k-9/issues/3272#issuecomment-528326161 and hopefully Thunderbird will too https://bugzilla.mozilla.org/show_bug.cgi?id=1322991. I am quite curious myself how well JMAP support would work with ProtonMail's bridge, particularly in regard to the bandwidth usage.
Unfortunately nobody except for Fastmail supports JMAP and they operate in and from a FVEY country.
The The Authenticated Received Chain (ARC) Protocol also has gone into RFC status as RFC 8617. Many more providers have announced support for that, currently Google and Fastmail do verification for it. So we may provide an additional reward badge for providers that support this in the future too.
@tya99 would you perhaps want to collaborate with us on a PR for the mail section overhaul?
sure, seeing as I've done all the research/contact.
@tya99 excellent, I just wanted to make sure, as we can't go on expecting everyone to worm with/for us just because they open well informed issues :). In any case I'm glad that you want to help out.
@dngray will be handling this from here on out.