• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion
  • Inviting everyone to the UX test of a new security feature in the WP Toolkit
    For WordPress site owners, threats posed by hackers are ever-present. Because of this, we are developing a new security feature for the WP Toolkit. If the topic of WordPress website security is relevant to you, we would be grateful if you could share your experience and help us test the usability of this feature. We invite you to join us for a 1-hour online session via Google Meet. Select a convenient meeting time with our friendly UX staff here.

PCI compliance still fails due to SSL Renegotiation DoS vulnerability in Qmail/IMAP

DragonAss

New Pleskian
For over 6 months now, PCI scanners have been failing us for being vulnerable (via Qmail and Courier IMAP only --> other daemons ok) with regards to the following issue...

SSL renegotiation DoS CVE-2011-1473 which is very similar to CVE-2011-5094. Both of these also say they're *DISPUTED* and a note on each reads: "It can also be argued that it is the responsibility of server deployments, not a security library, to prevent or limit renegotiation when it is inappropriate within a specific environment."

Okay. I've checked the documentation for both Qmail and Courier IMAP but didn't see anything regarding configuration of SSL renegotiation. I think Courier uses SSL/TLS for security and Qmail fires up STARTTLS but, other than that, I've got NO idea how to alter/patch either one, much less have it all playing nice with Plesk. It seems like OpenSSL should play a role here somewhere too (perhaps those other daemons use it?) but it's high time I reach out for more clues.


Please note: this is NOT the same as the BEAST attack / CVE-2011-3389. That one has been addressed by updated ciphers, tweaking httpd.conf, etc. as seen in the basic Plesk PCI Compliance Guide/Tool.

ANY ideas or advice greatly appreciated!
Should I consider Postifix? :)
 
I would suggest postfix. Alternatively, you should no issues implementing a compensating control to explain away the vulnerability. If you need some help, give us a call. Night Lion Security can help with PCI Compliance Consulting.
 
Thanks for the feedback VinnyT (your site is now bookmarked for the decision makers around here).

So far, I plan to keep using ipfilter rule(s) to block any such attack attempts. Unfortunately, we're "not allowed" to block the IP address of our PCI scanner's server, but I could send'em the details of our server config/setup and ask'em to disregard this issue as a false positive. If that doesn't work... then I'll try Postfix. :eek:)

If anyone else is in a similar situation and/or interested in "howto block renegotiation using ipfilter", see:
Rate limiting SSL handshakes

Anyone know a quick & dirty configuration option that'll work for Qmail and/or Courier IMAP directly?
<fingers X'd>
 
Back
Top