Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 3 subscribers
  • Views 2613 views
  • Users 0 members are here
Options
Suggested
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?

gsxfan

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.
Parents
  • 0

    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. 

Reply
  • 0

    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. 

Children
  • 0 in reply to RichBaldry

    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.

  • 0 in reply to gsxfan

    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.

Unfiltered HTML