* If you have compromised a private key, you can get useful data from the cable intercept.
* If you can collect ciphertext today, and decrypt it tomorrow (with, say, quantum computers), the cable intercept is very useful.
The OC's point was by default, meaning/inferring clear-text is still the modus operandi for generally getting onto IRC services.
>Many applications still aren't encrypted by default, like IRC.
SSL and SASL aren't, precisely, user-friendly implementations with some clients (e.g.: IRSSI[0] - but if you're using IRSSI, you don't want a user-friendly GUI to begin with, so...).
SASL has less to do with the actual encryption mechanism and more to do with the authentication mechanism (think NTLM)[1].
If IRC services dropped clear-text, today, that would go a lot further to standardising (e.g.: making default) encryption but, back to the OC's original point, it is not the default today.
[0] - https://freenode.net/kb/answer/irssi
[1] - https://en.wikipedia.org/wiki/Simple_Authentication_and_Secu...
I mention SASL because it is relevant to security posture, especially if the user wasn’t connecting via TLS. Although of course the server could allow PLAINTEXT in practice there’s no point in supporting that because IRC already had native plaintext server authentication.
[1]: https://github.com/hexchat/hexchat/blob/3d1d9e1716d66abb6921...
They're a lot better than I thought! (over 90% in each direction, although no data here about certificate verification and the presence or absence of backbone downgrade attacks)
If you run your own mail service, check out my colleague's project at
It probably means your email to your aunt isn't intercepted and shoved onto an enormous pile of decrypted email to be parsed for keywords. Probably. But that's about all.
Against an adversary determined to intercept:
- They can probably just strip STARTTLS, so that everything happens in plaintext - Even if they can't do that because of MTA-STS or similar, they can probably just present self-signed certs and it'll pass the mandatory checks - If they can't do /that/ either (no idea what proportion of email but it may well be in the minority) they can downgrade because unlike in HTTPS nobody is just saying "Old garbage bad, never do that or we'll scream" and so people keep doing it. SSLv3 may even work with a lot of mail servers.
Still, what we have now with opportunistic SMTP encryption is equivalent to what you get with snail mail. The spooks CAN read anybody's mail, but it's a hassle so they mostly don't read yours.