Hacker News Reader

Comment by computer | Hacker News Reader

It wouldn't be resilient to interception of mail going to and coming from lavabit however, since email is essentially a plaintext public protocol.

View on HN

This is somewhat true. RFC3207[1] describes opportunistic TLS encryption for SMTP communications. Our postfix deployment uses this and a fair amount of our email is sent over TLS-encrypted SMTP.

Of course, an MITM attack could hide the STARTTLS option and there are questions around the strength of the CA cert infrastructure, but SMTP is not just plaintext.

[1] https://tools.ietf.org/html/rfc3207

The problem is that you don't sent to the destination SMTP server. You send to your SMTP server. That goes at least one hop via SMTP and eventually ends up on the destination's domain server.

So even if I setup and host my own SMTP server, and even if I verify the TLS certs on my side, I have no way to verify that I'll get (1) A TLS connection (2) with an authenticated cert all the way to the ultimate destination.

It's beyond my control to ensure that I'm secured when emailing to an arbitrary domain with arbitrary configuration.

It's quite likely however that Lavabit, being a service that focusses on privacy, delivers enough emails directly to the target server over a secure protocol to cause problems for the NSA in this investigation.

The problem is that all of the people you correspond with use gmail, which participates in PRISM. No amount of transport encryption or storage encryption on your own end will stop Google from sharing that data with US authorities.

"Participates" is the wrong characterisation, they are under the jurisdiction of FISA orders, if the NSA wants to call that PRISM, it's their business. Also worth mentioning is that providers in non-US countries are subject to their respective country's surveillance efforts, so either way it's a red herring argument.

"Participates" is a perfectly acceptable word for silently complying with a law. Especially for an international company that could have changed jurisdiction of the relevant servers.

"Participates" is not at all an acceptable word for actions taken under duress, and for an international company, changing jurisdiction of the relevant servers would have made no difference whatsoever. As long as your flesh-and-blood body is located in the US, or in a country that chooses to enforce US law in such matters (or will ever be so located in the future, even for a stopover on an international flight), your servers could be on the moon for all it matters; you still have to obey the government.

There are different levels of duress. Nobody pointed a gun at Google. They could have refused if they truly wanted to.

Can the US serve a warrant to a server in Europe run by Europeans? I was assuming the answer was no, in which case you don't need violate any laws or worry about repercussions.

Well anything that hits an MTA or MDA and sits in a queue somewhere on rust is liable to be snagged. That's usually every host between you and the destination MUA.

The whole protocol and mail delivery system is fucking hopeless.

As an ex-ISP mail architect and ex-operations guy, I hope the whole existing email protocol suite and architecture dies in a fire.

The problem is that, left to market forces, we would end up with an email solution that looks like (or is) Facebook.

I'd rather we stopped talking electronically than ended up with Facebook.

Your username combined with your claimed former work experience is utterly hilarious--thank you for the levity in this dark time.

The name came after many years of filling in paperwork :)

...which is why you encrypt the contents before you send it, yes?

Considering that most other people don't use email encryption, no.

This is why the speculation that even with encrypted emails, to and from address is in the clear and that could be valuable info to government. So we're back to meta data in plain text both in transit and storage.

What? I don't think this is true at all. Plaintext data, email or not, can be protected with robust encryption. Your end security is the main consideration, but that has nothing to do with the protocol or content, really.

The difficulty is that most recipients of your message will not be willing to use whatever crypto technology you've chosen. PGP is probably the most popular email encryption system, but good luck finding people who use it. I work in the software industry, and I don't regularly correspond with a single person whom I know to use PGP.

It'll be interesting to see whether companies start to shift to using encrypted email over the next few decades - it's not that hard to set up if you know the counterparty will be using encryption of the same kind, and if it's not a service bought in from an external company you can fairly sure it is secure.

Companies could at least insist that intra-company email is encrypted, which would be a huge amount of their normal communications, and then extend that outside their boundaries with partners who also accept (say) S/MIME.

At present I sign my mails but like you have no clients who use encryption.

Key exchange is still a huge issue. Sure, you can post a public key online, but I have no guarantee it is actually your key. How do I do business with somebody new?

The core problem with widespread crypto use today is not encryption, it's trusted key exchange.

Put the fingerprint in your business cards? In fact, maybe we finally found a reasonable use for QR codes.

Fingerprint in hex at the bottom of the business card is something I've done for the past 15 years -- pretty much the only reason I even bother with business cards these days.

This is a really interesting problem that needs to be solved. We need some sort of P2P secure protocol to exchange keys between people. Bypassing all sorts of stuff and connecting directly and sharing over an encrypted channel. This sounds really tough the way the internet works right now but I think solutions will come up now that there is a real need for them.

Exchange/Outlook already does intra- and extra-company encryption.

Thanks, I didn't know that.

This comment implies you actually trust Microsoft's crypto implementation.

Nope, only that companies trust Microsoft's crypto implementation.

But as it happens, yes, I trust our crypto developers. They're much better at it than most of HN.

I don't. I've seen the source (via shared source) and there is a big fucking hole where the CSPs should be.

And the rest of the code is pretty shitty in places.

Reply on news.ycombinator.com