This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

V 9.706-9: The return of weak ciphers?

Today I've received the result of a PCI scan: Failed.

"38142 - SSL Server Allows AnonymousAuthentication Vulnerability" on port 25 is the reason. 38142 means that ADH or similar weak ciphers are allowed.

As far as I remember with the setting "TLS1.2 only" all weak ciphers are removed.

What can I do?

This thread was automatically locked due to age.
  • FormerMember
    0 FormerMember

    Hi ,

    Thank you for reaching out to the Community! 

    Could you please provide more information regarding this PCI scan and the email protection configuration on your UTM? 

    What did you configure under Email Protection > SMTP > Advanced > TLS settings? Is there any DNAT rule on port 25? If possible, send me the complete scan result by sending a personal message.


  • Hi,

    I've send the report as a PM.

    Under Email Protection > SMTP > Advanced > TLS settings I've configured the actual certificate and below TLS v1.2.

    There is no DNAT for port 25.

  • FormerMember
    0 FormerMember in reply to gsxfan

    Hi ,

    I didn't get your personal message. Could you please re-send it? 


  • As a temporary workaround, while this is being investigated, if you can SSH to your UTM and get root access, you can edit /var/storage/chroot-smtp/etc/exim.conf.

    Look for the line that reads:

    tls_require_ciphers = HIGH:!RC4:!MD5:!ADH:!SSLv2

    and update it to

    tls_require_ciphers = HIGH:!RC4:!MD5:!ADH:!SSLv2:!aNULL

    This issue is not really to do with weak ciphers. Anonymous authentication in this context would allow a remote server, if it wanted to, to connect to your UTM without your UTM having to provide a certificate to prove its own identity. It really affects the remote server more than it does your UTM. 

  • Thanks Rich, that hit the nail. The scan passed today, right before my vacation starts.

    But like every change of config files at file level this would probably be changed by the next update (Or restart...). What I'm wondering about is that this error occurred for the very first time after more than 15 years of PCI scans against Astaro/Sophos UTM.

    I hope that this config change will find its way to the system by the next update. It should be standard and mandatory. Otherwise I (And probably others) will run into this trap again.

  • We released 9.707 last week, before becoming aware of this issue. It will likely be addressed in our next release.

    The workaround - manually editing the config file - will persist until the firmware is updated. If you apply 9.707 you will need to re-do the config file change. It will not be overwritten on restart or by changing other configuration through the UI.