You could apply the same point to any piece of software exposed to the Internet. I don't see how one vuln makes you think we should start sending everything in plaintext again.
(Full disclosure: my startup surrounds certificates and PKI)
Similar vulnerabilities to heartbleed could exist in TCP stacks and mail servers, revealing the contents of unencrypted mail.
The reason encrypting things is nice is that it reduces the attack surface. You only have to protect your email at the point of consumption. Taken to extremes, if PGP were ubiquitous then your IMAP account wouldn't need to have a password.
I generally agree with tedu that OpenSSL and other TLS software should be used with great care, and not deployed without an understanding of the attack surface it adds. However, my approach to this problem seems to be different, at least based on this blog post.
tedu: TLS/PGP/GPG software is a minefield, so don't use it everywhere.
me: TLS/PGP/GPG software is a minefield, so let's investigate alternatives. Either something will stick, or TLS/PGP/GPG will be pressured to substantially improve. Or both.
I think tedu may agree with me because he's involved in signify, an OpenBSD tool to cryptographically sign/verify files, and reop, an alternative to OpenPGP software like GnuPG.
Maybe some things should be hard, to remind us that they are important.
This is pretty much where I come down on the issue. I don't really care if anyone reads my email 99.5% of the time. I know it's not very secure, so I don't use it for communicating anything I care too much about. Encyrpting all my email strikes me as about as sensible as using a one-time pad to encrypt postcards I send when I'm on vacation.
If I need to PGP something, I use the command line to create an ascii-armored version of the message and I copy/paste it into the email. I don't integrate PGP with my email client, even though that option is available to me. For the few times a year I need to deal with encrypted email, it's just not worth it.
The problem with that approach - encrypt only things you need - is that it signals to the adversaries (whoever they are) that this is the piece of data they should try to get. By encrypting everything, you make the adversaries spend enormous resources just trying to figure out which data is worth spending resources on.
But I honestly don't know which approach is better in lieu of TFA; however I'm leaning towards encrypting (almost?) everything.
P.S. Someone above me mentioned, bugs and complexity only get noticed and fixed if there are enough people using encryption, and I think that's a great point too.
There are bugs in the standards and bugs in the implementations. Enabling them exposes a great deal more attack surface to the internet at large. Worst case scenario: net security negative.
I don't understand what would make someone think that possibly-compromised security is worse than no security.
Possibly-compromised security has the potential in this case to mean your computer gets taken over and starts performing DDoS attacks at the behest of organised crime groups. No security means that some of your email may be read.
That is a false sense of / misunderstanding of what security is. Security is not yes/no, I am secure or not. It is a gradient. Gradient of risk vs cost.
You are never 100% secure. And probably don't want to be even that close to 100% (cost being too great).
If you simply read his essay, there are actual real world instances of being worse off because of using encryption. This isn't some super-theoretical navel-gazing going on: it actually happened, multiple times.
I have never received an encrypted spam (that would be one of the four horsemen, right?) but you can filter very effectively without knowing the contents of the message, just going off the headers and reputation of the sender.
I don't think I understood the other half of the article.
We shouldn't even allow the intelligence community to know who is talking to each other, or who is talking secretly. We should give cover to legitimate secrecy (political dissent for example) through our collective encrypted babble.
Please do encrypt all the things. It may take some more years of engineering to lock things down to the extent a new HeartBleed isn't always happening, but it's worth the effort.
One citizen's lolcats should look just like another citizen's rebellion.
Well put. How can anyone talk about rebellion when consequence could be torture/death. The internet provides a great communication medium and anti-propaganda anti-censorship mechanisms. Encryption and misdirection is key.
For what it's worth, I had to use https: to check that from my phone because my provider uses a HTTP transparent proxy (otherwise known as a man-in-the-middle!) - and it's down. (How very unfortunate. Perhaps it should know better than to try and parse my traffic.) And you had a certificate signed by your own CA, and that's no real bother when the link was http: in the first place. I was only able to read your blog because you used OE. Poetic.
But I know that every connection I make, GCHQ is a passive MITM on at least one hop. That's more pervasive than a coffee-shop Wifi - and they can inject things into plaintext traffic, too.
You think DANE's going to be a problem? I don't think so. It's at least as good as domain-validated certs with a CA - which isn't very good, but it's a reasonable minimum. It helps with pinning.
In 1962 Time magazine printed a version of the quotation credited to Einstein in “A Letter From The Publisher.” The phrasing used is still distinct from the common modern version [AETM]:
In fields of specialized knowledge, we aim to render an account that is plain and simple, yet does no violence to the difficulty of the subject, so that the uninformed reader can understand us while the expert cannot fault us. We try to keep in mind a saying attributed to Einstein that everything must be made as simple as possible, but not one bit simpler.
Also, side channel attacks are hard, so let's just use plaintext.
reply