Remediation Guides

SSL Anonymous Cipher Suites Supported (Nessus 31705): How to Fix It

26 September 2026 8 min read

SSL Anonymous Cipher Suites Supported (Nessus plugin 31705) means a TLS service accepts cipher suites that skip server authentication, such as the ADH and AECDH suites, so an on-path attacker can impersonate it. Fix it by adding !aNULL to the service’s cipher string (for Postfix, smtpd_tls_exclude_ciphers = aNULL), reloading the service and rescanning.

What the scanner is actually detecting

Nessus connects to each TLS service it finds and checks whether the server will complete a handshake with an anonymous cipher suite. In these suites the key exchange is unauthenticated Diffie-Hellman (DH or ECDH): the server sends no certificate and signs nothing. The session is encrypted, yet the client has no way to know who is on the other end.

Scanner ID Finding title Severity
Nessus Plugin 31705 SSL Anonymous Cipher Suites Supported Medium (CVSS v3 5.9, CVSS v2 2.6)

Tenable files the plugin under Service detection, first published it in March 2008 and links it to CVE-2007-1858, an old Apache Tomcat issue where the default SSL cipher configuration included an anonymous cipher. The check is generic and applies to any product; the plugin output names the flagged port.

In OpenSSL naming, three aliases cover these suites:

Alias What it matches Example suite
aNULL Every suite with no authentication: anonymous DH and anonymous ECDH All of the below
ADH Anonymous DH only (not the ECDH variants) ADH-AES256-GCM-SHA384 (TLS_DH_anon_WITH_AES_256_GCM_SHA384)
AECDH Anonymous ECDH only AECDH-AES256-SHA (TLS_ECDH_anon_WITH_AES_256_CBC_SHA)

Anonymous suites exist only in TLS 1.2 and earlier. TLS 1.3 has none, so you do not need to touch your protocol versions to fix this.

Real-world risk

Tenable’s description is accurate: an anonymous suite leaves the service open to a man-in-the-middle attack. An attacker who can intercept the traffic runs one handshake with the client and another with the server, then reads or alters everything in between. A purely passive eavesdropper still sees only ciphertext.

Two conditions have to line up. The attacker needs a position on the network path (same LAN segment, a compromised router, ARP or DNS spoofing), and the client has to offer an anonymous suite. Clients built on OpenSSL 1.1.0 or later refuse unauthenticated suites at their default security level, so the realistic exposure is older libraries, embedded clients, custom scripts and server-to-server mail.

Mail servers deserve a calmer reading. Postfix documents that its SMTP server enables anonymous ciphers by default and describes excluding them as generally unnecessary, because a server cannot force a sending server to verify its certificate in the first place. Removing them is still cheap, but a public MX flagged by plugin 31705 is not an emergency. The fix matters more on internal services that carry credentials, such as SMTP submission, LDAP or admin interfaces.

How to confirm it on the host

From any machine with Nmap, enumerate the accepted suites. The script handles STARTTLS on port 25 by itself:

nmap -sV --script ssl-enum-ciphers -p 25,443,465,587 host.example.com

Anonymous suites appear with _anon_ in the name, and the script adds the warning Anonymous key exchange, score capped at F.

To test directly with OpenSSL, ask for anonymous suites only:

openssl s_client -connect host.example.com:443 -tls1_2 -cipher 'aNULL:@SECLEVEL=0' </dev/null
openssl s_client -connect mail.example.com:25 -starttls smtp -tls1_2 -cipher 'aNULL:@SECLEVEL=0' </dev/null

A vulnerable server completes the handshake with a line such as Cipher is ADH-AES256-GCM-SHA384 and reports no peer certificate available. A fixed server returns a handshake failure alert (SSL alert number 40). Keep @SECLEVEL=0 in the command: on OpenSSL 1.1.0 or later the local client otherwise refuses to offer anonymous suites and prints no ciphers available, which says nothing about the server.

testssl.sh gives the same answer in its cipher category check, where the anonymous NULL ciphers line should read not offered:

testssl.sh -s host.example.com:443
testssl.sh -t smtp -s mail.example.com:25

On the server, find the cipher string in use and expand it. Every line with Au=None is an anonymous suite:

grep -Rn 'SSLCipherSuite|ssl_ciphers' /etc/httpd /etc/apache2 /etc/nginx 2>/dev/null
postconf smtpd_tls_exclude_ciphers smtpd_tls_mandatory_exclude_ciphers smtpd_tls_ask_ccert
openssl version
openssl ciphers -v 'HIGH:!MD5' | grep 'Au=None'

The last command shows the usual root cause: HIGH and ALL on their own include anonymous suites, while DEFAULT excludes them. OpenSSL 1.1.0 and later also reject unauthenticated suites at the default security level (1) even when the string lists them, so an OpenSSL-based service that still offers them is usually on OpenSSL 1.0.x, has @SECLEVEL=0 in its cipher string, or lowers the level itself, as Postfix does for opportunistic TLS.

How to fix it

The rule for any OpenSSL cipher string

Add !aNULL. The ! prefix removes those suites permanently, so later entries in the same string cannot add them back. Do not rely on !ADH, which leaves the AECDH suites in place, and delete any @SECLEVEL=0 unless you have a documented reason for it. A strict allow-list such as ECDHE+AESGCM:ECDHE+CHACHA20 also works, because the ECDHE alias only matches authenticated ephemeral ECDH. Check any string before you deploy it; this must print nothing:

openssl ciphers -v 'HIGH:!aNULL:!MD5' | grep 'Au=None'

nginx

