Don't listen to brainless auditors wielding checklists. The CRIME
attack does not apply to SMTP, because unlike SMTP, there is no
email messages with chosen plaintext compressed together in
the same packet with SASL credentials or other sensitive data.
The auditor completely failed to take the context into account.
Postfix 2.11 will include the ability to disable compression and
session tickets if enabled by default in the OpenSSL library. You
should disable compression if it uses too much CPU, and laugh at
any claims that SMTP needs "CRIME-prevention". You may disable
session tickets if they cause breakage with your favourite NetBSD
The patch is unlikely to get adopted as a non-configurable work-around
for a non-problem.
On 05/14/2013 05:05 PM, Viktor Dukhovni wrote:
> Don't listen to brainless auditors wielding checklists.
Unfortunately you have to. They may be wrong but you're not going to
pass PCI compliance scans unless you jump through their stupid hoops. I
recommend that you don't put your MTA on the same server that you run
your ecommerce apps on anyways, then you don't have to worry about
passing PCI scans on the MTA.
As for this particular issue, I believe you can work around it to the
satisfaction of the auditors by disabling any CBC ciphers. You can use
the command, "openssl ciphers" for a list, and then set
smtpd_tls_exclude_ciphers to any that have CBC in the name. No need to
worry about smtp ciphers as the scanner can't detect those anyways.
On Tue, May 14, 2013 at 02:03:44PM +0200, Andreas Schiermeier wrote:
> Thank you Wietse and Viktor for your clarifications.
> I admit, there's absolutely no need for the patch past Postfix 2.8 with
> OpenSSL 1.x.
The SSL_OP_NO_COMPRESSION control is not part of SSL_OP_ALL
(bug-interop work-arounds enabled by default). Therefore, there
is nothing in new releases of either OpenSSL or Postfix to disable
What Postfix 2.8 provides is the ability to turn off some work-arounds,
which has no effect on compression (and thus "CRIME"). Before 2.8,
all work-arounds were enabled. Since your auditors want you to
jump through hoops (for no reason) to disable compression, if you
in fact must do this, just disable TLS support in Postfix, then
SSL compression is no longer on their checklist.
Turning off CBC ciphers while leaving TLS enabled will just create
a bunch of pain, as some sites turn off RC4 (which has its own
flaws) and TLSv1.2 modes are still not universally supported.
So your patch may apply to your site. When I supported OpenSSL
a few years back at my previous employer (we built from source),
I always disabled compression at compile time (it never seemed
like a good idea to me, and my uninformed bias was vindicated).
That's another option.
Better than all of these is to talk to the auditor and explain
that SMTP != HTTP, and CRIME is an attack on HTTP + SSL, not
SMTP + SSL. SMTP with compression, then SSL is far more secure
than SMTP with no SSL at all, which they would not even notice,
since most email is still not encrypted. Some auditors can be
made to succumb to basic logic.
>I'm confident our auditors will understand and accept the
>The finding comes from an automated scan.
>It's good to know 2.11 will include the ability to disable compression.
>Maybe I'll inform Ubuntu package maintainers about my patch, in case
>there is rising demand for jumping through "stupid hoops" :-).
Discussing that or how to document working around the "issue" would be useful. It would be a good topic to discuss on [hidden email].