[Top] [All Lists]

Re: [ietf-smtp] [Shutup] Compressing SMTP streams

2016-02-09 03:57:37
On 08/02/2016 18:07, Martijn Grooten wrote:
These kinds of attacks are the reason why people say that compression and encryption don't go together, even if you are technically right that it's all compression's fault. So perhaps it would be better to say: if it's sensitive, don't compress it.

You can't say that...

If 'compression and encryption don't go together', then you have to stop people sending JPG, DOCX, ZIP, GIF etc files as well. Those are compressed, and they are sent over encrypted links.

Should HTTPS servers stop delivering JPEG files? Do we force people to download images as BMP files?

No, because it's not that 'compression and encryption don't go together', but that compression can be used *in a very specific way* to help find out the content of the encrypted data. It does not break the encryption, and it is not a weakness of the encryption.

(AFAICT, CRIME/etc will not help determine the content of JPG/DOCX/etc files. It is purely "if I send known data along with unknown data and can tell the compressed size, then, after lots of tries I can guess what the unknown data is that was sent with my known data". If I am simply receiving something that I have no control over (or sniffing a stream that I can't inject into), then I have nothing to work with, and the data is safe. SMTP is just "receiving something".)

As far as I can see, the CRIME method isn't really even an 'attack on HTTPS'. It's actually an attack on the web browser. If you write a standalone 'CRIME client' it'd be useless. The CRIME attack is attempting to determine the cookies stored in a web browser. It doesn't allow the attacker to determine the content downloaded from the HTTPS server, just the cookie content sent by the browser. It's very specific, and there's nothing like it, even in concept, in SMTP.

This is all true. I can't see how a CRIME-like attack on SMTP+TLS could work either. But cryptography tends to set itself very high standards, in which "I can't see how" just isn't good enough.

But it is.

I "can't see how" TLS can be snooped on usefully, but that doesn't mean we throw it away. You can't prove a negative. Until someone has discovered a weakness, or at least a theoretical weakness, then you have to assume it's good enough.

All the documentation I've found on CRIME/etc require specific behaviour, which is just not there in SMTP. I may be wrong, and someone may have worked out a theoretical way to exploit compression in SMTP, but just saying 'there may be a way to break this that no one's discovered yet' isn't (IMHO) a good enough reason not to do something. Otherwise we may as well just abandon all attempts at encryption, as there may be ways to break those that no one has discovered yet.

Until someone comes up with an SMTP extension which lets a third party say to an unrelated MTA "send that last message again with this arbitrary data added at the start" (so it can be sniffed to try to determine the newly compressed message size and compare it to other compressed sizes of the same message with different data at the start), then I can't see how CRIME or anything like it could work with SMTP.

It has to be a third party telling the MTA to send again, because the two MTAs involved in the transaction can already see the uncompressed/unencrypted data, so any attempt for them to do a 'CRIME-like' attack is totally pointless. In CRIME, there are three parties involved - the browser, the server and the page content/script. it's this third thing which does the attack. In SMTP there are (currently) only two, so there is no agent available to perform the attack.

ietf-smtp mailing list