You’re in control of publishing your public key, not the email provider.
I’d be remiss if I didn’t tell you how bad MTA-STS is:
* MTA-STS: compromise for the DNSSEC-challenged
* Still can and should prefer DANE outbound
* Authenticates domain control via CA leap of faith
* Vulnerable to MiTM at cert bootstrap
* Vulnerable to weakest root CA, and unauthorized certs
* Open to downgrade on first (or irregular) contact
* Complex mix of HTTPS, unsigned DNS and SMTPThis is only true if you personally fully own the domain and have control of the DNS and other services, which is not the case for the utter majority (at least 99.9%, maybe a few more 9s) of the population. Of course, in that case, you are pretty much the email provider, so not trusting the email provider is a pretty questionable scenario at that point.
> MTA-STS: compromise for the DNSSEC-challenged
Yeah... DNSSEC is a classic example of a solution looking for a problem. Most of your criticism would apply equally well to not using DANE for TLS, and every browser vendor has looked at it and decided against it because it adds no security.
Right now, DANE is the only way to mitigate downgrade attacks with SMTP and TLS connections. Apparently use of DANE for email is growing [1].
DANE hasn’t taken off with browser vendors because of their concern about additional DNS lookups when making TLS connections.
[1]: “Number of DANE-enabled mail domains growing exponentially”—https://www.sidn.nl/en/news-and-blogs/number-of-dane-enabled...
And right from the MTA-STS RFC: https://www.rfc-editor.org/rfc/rfc8461.html#section-2
the mechanism described here instead relies on certification authorities (CAs) and does not require DNSSEC, at a cost of risking malicious downgrades.
So there’s that.
PGP and S/MIME do. The latter is used for all sorts of official messages for exactly that reason.
Unauthenticated encryption is rather worthless. Repudiation is a separate matter and threat model.
How so?
Mind you, unauthenticated encryption in terms of signal does not mean that anyone can forge a message, rather that you can't prove to a 3rd party that this was a message sent by the sender rather than forged by you.
b) I'm my own email provider, but I don't trust my server provider (they could read HDD of my server), for example. Or my recipient's provider.
Because I've been using that method for close to 15 years now?
If you mean FTPS (which I suspect you do as I actually had to set up something similar at one time), that's FTP over SSL and has nothing to do with SSH.
Your point still stands though: some of the background "FTP a CSV file with a cronjob" crap that goes on in the background would horrify anyone.
It's also a counterpoint to one of the OP's points which is that trying to secure email is a dead-end that we should give up on. It may be possible, though very difficult, to transition to secure email. But it would have to be a brand new protocol not tacked-on to the current system. The way that SFTP is the appropriate upgrade path for FTP and not FTPS.
A new e2e protocol that works just like email does would be excellent, but we don't yet have that. Signal &co are chat apps with a different feel and purpose and other than matrix and xmpp not federated, which is a non starter for many entities.
There are some things we could easily give up to get encrypted mail. For example, setting a max delivery time to allow ephemeral keys.
But there are other problems with encrypted messaging, and I'm particularly thinking of spam. How does Signal/WhatsApp manage to keep a lid on it? Would that be possible in a federated system?
It is not. Unencrypted is environmental pollution that need to be actively prevent until it reach zero use. A favorable future is one where the firewall blocks any unencrypted traffic by default.
Similar, giving third party clear text copies of private information is not secure. It is never going to be secure, and the only half working solution there is the kind of heavy legal regulations and systems that does not exist anywhere yet.
If people want to debate over which end-to-end encryption scheme is best then they can do so as much they want, but in the end the goal here is to stop plain text from continuing harming people.
Email is protected with TLS on all every hop if your provider is competent. My point is that this protection is sufficient for most purposes. Where it is not sufficient, email encryption doesn't actually add the protection you probably wanted (this is the what the original article is detailing).
Project like freedom box could make email encryption obsolete, but thats not because unencryption would be secure enough. It would be because the encryption would be moved away from the individual email and onto the whole server.
Because Gmail does all of those things, and spends more money and effort making sure they do it correctly than you will over your lifetime.
If you have secrets where you believe that, say, a government will extrajudicially lean on Google to access them, theres am equally, or even higher likelihood that you misconfigured something somewhere and leaked your data.
Giving google a plain text copy of everything you say in private communication is not good enough security. Anyone working with information that is covered under privacy laws should be held legal responsible for disclosing it to a third party, regardless if that third party is google or a friend at a bar. If it is a doctor, lawyer or government employee the probability of this is close to 100%. If its a company talking to customers, communicating personal data as defined by the EU between employees, there is only a google breach away from being found out and sued.
The only choice is encryption, with the choice between a encrypted server under the control of the person responsible for keeping the information safe, or encryption per email. Which of those two choices one choose does not matter but giving google a plain text copy and calling it safe is just LARP security.
I should mention that here in Sweden there were recently a large political scandal involving the government using IBM as a third party service provider. Sensitive data got sent over the border and outside the control of the government, and it continued for years as those in charged really wanted to believe that "the cloud" could treated as just as secure as running your own servers. The law said otherwise, and when reality came crashing down things had to change. Convenience does not make it suddenly acceptable to give a third party sensitive information, even if that third party is a large international operator who can't do any wrongs.
Using gmail without encryption in those cases is a security issue and also illegal. A lot of people still use gmail in those cases and google track record in regard to data leaks has meant that few people have been found out. That said it will only take one significant data leak and people will start to dig for all data being sent to google. That day a lot of peoples head will roll.
I would guess without exaggeration that a large enough data leak at gmail would cause a global market crash. There is just too much plain text data containing sensitive information that people would dig into. Not private, not meta, just information which people should not have given to a third party. Google privacy policy does not play a role in that.
Then PGP is irrelevant, you don't email that data around. And even if you are, then you aren't dealing with security, you're dealing with compliance, compliance with legal obligations has nothing to do with, and is often in direct action against, actual security.
> Using gmail without encryption in those cases is a security issue and illegal.
This, almost certainly, isn't true, given that Gmail is a GDPR compliant store. You might need to use enterprise gmail, for the legal requirements, but that's still entirely beside the point. "Use enterprise Gmail" is the solution here, not "fail to use PGP".
Enterprise Gmail is able to operate as a data processor, but there is a lot of fine details in order to stay within the law. It assumes that the company has agreed to the gmail processing terms and gotten permission from their own customer to process the data in such ways. Again here we hope that op security match the fine line between legal and illegal. (If we want a practical example which I know people do, imagine a administrator of a CRM sending a copy of the database to a new hosting provider. Now a copy of the database exist in the sent folder and an other copy at the email provider that the hosting company use. It is very doubtful that GDPR allows that kind of sharing of the private information. If the file get leaked in a data breach there is high probability of a successful lawsuit for mishandling of the information).
Using your own email server or tools that automatically encrypt everything does however prevent those risks.
It sounds like you're talking about encryption at rest, in which case Gmail does that already, more securely than whatever you're doing so the backwards approach to compliance is more effort and less secure in practice.
I wrote a program to do that, but there is also a package in Debian if I recall right that also do it. On the mail server it looks up keys in DNS and if it founds it, automatically encrypts outgoing email.
> talking about encryption at rest, in which case Gmail does that already
Emails at google is not encrypted. Good must have access to the plain text in order to do analytics and search. If google has a data breach it can include every single email gmail has in plain text, and that is a fundamental risk.
> more securely than whatever you're doing
That is kind of impolite to make assumption about my own setup. It is also wrong.
So you're not talking about pgp/e2ee, you're talking about, like, SMIME or something.
> Emails at google is not encrypted.
They're at least as encrypted as they are on your server from what you've told me.
> That is kind of impolite to make assumption about my own setup.
Given that you don't seem to understand the difference between end to end encryption, in transit encryption, and encryption at rest, I'm going to say that no, I'm very confident that you haven't done this correctly.
> It is also wrong.
And that therefore no, gmail and Outlook are both more secure than your email server.
Basic 101 security. In order to calculate risk you take the risk threats minus risk mitigation. The bigger the threat, or the fewer the risk mitigations are, the bigger the risk.
You might have forgotten that in 2010 there was this data leak called cablegate. NSA lost 251,287 diplomatic messages. NSA did store them on an encrypted server, and used transit encryption, and yet the data leaked. A major risk to data security is access, and in that case an administrator with access leaked it.
With my mail server, that administrator is me. One of the larger benefits of personal servers.
When you compare Gmail and my mails server then you include social risk just as much as technical risk. You compare the physical risk, that is servers located in multiple places on the earth. You compare the political risk of a single entity that control 80% of the world email with a private email address used by one person. you compare targeted attacks with passive and optimistic attacks.
Lets put money where out mouths are. Want to bet that google will have a new data leak before I do? Looks like a very lucrative bet to me.
In 2018 Google had a data breach. five million user's data was compromised. In 2018 I had zero data breaches in any of my servers. Zero users data was compromised. I have been running my own server for almost 20 years and not a single bit has been lost.
Have I Been Pwned? has billions of leaked accounts, not a single which belongs to me. What about you?
> So you're not talking about pgp/e2ee, you're talking about, like, SMIME or something.
No. There are RFC for email security written in this century. The adaption of putting pgp keys in dns is not great however which is why personal email servers is currently better, but both solution works fine either way as long both side of the conversation does it.
Ah I see, so you aren't actually worried about security, you're worried about privacy. Which We've been over when I said:
> Privacy is not security.
You also are ignoring a whole host of other risks, like data loss (your one server breaks, oops there goes your all of your email, etc.)
> Lets put money where out mouths are. Want to bet that google will have a new data leak before I do? Looks like a very lucrative bet to me.
Sure, I'll bet you $10,000 that my email will not be leaked before yours. Here's what we'll do, I'll tell you my email address, and you tell me yours. Mine is @gmail. Yours is hosted on your server. I'll then turn around and spend $8000 on a pen-test of your server, they'll exfiltrate data, and I'll win the bet and be up an easy $2,000.
> In 2018 Google had a data breach
Pause, hold on. No. In 2018, Google announced that there was a vulnerability that could allow semi-public information to be shared more widely than intended (literally it was things like name and phone number that you put on your G+ profile being shared with a wider than intended audience).
There was no evidence that this vulnerability had been used, and Google's own employees detected it.
> In 2018 I had zero data breaches in any of my servers
that you detected. Here, Google has a better track record than you: they are actively monitoring and red-teaming their own servers and systems to detect vulnerabilities. Do you?
So I'll put it bluntly one more time: you are putting your clients data at more risk by administrating your own mailserver than you would be if you let Google or MS do it for you. You can try to come up with all the counterarguments you want, but they are, as this article puts, security LARPing, not actual security best practices.
In the end, if you have your email leaked while I do not then that is what matters. Results. I have had zero leaked accounts. Most people have stuff that been leaked, and since you refused to answer, I assume you are listed in Have I Been Pwned?. You trusted someone to be secure and they were not. That was your choice, and it was the wrong one.
If you break the law however, which is what happens if a pen test a system without permission, then it doesn't really matter if you hack or use rubber hose tactics. Breaking the law is breaking the law. The police don't look kindly to bets under those situations.
I will also say the same thing I wrote to those two pen testers that tested our system. If you find any vulnerability I will happy help write the CVE report. What I did not tell them but will mention here is that I also happy take part in getting those bug hunting reward money that zero days exploits usually rewards. If you have for example a working exploit against current stable release of latest SSH then I am sure we can turn that in somewhere for a pretty good amount of money.
In any sane setup, your (and your recipient's) email client will use encrypted connections to and from your respective email servers. Any competent email provider will use MTA-STS, ensuring that no one but the sender, receiver, and respective MTAs can read the message [1]. All this happens for regular unencrypted email, without any effort on the user's part.
So encrypted email purports to drop the ability to allow the MTAs to read the email. But... they don't really do that. Your email providers are required to MITM all of your email, and can trivially modify any plaintext attribute they want to. And anyone who has credentials to your email account can also trivially MITM all incoming email (and may be able to at least social engineer outgoing email, if not MITM as well). This means that pretty much any key discovery mechanism that allows an unencrypted email to initialize or update a public key is defeated [2].
So, encrypted email only provides extra security in those cases where: a) keys are negotiated completely external to email (in which case, why bother with email?), or b) you trust the email provider enough to not try to intercept your messages but not enough to not look at your messages without your permission. Given the BOFH principle (i.e., administrators have no inclination to look at your email because you're boring), that kind of means the second case doesn't really exist as a practical concern. You can improve your security in the second case simply be deleting emails from the server immediately, again not requiring encrypted email.
So... why bother with encrypted email? Unencrypted is secure enough unless you're paranoid, and if you're more than very slightly paranoid, encrypted email isn't secure enough.
[1] This is all happening via TLS, which has gone far, far further than PGP or S/MIME have in actually making "no one can read encrypted text" true. The latter protocols take the stance that "using the cipher.encrypt() is good enough," which has been known to be false for decades.
[2] And DANE-PGP is right out, because your email provider is of course the one publishing your public key.