5 ms·

* Many applications still aren't encrypted by default, like IRC. * If you have compromised a private key, you can get useful data from the cable intercept. *

* Many applications still aren't encrypted by default, like IRC. * 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.

esmi 7y ago
IRC sure, but the big win is email.
- SXX 7y ago
  Majority of email traffic is by now for sure use s2s encrypted. Also considering how big major players are most of mail never leave Google / Microsoft / etc servers anyway and connections between them always only ever go over TLS.
  - schoen 7y ago
    You can get some statistics from Google at https://transparencyreport.google.com/safer-email/overview https://transparencyreport.google.com/safer-email/overview 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 https://starttls-everywhere.org/ https://starttls-everywhere.org/
    - esmi 7y ago
      I was just about to post the same link. Outside the US the numbers are a lot lower. Outbound to some countries is 0%. South Africa wasn’t in the report though.
  - tialaramex 7y ago
    Almost all of the SMTP over TLS will be opportunistically encrypted only and usually with pretty bad protocol / cipher choices. 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.
esotericn 7y ago
IRC probably isn't the best example, I've been using TLS for a good while now. "By default" probably depends a lot on the client.
jchw 7y ago
Modern IRC servers tend to support TLS on port 6697 and SASL for authentication. I’ve been connecting to IRC over SSL for probably a decade at least.
- maxheadroom 7y ago
  >Modern IRC servers tend to support TLS on port 6697 and SASL for authentication. 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 https://freenode.net/kb/answer/irssi [1] - https://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer#SASL_mechanisms https://en.wikipedia.org/wiki/Simple_Authentication_and_Secu...
  - jchw 7y ago
    This is mostly irrelevant; users using Web IRC gateways, services like IRCCloud or clients like HexChat[1] do not have to configure the server unless it isn’t already present in the list. If they do, they already will have to manually configure either TLS or plaintext. There is no “default.” 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/3d1d9e1716d66abb6921d15ae22a25f320eeef13/src/common/servlist.c https://github.com/hexchat/hexchat/blob/3d1d9e1716d66abb6921...

esmi 7y ago

IRC sure, but the big win is email.

SXX 7y ago
Majority of email traffic is by now for sure use s2s encrypted. Also considering how big major players are most of mail never leave Google / Microsoft / etc servers anyway and connections between them always only ever go over TLS.
- schoen 7y ago
  You can get some statistics from Google at https://transparencyreport.google.com/safer-email/overview https://transparencyreport.google.com/safer-email/overview 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 https://starttls-everywhere.org/ https://starttls-everywhere.org/
  - esmi 7y ago
    I was just about to post the same link. Outside the US the numbers are a lot lower. Outbound to some countries is 0%. South Africa wasn’t in the report though.
- tialaramex 7y ago
  Almost all of the SMTP over TLS will be opportunistically encrypted only and usually with pretty bad protocol / cipher choices. 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.

esotericn 7y ago

IRC probably isn't the best example, I've been using TLS for a good while now. "By default" probably depends a lot on the client.

jchw 7y ago

Modern IRC servers tend to support TLS on port 6697 and SASL for authentication. I’ve been connecting to IRC over SSL for probably a decade at least.

maxheadroom 7y ago
>Modern IRC servers tend to support TLS on port 6697 and SASL for authentication. 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 https://freenode.net/kb/answer/irssi [1] - https://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer#SASL_mechanisms https://en.wikipedia.org/wiki/Simple_Authentication_and_Secu...
- jchw 7y ago
  This is mostly irrelevant; users using Web IRC gateways, services like IRCCloud or clients like HexChat[1] do not have to configure the server unless it isn’t already present in the list. If they do, they already will have to manually configure either TLS or plaintext. There is no “default.” 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/3d1d9e1716d66abb6921d15ae22a25f320eeef13/src/common/servlist.c https://github.com/hexchat/hexchat/blob/3d1d9e1716d66abb6921...