CVE-2016-2183...
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.
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.
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...
> 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...
Although I doubt the older clients even implement rekeying at all...
(AES-GCM requires rekeying, too, also at intervals that exceeds typical SMTP session lengths, and is not considered terminally broken because if this.)
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)
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.
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.
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.
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...
fishgoesblub•7h ago
toast0•5h ago
jxjnskkzxxhx•5h ago
Do you spend a lot of time on your phone?