Something I've been interested in for the past few months is SSL/TLS, and in particular looking at undetectable attacks.
Censorship is detectable. You know you're being censored. Censorship always implies passive network tapping - the entity has to perform the tap to do the censorship. And censorship itself is an active attack - the entity blocks you from visiting the website.
But passive attacks are usually undetectable from the user's perspective. If a network is being tapped - either a corporate network, or the national backbone - you usually have no way of learning this. We have a pretty good idea that the NSA is tapping large swaths of the Internet, but because it's just whistleblowers it's not considered credible proof. The Swedish version however is well documented.
But active attacks aren't always detectable either. If Chrome didn't have cert pinning, who knows how long DigiNotar would have been undetected. If a CA is compromised, we won't be able to detect an attack. Bugs can bypass certificate validity checking too. It's a dangerous type of client bug that allows undetectable MITM, but we've seen them. And if a client isn't checking for the validity of a certificate, an attacker doesn't need a bug or CA compromise, they can just perform a MITM with a self-signed certificate.
When we think of "SSL clients" we think of web browsers. Sometimes email uses SSL too. Not always. When it doesn't, it's obviously easy to tap and read. But when it does, it's not much better.
Your individual client - Outlook or Thunderbird will require a valid certificate if it's configured to use SSL. But there's more to it than that. Without going into too much detail, Outlook is a Mail User Agent (MUA), and it talks to a Mail Transfer Agent (MTA). When you send an email, your MUA transfers it to a MTA, and the MTA transfers it to another MTA. That MTA-to-MTA transfer is rarely protected by SSL. When it is protected it rarely has a valid certificate. Even if it does have a valid certificate, it's almost never that a MTA requires a valid certificate.
The end result of this is that our entire email infrastructure is vulnerable to passive eavesdropping and undetectable active attacks. We have statistics. And we have examples. You can use the very awesome CheckTLS.com to run some tests on different mail servers. I ran a few tests myself:
- Valid SSL Certificate
- Wells Fargo
- Bank of America
- PNC Bank
- Has Invalid SSL Certificate
- Google/Gmail, including Twitter and Github
- Google Voice e.g. txt.voice.google.com
- Youtube - bad wildcard
- J.P. Morgan Chase
- ING Direct
- Tor Project (self-signed)
- EFF (For a strange reason..)
- Comodo (For a strange reason..)
- Digicert (For a strange reason..)
- Has no SSL Certificate
- Discover Card
There's no ubiquitous e-mail encryption (S/MIME or PGP), there's no requirement for a valid SSL certificate (for what it's worth), and there's no requirement for SSL at all. And there's no global plan for fixing it either. Yet.