Don't worry - it only took 9 years between 3DES being publicly known to have severe vulnerabilities and Google deciding it isn't appropriate for protecting perhaps the most sensitive dataset in the world (private emails).
CVE-2016-2183...
aspenmayer · 4h ago
Email on Gmail (or on any cloud email service provider subject to US jurisdiction) older than 180 days is available upon request without a warrant.
> Under ECPA, it is relatively easy for a government agency to demand service providers hand over personal consumer data stored on the service provider's servers. Email that is stored on a third party's server for more than 180 days is considered by the law to be abandoned. All that is required to obtain the content of the emails by a law enforcement agency is a written statement certifying that the information is relevant to an investigation, without judicial review.
That's the statute, but arguably it's superseded by the Fourth Amendment, and many companies have a policy of treating it as such. Google's policy[0] is to disregard the ECPA 180 day rule, and to always require a warrant for content:
>On its face, ECPA seems to allow a government agency to compel a communications provider to disclose the content of certain types of emails and other content with a subpoena or an ECPA court order (described below). But Google requires an ECPA search warrant for contents of Gmail and other services based on the Fourth Amendment to the U.S. Constitution, which prohibits unreasonable search and seizure.
Essentially, they're saying that they think they would win a constitutional challenge if the government were to try and fight them on this. It doesn't look like the government has taken them up on that to date.
Similar policy from Apple[1]:
> For all requests from government and law enforcement agencies within the United States for content, with the exception of emergency circumstances (defined in the Electronic Communications Privacy Act 1986, as amended), Apple will only provide content in response to a search warrant issued upon a showing of probable cause, or customer consent.
Meta[2]:
>A search warrant issued under the procedures described in the Federal Rules of Criminal Procedure or equivalent state warrant procedures upon a showing of probable cause is required to compel the disclosure of the stored contents of any account, which may include messages, photos, videos, timeline posts, and location information.
Is ‘stored’ in this context implying unread also, or is using IMAP to maintain a local and remote sync considered ‘abandoned’?
SchemaLoad · 5h ago
Was Gmail actively sending emails with this? Or just not blocking emails from other servers using it? Breaking email deliverability is a pretty serious action to take.
tialaramex · 2h ago
The latter.
What we're talking about here is a TLS negotiation. So, when you connect to a TLS server, in this case to deliver email to Gmail over SMTP - you tell it what ciphers you know [the RFCs list "Mandatory to implement" ciphers, but the IETF do not have an enforcement arm, so you could choose to list only ciphers you made up here for whatever that's worth] - and then the server picks one from your list.
Google's change here is when a client calls Gmail and professes that the least awful cipher it knows is 3DES, that's too bad, connection failed.
So yes, this only affects email which was previously using this awful cipher and now just can't be delivered instead.
jeroenhd · 2h ago
With Gmail's spam filter being the way it is, email deliverability issues because of 3DES are probably invisible next to the normal email being silently discarded.
Users trying to send email to an outgoing SMTP server that hasn't been maintained this decade may see a warning, but I doubt there are still that many broken server out there that can't be replaced or updated on short notice once the domain admin gets told Gmail can't reach them.
behringer · 5h ago
The broken systems would have repaired their systems 8 years ago when users complained.
fweimer · 4h ago
This can be mitigated by limiting the amount of data that is transmitted with a single 3DES session key. I doubt that Gmail accepts that many gigabytes of data in a single SMTP session anyway, so I doubt it's impacted by this flaw.
(AES-GCM requires rekeying, too, also at intervals that exceeds typical SMTP session lengths, and is not considered terminally broken because if this.)
ahofmann · 2h ago
I'm a bit confused. On a technical level emails are even less secure than postcards. Everyone involved transporting it, can read, copy and save it. So how are emails private and the most sensitive dataset in the world?
I know that my email account is the most important part in my digital life and if someone would get hold of it, I'm basically dead. But the emails I get and send are not private at all.
entropyie · 3h ago
Unless folks are regularly sending 32GB emails, this CVE is not severe in this context.
jeroenhd · 2h ago
You don't need to send 32GB of emails, you only need to send 32GB of traffic. Setting up a TLS connection and sending EHLOs ad infinitum can generate traffic without hitting any "message size < 8MiB" filters.
jsnell · 2h ago
What's the threat model here? A scenario where the attacker controls the plaintext being sent but doesn't know what the plaintext is seems quite unlikely.
xtajv · 39m ago
> A scenario where the attacker controls the plaintext being sent but doesn't know what the plaintext is seems quite unlikely.
(Not sure what attack scenarios OP had in mind -- iust sharing the usual CPA example)
danielbln · 3h ago
I try to keep all of my mails to just under 31GB.
agildehaus · 5h ago
3DES isn't as easy to exploit versus, say SSLv3 and RC4 which were both quickly removed.
zzq1015 · 4h ago
Probably not just that. 3DES is the last cipher supported by "old" clients (I'm talking Windows XP). If you remove 3DES, the TLS connection will simply fail.
You can never imagine how many people are still using WinXP, or other forgotten legacy clients/servers that only support up to TLS 1.0 and RC4/DES/3DES without realizing it.
waste_monk · 3h ago
>You can never imagine how many people are still using WinXP
XP still has 0.38% of market share (specifically Windows non-mobile platforms) according to [1], not sure about absolute numbers.
>If you remove 3DES, the TLS connection will simply fail.
Strong backwards compatibility is great, but continuing to run XP 10+ years after EOL is a personal choice and its remaining users should not expect the world to continue to accomodate them forever. I don't think it's unreasonable to deny them service in this case.
Article is talking server-server flows not clients.
waste_monk · 3h ago
Would this not also include desktop email clients using SMTP for mail submission?
zzq1015 · 3h ago
Yeah, despite what it says, I really think Google is gonna ditch 3DES across the board, starting from Gmail.
zzq1015 · 4h ago
"The obvious way to avoid these attacks is to stop using legacy 64-bit block ciphers. Alternatively, the attack can be mitigated by rekeying the session frequently."
Although I doubt the older clients even implement rekeying at all...
timewizard · 4h ago
Triple DES was always just sort of funny to me. "DES is completely broken. So we'll just do it three times in a row now." Well, fun while it lasted, I guess.
zzq1015 · 4h ago
DES is weak because it only uses 56 bits, and you can brute force it. 3DES has 168 (56*3) bits with the security of 112 (56*2) bits.
scrapheap · 3h ago
Yes, the problem with 3DES isn't the key length, it's the 64bit block size which opens it up to birthday attacks if it's used in a stream for a long enough with the same key. Defending against this sort of attack is one of the reasons that a lot of VPN setups rekey the encrypted connection with the client at regular intervals. Note that once Gmail disables 3DES it's minimum block size supported will be 128bits.
NicolaiS · 4h ago
Biggest reason to avoid DES is the short key. Double-DES doesn't fix that due to the meet-in-the-middle attack. Triple DES "solves" the short key problem.
fishgoesblub · 7h ago
My reading has gotten worse over the years, it took me multiple times re-reading to realise this isn't deprecating Gmail on the Nintendo 3DS.
toast0 · 4h ago
I think they did that last year, when they killed the HTML version of Gmail. I kind of really doubt the 3DS browser can run the regular gmail interface.
jxjnskkzxxhx · 4h ago
> My reading has gotten worse over the years
Do you spend a lot of time on your phone?
Meekro · 5h ago
Can someone explain why this is important enough to land on the HN front page? Are people being inconvenienced by this or something?
DaiPlusPlus · 5h 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 · 3h 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 · 2h 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 · 4h ago
To me it’s surprising in the sense that it was even still supported.
Meekro · 4h ago
Yeah, apparently OpenSSL dropped it almost 10 years ago.
zzq1015 · 4h 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.
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 · 3h 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 · 4h ago
Because it's interesting?
The 3DES saga is still ongoing...
syeare · 5h ago
I can't explain it, no unfortunately
But what about someone maintaining and developing, say, an obscure e-mail client?
Meekro · 4h 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.
foobarkey · 5h ago
Crqpping on google is meta
gpvos · 2h ago
Does Gmail support receiving unencrypted SMTP? And can you see whether encryption was used during transport?
aaronmdjones · 2h ago
Yes, and yes. Click the three dots icon in the top right (next to the star icon etc) and click "Show original". Look for the Received: header added by Google's servers. If it says SMTP, it was a very old MTA on the other side. If it says ESMTP, it was newer. If it says SMTPS or ESMTPS, it was secured with TLS; then it will also say the TLS version and ciphersuite below it.
CVE-2016-2183...
> Under ECPA, it is relatively easy for a government agency to demand service providers hand over personal consumer data stored on the service provider's servers. Email that is stored on a third party's server for more than 180 days is considered by the law to be abandoned. All that is required to obtain the content of the emails by a law enforcement agency is a written statement certifying that the information is relevant to an investigation, without judicial review.
https://en.wikipedia.org/wiki/Electronic_Communications_Priv...
>On its face, ECPA seems to allow a government agency to compel a communications provider to disclose the content of certain types of emails and other content with a subpoena or an ECPA court order (described below). But Google requires an ECPA search warrant for contents of Gmail and other services based on the Fourth Amendment to the U.S. Constitution, which prohibits unreasonable search and seizure.
Essentially, they're saying that they think they would win a constitutional challenge if the government were to try and fight them on this. It doesn't look like the government has taken them up on that to date.
Similar policy from Apple[1]:
> For all requests from government and law enforcement agencies within the United States for content, with the exception of emergency circumstances (defined in the Electronic Communications Privacy Act 1986, as amended), Apple will only provide content in response to a search warrant issued upon a showing of probable cause, or customer consent.
Meta[2]:
>A search warrant issued under the procedures described in the Federal Rules of Criminal Procedure or equivalent state warrant procedures upon a showing of probable cause is required to compel the disclosure of the stored contents of any account, which may include messages, photos, videos, timeline posts, and location information.
[0] https://support.google.com/transparencyreport/answer/9700059...
[1] https://www.apple.com/legal/privacy/law-enforcement-guidelin...
[2] https://about.meta.com/actions/safety/audiences/law/guidelin...
What we're talking about here is a TLS negotiation. So, when you connect to a TLS server, in this case to deliver email to Gmail over SMTP - you tell it what ciphers you know [the RFCs list "Mandatory to implement" ciphers, but the IETF do not have an enforcement arm, so you could choose to list only ciphers you made up here for whatever that's worth] - and then the server picks one from your list.
Google's change here is when a client calls Gmail and professes that the least awful cipher it knows is 3DES, that's too bad, connection failed.
So yes, this only affects email which was previously using this awful cipher and now just can't be delivered instead.
Users trying to send email to an outgoing SMTP server that hasn't been maintained this decade may see a warning, but I doubt there are still that many broken server out there that can't be replaced or updated on short notice once the domain admin gets told Gmail can't reach them.
(AES-GCM requires rekeying, too, also at intervals that exceeds typical SMTP session lengths, and is not considered terminally broken because if this.)
I know that my email account is the most important part in my digital life and if someone would get hold of it, I'm basically dead. But the emails I get and send are not private at all.
https://en.wikipedia.org/wiki/Chosen-plaintext_attack#In_pra... comes to mind.
(Not sure what attack scenarios OP had in mind -- iust sharing the usual CPA example)
You can never imagine how many people are still using WinXP, or other forgotten legacy clients/servers that only support up to TLS 1.0 and RC4/DES/3DES without realizing it.
XP still has 0.38% of market share (specifically Windows non-mobile platforms) according to [1], not sure about absolute numbers.
>If you remove 3DES, the TLS connection will simply fail.
Strong backwards compatibility is great, but continuing to run XP 10+ years after EOL is a personal choice and its remaining users should not expect the world to continue to accomodate them forever. I don't think it's unreasonable to deny them service in this case.
[1] https://gs.statcounter.com/os-version-market-share/windows/d...
For sites like Google, it's still too large to ignore.
Also, a fun fact: Google still serves plain HTTP for really old clients, just in case the client barely supports HTTPS.
Machines visiting sites with statcounter tracking widgets (and presumably not running with scripts/cookies disabled etc. ).
That works out to be ~5ish million internet connected XP machines, apparently[1].
>For sites like Google, it's still too large to ignore.
They do this sort of thing all the time [2]. IIRC Reader still had several million users when it got the axe.
[1] https://www.computerworld.com/article/2091600/youre-not-real...
[2] https://killedbygoogle.com/
- https://sweet32.info/
Although I doubt the older clients even implement rekeying at all...
Do you spend a lot of time on your phone?
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.
https://support.google.com/a/answer/9795993
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."
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.
The 3DES saga is still ongoing...
But what about someone maintaining and developing, say, an obscure e-mail client?
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.