5 ms·
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 perh
by londons_explore 1y ago
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...
- SchemaLoad 1y agoWas 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.
- behringer 1y agoThe broken systems would have repaired their systems 8 years ago when users complained.
- deleted 1y ago[deleted]
- jeroenhd 1y agoWith 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.
- tialaramex 1y agoThe 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.
- agildehaus 1y ago3DES isn't as easy to exploit versus, say SSLv3 and RC4 which were both quickly removed.
- zzq1015 1y agoProbably 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.
- everfrustrated 1y agoArticle is talking server-server flows not clients.
- waste_monk 1y agoWould this not also include desktop email clients using SMTP for mail submission?
- zzq1015 1y agoYeah, despite what it says, I really think Google is gonna ditch 3DES across the board, starting from Gmail.
- waste_monk 1y 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. [1] https://gs.statcounter.com/os-version-market-share/windows/desktop/worldwide https://gs.statcounter.com/os-version-market-share/windows/d...
- timewizard 1y agoTriple 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 1y agoDES 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 1y agoYes, 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 1y agoBiggest 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.
- aspenmayer 1y agoEmail 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. https://en.wikipedia.org/wiki/Electronic_Communications_Privacy_Act https://en.wikipedia.org/wiki/Electronic_Communications_Priv...
- eurleif 1y agoThat'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. [0] https://support.google.com/transparencyreport/answer/9700059#zippy=%2Cwhats-the-difference-between-a-subpoena-a-search-warrant-and-a-court-order-under-ecpa-what-information-can-a-government-agency-get-from-google-with-each https://support.google.com/transparencyreport/answer/9700059... [1] https://www.apple.com/legal/privacy/law-enforcement-guidelines-us.pdf https://www.apple.com/legal/privacy/law-enforcement-guidelin... [2] https://about.meta.com/actions/safety/audiences/law/guidelines https://about.meta.com/actions/safety/audiences/law/guidelin...
- zzq1015 1y 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." - https://sweet32.info/ https://sweet32.info/ Although I doubt the older clients even implement rekeying at all...
- fweimer 1y agoThis 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.)
- entropyie 1y agoUnless folks are regularly sending 32GB emails, this CVE is not severe in this context.
- danielbln 1y agoI try to keep all of my mails to just under 31GB.
- jeroenhd 1y agoYou 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 1y agoWhat'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 1y ago> A scenario where the attacker controls the plaintext being sent but doesn't know what the plaintext is seems quite unlikely. https://en.wikipedia.org/wiki/Chosen-plaintext_attack#In_practice 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)
- jsnell 1y agoThe suggested attack was the attacker writing an infinite stream of EHLOs on a connection. What's the scenario where an attacker has full control of the SMTP control framing, but doesn't have attack to the payloads?
- sim7c00 1y agoSearch for 'sweet32 attack' . it's pretty much this technique - i think. The CVE mentions that attack type atleast, and it has its own .info site to explain what it is... The message type jeroenhd mentioned is useful here, as it generates a predictable response from the server, without having to sent actual email over it or authenticate against it. (so an external attacker can generate the needed encrypted traffic, with predictable / known plaintext). They dont know emails being sent, but they do know the response to EHLO. once the attack is acheived, they have a key, and can decrypt also other traffic sent by the service if you manage to capture it. I'd say the thread-model or whatever is thus, someone who can sniff your email traffic and can speak to your smtp server. (if they can do the first, certainly they can do the second.) its much harder to get to the email traffic outside of your network, but not impossible. (ISP for example can grab it easily.... - so in certain regions this might be a big risk - nasty governemnts etc..)
- ahofmann 1y agoI'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.
- belter 1y agoGoogle business is selling ads not security. :-) Look at all the insecure ciphers they will still allow you to connect with: https://www.ssllabs.com/ssltest/analyze.html?d=gmail.com&latest https://www.ssllabs.com/ssltest/analyze.html?d=gmail.com&lat...
- zinekeller 1y agoThis is highly misleading, especially that Gmail still accepts plaintext SMTP communications. In that context, this is more of a code cleanup rather than the security brouhaha that this is implying.