The built-in default is HIGH:!aNULL:!MD5, so nginx only offers anonymous suites if a custom ssl_ciphers dropped the exclusion. Fix every occurrence, including stream and mail blocks:

grep -Rn ssl_ciphers /etc/nginx/
# in each server block:
ssl_ciphers HIGH:!aNULL:!MD5;

Then run nginx -t and systemctl reload nginx.

Apache httpd

Since version 2.4.7, mod_ssl adds !aNULL:!eNULL:!EXP to every cipher string automatically, so a current httpd cannot offer anonymous suites. If an Apache host is flagged, check apachectl -v. On an older release, plan the upgrade and set this in the meantime:

SSLCipherSuite HIGH:!aNULL:!MD5

Run apachectl configtest, then apachectl graceful. If it is current, something else on that port, such as a proxy in front, is offering them.

Postfix

Postfix enables anonymous ciphers on its SMTP server by default and only suppresses them when it asks clients for certificates, which makes mail relays an obvious first place to look. Exclude them explicitly:

postconf -e 'smtpd_tls_exclude_ciphers = aNULL'
postconf -P | grep -i tls
postfix reload

smtpd_tls_exclude_ciphers applies at all TLS security levels, so it covers both opportunistic and mandatory TLS. It is a plain list, not an OpenSSL cipher string, so write aNULL without the !. The postconf -P output shows master.cf overrides; a submission (587) or smtps (465) entry with its own -o smtpd_tls_exclude_ciphers= value overrides main.cf for that service.

Setting smtpd_tls_ask_ccert = yes also removes them, but Postfix notes that some MTAs abort when asked for a client certificate, so the exclusion is safer.

Java and Tomcat

Current OpenJDK releases ship with anon and NULL in jdk.tls.disabledAlgorithms, and Tomcat’s default SSLHostConfig ciphers value already contains !aNULL. A flagged Java service usually has an old bundled runtime, an edited java.security file ($JAVA_HOME/conf/security/, or jre/lib/security/ on Java 8), or an explicit ciphers list naming anonymous suites. Update the runtime or restore anon to the disabled list, fix the cipher list, and restart.

Windows, load balancers and appliances

Microsoft’s Schannel cipher suite tables contain no anonymous suites, so IIS, RDP and other Schannel services do not trigger this plugin. On Windows, look for a third-party service with its own TLS library, such as Java or an OpenSSL build. If TLS terminates on a load balancer or appliance, change its cipher profile there; the backend’s settings never reach the client.

How to verify the fix and rescan

  1. Expand the new cipher string with openssl ciphers -v '...' | grep 'Au=None' and confirm it prints nothing.
  2. Rerun the openssl s_client ... -cipher 'aNULL:@SECLEVEL=0' test against every flagged port and confirm a handshake failure.
  3. Rerun nmap --script ssl-enum-ciphers and confirm no _anon_ suite or anonymous key exchange warning remains.
  4. Run a targeted Nessus rescan with the same policy and confirm plugin 31705 is gone for that host and port.

What can break and how to roll back

  • Clients that only offer anonymous suites. They are rare, but their handshakes will fail, and Postfix warns that some SMTP clients do not fall back to plaintext after a TLS handshake failure, so their mail may stay queued.
  • Check first. With smtpd_tls_loglevel at 1 or higher, Postfix logs the negotiated cipher for each session. Search before the change: grep -E 'with cipher (ADH|AECDH)-' /var/log/maillog /var/log/mail.log. The word “Anonymous” at the start of those log lines only means the client sent no certificate; the cipher name is what counts.
  • Rollback on Postfix: postconf -X smtpd_tls_exclude_ciphers, then postfix reload.
  • Rollback on nginx, Apache and Java: restore the previous configuration file and reload or restart the service.

Common false positive reasons

  • No reload yet. The file is correct but the running process still uses the old cipher list.
  • A different port. Port 443 is clean, but 25, 465, 587 or a management port still offers anonymous suites; the plugin output names the port.
  • A master.cf override. One Postfix service keeps its own exclude list.
  • Something in front of the host. The scanner reached a load balancer or TLS-inspecting proxy, not the server you changed.
  • A misleading local test. An openssl s_client check without @SECLEVEL=0 fails on the client side and looks like a pass while the server still offers the suites.

FAQ

Is an anonymous cipher the same as a NULL cipher?

No. aNULL suites encrypt without authenticating the server; eNULL suites do not encrypt at all. Exclude each separately.

Is !ADH enough?

No. ADH matches anonymous DH only and leaves the anonymous ECDH (AECDH) suites enabled. Use !aNULL, which covers both.

Does TLS 1.3 have anonymous cipher suites?

No. They exist only in TLS 1.2 and earlier, so TLS 1.3 clients are unaffected by the change.

Do I have to fix this on a public mail server?

The practical gain there is small, because a mail server cannot force senders to verify its certificate. The change is one Postfix parameter and removes a recurring Medium finding, so it is usually worth making unless a known peer depends on anonymous TLS. If you are also reviewing the certificates that make authentication possible, see our guide to building a TLS certificate inventory.

Tracking this finding across many hosts

Plugin 31705 can appear on many mail relays and internal services at once. SITEY is a self-hosted vulnerability management platform that imports findings from 16 scanners, with Nessus results brought in by uploading a .nessus export; duplicates are merged per scanner, not across scanners. Per-finding retest is available for Nessus findings, and its AI can write host-specific remediation scripts that its agents run on Windows and Linux endpoints only after human approval.

Sources

SITEY closes the loop, not just the report.Discover, validate, fix and verify in your own infrastructure.

See pricing