search

privacytools / privacytools.io

🛡🛠 You are being watched. Protect your privacy against global mass surveillance.
https://www.privacyguides.org
Creative Commons Zero v1.0 Universal
3.12k stars 384 forks source link

Email relaying opportunistic encryption technologies #603

Closed ghost closed 4 years ago

ghost commented 5 years ago

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

SPF/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

ghost commented 5 years ago

Good idea.

We could reward them with a "gold, silver and bronze" star for adopting these technologies.

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.

ghost commented 5 years ago

"gold, silver and bronze" star

Ah yeah that wasn't literal, I hadn't really thought about the award would be called. But yes you're right.

I suggest adding a reason behind each badge/star

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.

ghost commented 5 years ago

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:

Other TLS RFCs:

Must have a plan for:

Providers to be removed

No domain control

SMTP:

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.

ghost commented 5 years ago

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.

I think the preliminary categories will be and will be based on, domain security, SMTP encryption and authentication.

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.

ghost commented 5 years ago

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.

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.

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.

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.

ghost commented 5 years ago

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.

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.

ghost commented 5 years ago

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 ✔️

Port 465 was only officially designated a secured port for mail submission (SMTPS) for a short period, and it is now considered a “legacy” port. Although many email programs and email services (like Runbox) support mail submission on port 465 using TLS/SSL, it is not officially designated for that any longer, and so sometimes compatibility may be an issue or you may find it referred to as a “legacy” port.

STARTTLS Only ❌

Some other secure method ✔️

ghost commented 5 years ago

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_SHA256 while Outlook only allow the use of TLS_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

Vendor TLS 1.0 Removal TLS 1.1 Removal
Apple March 2020 March 2020
Google January 2020 January 2020
Microsoft first half of 2020 first half of 2020
Mozilla March 2020 March 2020
PCI-DSS 30 June 2018 Not specified - though they prefer 1.2

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:

ghost commented 5 years ago

I'm going to update the Great/Good category to say that a DMARC policy must be included but may be not enforced ie p may be none, quarantine or reject. 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/

ghost commented 5 years ago
Provider (link on Hardenize) Response (Email/Ticket) DNSSEC CAA TLS Errors MTA-STS TLS-RPT DANE DANE (Custom) DKIM DKIM (Custom) DMARC Server Suite Pref. SMTPS Support Date for Deprecate TLSv1.0 & TLS 1.1
mailbox.org ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️[1] Able to be changed by customer for their domains ✔️ ✔️ ✔️ (disabled on web)
soverin.net ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ❓ ✔️ ✔️ Yes ✔️ ✔️ ✔️ Yes ✔️ (disabled on web)
protonmail.com ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ❓ ✔️ Yes ✔️ ✔️ ✔️ ✔️
tutanota.com ✔️ ✔️ ❌ https://github.com/tutao/tutanota/issues/898 ✔️ ❌ https://github.com/tutao/tutanota/issues/461 ❌ https://github.com/tutao/tutanota/issues/899 ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️[2] ✔️ (disabled on web)
disroot.org ✔️ ✔️ ❌[6] ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️[1] ✔️ ✔️ ❌
posteo.de ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ❌ No ✔️ ✔️ Yes ✔️[1] ✔️ ✔️ ✔️
mailfence.com ✔️ ❌ ✔️ ✔️ ✔️ ✔️ ❌ ✔️ ✔️ ✔️ ✔️ ✔️ (disabled on web)
runbox.com ✔️ ❌ ❌ ❌[3] ✔️ ❌ ❌ ✔️ ✔️ ✔️[1] ❌ ✔️ ✔️
startmail.com ✔️ ✔️ ✔️ ✔️ ✔️ ✔️ ❌ [7][8] ✔️ ✔️ ✔️[1] ✔️ ✔️ ✔️ (disabled on web)
kolabnow.com ✔️ ✔️ ✔️ ✔️ ❌ ❌ ✔️ ✔️ Yes, signed as kolabnow.com ✔️ ✔️ ❌ ✔️
neomailbox.com ✔️ ❌ ❌ ❌[5] ❌ ❌ ❌ ❌ ❌ ❌ ❌ ❌ ✔️

(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

lucassz commented 5 years ago

@tya99

I really appreciate the effort put into compiling this! Would it be possible to add client-side encryption to the table?

ghost commented 5 years ago

@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.

  • Technical Assistance Notices (TAN), which are compulsory notices for a "designated communication provider" to use an interception capability they already have;
  • Technical Capability Notices (TCN), which are compulsory notices for a designated communication provider to build a new interception capability, so that it can meet subsequent Technical Assistance Notices; and
  • Technical Assistance Requests (TAR), which are "voluntary" requests, but which have been described by experts as the most dangerous of the three because there was less oversight, at least in the original version of the law.

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/

lucassz commented 5 years ago

@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.

ghost commented 5 years ago
  • Encrypting non-encrypted messages' content with the user's public key and then storing them in that form. Obviously, it's not possible to verify that the email provider actually deleted the unencrypted version, but having the feature is far better than not having it. Mailbox.org is an example of a provider with this feature.

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.

  • Fully encrypting all emails' metadata, content, etc. with the user's public key, again claiming not to store the unencrypted version. I believe that Tutanota and ProtonMail both do this.

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.

ghost commented 5 years ago

This was also an interesting read https://www.ctrl.blog/entry/protonmail-vs-mailbox

blacklight447 commented 5 years ago

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.

ghost commented 5 years ago

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.

ghost commented 5 years ago

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/

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.

ghost commented 5 years ago

Updated, looks like proton mail is now fully compliant with our best category. We've got quite a few now in there (5 providers).

ghost commented 5 years ago

@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.

blacklight447 commented 5 years ago

@tya99 would you perhaps want to collaborate with us on a PR for the mail section overhaul?

ghost commented 5 years ago

@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.

blacklight447 commented 5 years ago

@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.

ghost commented 4 years ago

@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.

@dngray will be handling this from here on out.