7 ms·

Unless folks are regularly sending 32GB emails, this CVE is not severe in this context.

danielbln 1y ago
I try to keep all of my mails to just under 31GB.
jeroenhd 1y 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 1y 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 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 ago
      The 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 ago
    Search 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..)
    - jsnell 1y ago
      In your example, the attacker already has the session key for the TLS connection, so they don't need to run this attack to decrypt the traffic on that connection. And running the attack does not help them decrypt any other connections. Sweet32 depended on the attacker being able to send an arbitrary amount of traffic over a connection where they did not control either of the endpoints, and with that connection also carrying the data they wanted to steal. That doesn't map at all to the proposed "infinite stream of EHLOs" attack.
- entropyie 1y ago
  If it's your connection, why on earth would you want to break the crypto? You already have the keys and the message...

I try to keep all of my mails to just under 31GB.

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 1y 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 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 ago
    The 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 ago
  Search 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..)
  - jsnell 1y ago
    In your example, the attacker already has the session key for the TLS connection, so they don't need to run this attack to decrypt the traffic on that connection. And running the attack does not help them decrypt any other connections. Sweet32 depended on the attacker being able to send an arbitrary amount of traffic over a connection where they did not control either of the endpoints, and with that connection also carrying the data they wanted to steal. That doesn't map at all to the proposed "infinite stream of EHLOs" attack.
entropyie 1y ago
If it's your connection, why on earth would you want to break the crypto? You already have the keys and the message...