Hacker News Reader

Comment by jcranmer | Hacker News Reader

> However, it doesn't address intercepting and recording communications in-transit, which is extremely commonplace these days.

MTA<->MTA SMTP transmission is increasingly SSL these days, and end-user MUA<->MTA transmission has pretty much been entirely SSL for a long while. Google cites about 80-90% of its MTA<->MTA transmission is encrypted (https://www.google.com/transparencyreport/saferemail/).

View on HN

Yes, see my link to the BULLRUN program. There were quite a few follow-ups as well.

[1] https://freedom-to-tinker.com/2015/10/14/how-is-nsa-breaking...

[2] https://arstechnica.com/security/2015/10/how-the-nsa-can-bre...

[3] https://blog.cryptographyengineering.com/2013/12/03/how-does...

And so on and so forth.

Also keep in mind that they are retaining a full take online-- storing all traffic on the internet. Even if it can't be decrypted in realtime, they can come back to it in, say 10 years, with all the advancements in brute forcing and potentially quantum computing available in 2027, to take a look at your 2017 activity. The emails you wrote, the websites you visited, all your chats, all your searches, saved forever.

There is no evidence indicating that anyone can break encryption for mail servers using STARTTLS.

Not right now, no. But if you start saving encrypted streams, and then come back to them 10 years later when, perhaps, a TLS vulnerability is found...

I don't know what the media coverage stated, but the source material indicates that full-take is only stored in a 5 day rolling buffer. I believe 30-day for certain flagged selectors. Not at all indefinite, that is not possible.

As of 2011, GCHQ stored their full-take for 3 days and metadata for 30 days. Do you believe they haven't increased capacity in the past 6 years?

Again, the discussion comes down to evidence versus reasoned speculation. Evidence of intelligence agency activity is generally pretty tough to come by.

I'd also believe the country's data transmission volume has increased in the same timeframe, and given how IOT is rapidly scaling up, probably a lot faster than storage capacity.

They have techniques to reduce the data corpus, called "massive volume reduction" or MVR in the GCHQ "Mastering the Internet" rather pompously named leak. It discards junk traffic and assumedly does deduplication, etc. Remember, Tempora went online in 2011, 6 years ago. Techniques have certainly been refined since.

[1] https://www.theguardian.com/uk/2013/jun/21/gchq-cables-secre...

[2] https://www.theguardian.com/uk/2013/jun/21/gchq-mastering-th...

But we're talking encrypted streams here. No algorithm, real or imagined, can dedupe or compress random noise.

Additional data intake would greatly increase costs as well. I guess I'm not fully understanding, is the implication that getting more data would lead to more useful information?

From reading the source documentation itself (not editorialized coverage), it seems they are already swimming in almost too much data. Their focus is much more likely to be aimed at data refinement at this point, as adding even more data would make it far more difficult for analysts to do their job.

It absolutely will NOT be more useful! That's one of the main takeaways from Snowden's leaks-- mass surveillance does not make us safer. Thing is, the three-letter agencies strongly disagree.

It is unlikely that many servers are strong enough to resist penetration and theft of the mail server's private key. That key then can be indexed and matched as well. Is your mail server refusing downgrades to non-PFS ciphers? Is your kernel not affected by zero-days leaking the state of your secure random pool? Are there vulnerabilities in openssl we don't know about but collection agencies do? Is the reason that the government hasn't announced the CNSA Suite yet because the NSA is busy taking advantage of EC weaknesses combined with quantum computing capability? To say nothing of various direct TLS attacks, which are easy enough to translate from HTTP to SMTP, are agencies putting these to work? How far does the integration of passive collection and active attack go these days - there's plenty of evidence to indicate they have been significantly combined in the past.

To say there is no evidence that anyone can break a TLS session is a bit like denying climate change.

> To say there is no evidence that anyone can break a TLS session is a bit like denying climate change.

None of what you have stated is evidence, and nothing from the leaked Snowden material is evidence. I did not say that they cannot do it as I have no way of knowing that, only said there is no actual evidence at all, so this devolves into "what-ifs" which lead to helplessness. I do not see how that is good for anyone.

The dirty secret nobody wants to talk about is that MTA's don't do certificate validation. You can't or you'd never deliver email successfully because of the number of self signed certs out there.

MITM on SSL/TLS SMTP is child's play

Postfix and Exim both support DANE/TLSA. When I email somebody with TLSA set up, or they email me, the certificates are validated using DNSSEC signed DNS records:

  mike@snake:~$ dig +short mx grepular.com
  20 mail.grepular.com.
  10 mx1.grepular.com.
  mike@snake:~$ dig +short tlsa _25._tcp.mx1.grepular.com
  2 1 1 60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517 616E8A18
  2 1 1 B111DD8A1C2091A89BD4FD60C57F0716CCE50FEEFF8137CDBEE0326E 02CF362B
  mike@snake:~$ dig +short tlsa _25._tcp.mail.grepular.com
  2 1 1 B111DD8A1C2091A89BD4FD60C57F0716CCE50FEEFF8137CDBEE0326E 02CF362B
  2 1 1 60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517 616E8A18
  mike@snake:~$

Who are you emailing? Gmail/yahoo/other technically competent organizations?

Try working with small businesses, lawyers, etc who self-host. It will fail and clients will scream bloody murder unless you turn off validation so their emails can get delivered.

That assumes that nobody can MITM either your DNS server, the your ISPs DNS cache (if you use it), or Google's DNS cache (if you use it).

Or it assumes DNSSEC.

It does assume DNSSEC yes. Which is a requirement of DANE.

Hopefully Let's Encrypt (and ACME in general) and similar efforts will help to alleviate that issue.

Let's Encrypt in particular seems to be more geared toward websites, but I actually did manage to put it to use rather trivially on my mailserver (which previously used self-signed certs) thanks to 'acme-client' on OpenBSD.

How will using SSL/TLS protect you from the NSA?

They must surely have the ability to generate valid certificates.

I don't get why this was downvoted. The chances are that the NSA has obtained at least some certificate authorities' root certificates must surely be pretty high?

I not why not? (I may be misunderstanding something about root certificates).

Because using a CA to issue a cert for you improperly is a good way to burn your CA. So it'll probably be used very carefully and in very limited scope because it's detectable and leaves undisputable proof.

For SMTP it's different since people aren't watching as closely. -- but then the CA angle is irrelevant because there's no verification. Though I'd be surprised if Google doesn't have some sort of program to look at these things and try to detect MITM or just gather info in general.

Didn't they just add a little security indicator to Gmail? Google could probably single handedly force TLS verification on email by saying it'll increase deliverabiliy.

It's actually even simpler than that: self-signed certs are rampant among mailservers, so it'd be trivial (comparatively speaking) to perform a MITM attack. Hopefully we'll eventually get to the point where everyone is using Let's Encrypt or has otherwise ditched self-signed certs, but until then, the likes of the NSA wouldn't even need to bother with the CAs to snoop on mail traffic.

Do MTAs check the certs of each other now? I was under the impression that they largely didn't.

By and large the only way to prevent man in the middle and downgrade attacks is to use DNSSEC and DANE. Without that, an attacker can just filter out the STARTTLS option in the SMTP EHLO response and the mail will be sent in plaintext.

However, active attacks like downgrade attacks and TLS man in the middle are not popular for large scale surveillance. The reason is that it is easy to detect.

Or you could just use the existing standard TLS handshake instead of STARTTLS to upgrade the connection. DANE for this would be a step backwards, as you would just give governments the control of the PKI system.

Edit: There is, however, something you could do with DNSCRYPT (or blockchain), that goes beyond just in-transit encryption. If you could publish your public key to a trust-worthy registry then we could have transparent body encryption. You could move email storage locally (with encrypted cloud backup), but still have DDoS resistant MXs.

For large scale monitoring of traffic, active attacks are very unattractive. If a government would manipulate dns on a large scale, that would cause a lot of trouble.

For targeted attacks, using PGP is the way to go. Though it comes with the price of manual key management.

It would be nice if somebody can do decentralised authentication at scale. But I haven't seen it in practice and I doubt it is going to happen at all.

PGP works on individual message level. If email encryption is ever to get ubiquitous it needs a more comprehensive approach. It should start with a local email server that keeps all messages in an encrypted vault and can communicate in a secure manner with other clients that implement the “secure delivery” protocol (which would be indicated by being able to securely resolve the public key of target email address, and from an UI perspective by a special “Secure Send” send button).

Manual key management will never succeed. Key discovery needs to be aggressively opportunistic yet secure. It’s the only way to go.

Disclaimer: I'm only a consumer of cryptography, not a cryptographer.

I have the feeling that secure email needs to be completely separate from SMTP; clients might be able to use both, in the same way that Signal will also use SMS when necessary. It should probably use a double-ratchet-based protocol, but cannot rely on centralization for contacts discovery and key exchange (because then it wouldn't be email-like).

Among things that currently exist, it seems like the Matrix protocol[0] and OMEMO[1] seem basically suitable as a transport (both of them use the Olm protocol developed for Matrix, I believe).

[0]: https://www.matrix.org/ [1]: https://xmpp.org/extensions/xep-0384.html

You can absolutely replace SMTP but whatever you replace it with needs to be at least compatible with it. Lots of warnings, Insecure Email Ahead, but it needs to be compatible.

I also don’t think email should be e2e by default. Next gen email will never get adopted if Gmail can’t index it. What you want is to give them the option of selling “Secure Cloud Email Vault.” Something that’s encrypted or partially encrypted (just body) on their servers, like Amazon is selling encryption for S3.

But the protocol can also support fully local encrypted email (as detailed in my previous) for those that want that.

Edit: Oh also for the actual cryptography there needs to be a way to give someone (like Court Order) decryption key to a single message. This avoids a lot of issues. Governments are not just going to let you deploy fully encrypted email by default.

> I also don’t think email should be e2e by default. Next gen email will never get adopted if Gmail can’t index it.

Fallback is fine; in the age of "surveillance capitalism" security for the moderately interested is the best we can hope for.

> Governments are not just going to let you deploy fully encrypted email by default.

What do you base this on? What would they do?

> What do you base this on? What would they do?

PATRIOT Act Vol. 2. It’s the lizard people I’m worried about.

I'm very curious if you know a decentralised authentication mechanism that scales and works for e-mail. I don't know any.

Without, improving over PGP is mostly wishful thinking.

As I said DNSCRYPT or Blockchains like Etherium/Namecoin. PGP’s WoT model is a complete failure.

They either don't or will happily silently downgrade to SMTP even if previously they've connected via SSL. So an active interceptor can still intercept communications.

Reply on news.ycombinator.com