6 ms·

Can someone explain why this is important enough to land on the HN front page? Are people being inconvenienced by this or something?

by Meekro 1y ago

foobarkey 1y ago
Crqpping on google is meta
syeare 1y ago
I can't explain it, no unfortunately But what about someone maintaining and developing, say, an obscure e-mail client?
- Meekro 1y ago
  If someone's maintaining an old/obscure email client, I would expect them to be importing a TLS library under the "don't roll your own crypto" principle. Assuming it's been updated at some point in the last ~15 years, it's probably capable of auto-negotiating to something better than 3DES. And if it hasn't been updated for that long, it probably doesn't support TLS 1.2 and is getting rejected from just about everything for that reason.
DaiPlusPlus 1y ago
Statistically, someone, somewhere, has a VAX box that hasn't been rebooted since before the fall of the Soviet Union, running their org's MTA with a comically outdated cryptosuite. Anyone running vaxen that old is bound to be a regular here on HN.
- Meekro 1y ago
  Unfortunately, that box is going to have increasing difficulty connecting to anyone at all. TLS 1.2 was added to OpenSSL around 2010, and de-facto mandated around 2020. Any SSL/TLS software from before that will increasingly find its connections rejected.
  - jeroenhd 1y ago
    The world of email is full of zombie servers that should've died years ago but still linger. Configuring your email server to require the security that was considered "modern" ten years ago in terms of websites will still get you delivery failures when you start dealing with email servers. There's a reason Google is deprecating 3DES now, and not ten years ago when they reasonably should've. Because email customers on all sides want email to arrive, there's little incentive to modernize configurations or requirements. When you disable ancient cryptography, you'll get blamed for your change making email from someobscurewebsite.gov no longer arriving. For a significant amount of mail servers, you can pick between "accept a random self-signed certificate using a cipher suite from the late 2000s" or "send email over unencrypted SMTP", and you just have to hope that the email server doesn't have your domain configured as "secure transmission required". I'm in favour of Google just breaking the old, broken mail servers, but I wouldn't assume that TLS 1.2 is available on email servers.
andreareina 1y ago
To me it’s surprising in the sense that it was even still supported.
- Meekro 1y ago
  Yeah, apparently OpenSSL dropped it almost 10 years ago.
zzq1015 1y ago
I had no idea that you can filter/reject certain TLS versions/ciphers (on Gmail servers) before seeing this on the HN front page. https://support.google.com/a/answer/9795993 https://support.google.com/a/answer/9795993
- Meekro 1y ago
  If you've never used a TLS library such as Go's crypto/tls, that's understandable-- this is stuff most programmers never need to think about. Fortunately TLS does work pretty well: both sides of an encrypted connection will auto-negotiate and pick the strongest cipher that they both support. TLS libraries do drop old, weak ciphers from time to time. But thanks to auto-negotiating, this will only be a problem if your TLS lib is so out-of-date that it doesn't support any still-trusted alternatives. Which brings me back to why this story is so strange: "Gmail upgrades TLS library, drops old insecure algorithm that OpenSSL had dropped almost 10 years ago."
  - zzq1015 1y ago
    Oh, I meant on Gmail servers. I always customize TLS versions and cipher suites because I don't trust the defaults. AFAIK you can customize them on: - Chrome & Firefox (can only enable/disable ciphers, no reordering, PQ ciphers supported since 2024) - OpenSSL (by customizing openssl.cnf, PQ ciphers supported since 3.5) - curl - nginx/apache - OpenSSH (I enabled PQ ciphers too) - Multiple programming libraries - and others... Also, clients and servers don't "pick the strongest cipher that they both support". Servers select the cipher ultimately, and they can be misconfigured to pick, for example, 3DES over AES.
cedilla 1y ago
Because it's interesting? The 3DES saga is still ongoing...

Can someone explain why this is important enough to land on the HN front page? Are people being inconvenienced by this or something?

by Meekro 1y ago

Can someone explain why this is important enough to land on the HN front page? Are people being inconvenienced by this or something?

foobarkey 1y ago

Crqpping on google is meta

syeare 1y ago

I can't explain it, no unfortunately But what about someone maintaining and developing, say, an obscure e-mail client?

Meekro 1y ago
If someone's maintaining an old/obscure email client, I would expect them to be importing a TLS library under the "don't roll your own crypto" principle. Assuming it's been updated at some point in the last ~15 years, it's probably capable of auto-negotiating to something better than 3DES. And if it hasn't been updated for that long, it probably doesn't support TLS 1.2 and is getting rejected from just about everything for that reason.

DaiPlusPlus 1y ago

Statistically, someone, somewhere, has a VAX box that hasn't been rebooted since before the fall of the Soviet Union, running their org's MTA with a comically outdated cryptosuite. Anyone running vaxen that old is bound to be a regular here on HN.

Meekro 1y ago
Unfortunately, that box is going to have increasing difficulty connecting to anyone at all. TLS 1.2 was added to OpenSSL around 2010, and de-facto mandated around 2020. Any SSL/TLS software from before that will increasingly find its connections rejected.
- jeroenhd 1y ago
  The world of email is full of zombie servers that should've died years ago but still linger. Configuring your email server to require the security that was considered "modern" ten years ago in terms of websites will still get you delivery failures when you start dealing with email servers. There's a reason Google is deprecating 3DES now, and not ten years ago when they reasonably should've. Because email customers on all sides want email to arrive, there's little incentive to modernize configurations or requirements. When you disable ancient cryptography, you'll get blamed for your change making email from someobscurewebsite.gov no longer arriving. For a significant amount of mail servers, you can pick between "accept a random self-signed certificate using a cipher suite from the late 2000s" or "send email over unencrypted SMTP", and you just have to hope that the email server doesn't have your domain configured as "secure transmission required". I'm in favour of Google just breaking the old, broken mail servers, but I wouldn't assume that TLS 1.2 is available on email servers.

andreareina 1y ago

To me it’s surprising in the sense that it was even still supported.

Meekro 1y ago
Yeah, apparently OpenSSL dropped it almost 10 years ago.

zzq1015 1y ago

I had no idea that you can filter/reject certain TLS versions/ciphers (on Gmail servers) before seeing this on the HN front page. https://support.google.com/a/answer/9795993 https://support.google.com/a/answer/9795993

Meekro 1y ago
If you've never used a TLS library such as Go's crypto/tls, that's understandable-- this is stuff most programmers never need to think about. Fortunately TLS does work pretty well: both sides of an encrypted connection will auto-negotiate and pick the strongest cipher that they both support. TLS libraries do drop old, weak ciphers from time to time. But thanks to auto-negotiating, this will only be a problem if your TLS lib is so out-of-date that it doesn't support any still-trusted alternatives. Which brings me back to why this story is so strange: "Gmail upgrades TLS library, drops old insecure algorithm that OpenSSL had dropped almost 10 years ago."
- zzq1015 1y ago
  Oh, I meant on Gmail servers. I always customize TLS versions and cipher suites because I don't trust the defaults. AFAIK you can customize them on: - Chrome & Firefox (can only enable/disable ciphers, no reordering, PQ ciphers supported since 2024) - OpenSSL (by customizing openssl.cnf, PQ ciphers supported since 3.5) - curl - nginx/apache - OpenSSH (I enabled PQ ciphers too) - Multiple programming libraries - and others... Also, clients and servers don't "pick the strongest cipher that they both support". Servers select the cipher ultimately, and they can be misconfigured to pick, for example, 3DES over AES.

cedilla 1y ago

Because it's interesting? The 3DES saga is still ongoing...