SSLv3 POODLE Vulnerability Fix: Disable SSL 2.0 and 3.0 (Nessus 20007, 78479)

SSL Version 2 and 3 Protocol Detection means a service on the host still completes handshakes using SSL 2.0 or SSL 3.0, protocols broken by attacks such as POODLE (CVE-2014-3566) and DROWN. To fix it, disable both protocols: set the Schannel registry values on Windows, restrict SSLProtocol or ssl_protocols on Apache and nginx, update appliance firmware, then rescan.

What the scanner is actually detecting

Each scanner below offers an SSL 2.0 or SSL 3.0 handshake to a TLS-capable port. If the service negotiates that version, the finding fires. It is reported per port, so one host can carry it on 443, a mail port, LDAPS and a management interface at once.

The detection and POODLE findings share one root cause and one fix: once SSL 3.0 is off, the POODLE entries clear too. Expect severities to disagree. Tenable rates plugin 20007 Critical, while its dedicated POODLE plugin 78479 is rated Low. Prioritize by where the port is reachable from, not by the label alone.

Real-world risk

POODLE is a padding oracle attack on SSL 3.0’s CBC mode. The attacker needs a man-in-the-middle position and a way to make the victim’s client send many requests; Microsoft’s advisory notes the attacker must make several hundred HTTPS requests before the attack could succeed. The payoff is decrypted bytes such as session cookies. Current browsers no longer offer SSL 3.0, so the realistic exposure today is legacy and non-browser clients that still negotiate it.

SSL 2.0 is the more serious half. DROWN (CVE-2016-0800) lets an attacker use a server that accepts SSL 2.0 to decrypt TLS sessions that use the same RSA key, even when those sessions run on a different server. SSL 3.0 is also formally deprecated: RFC 7568 states that SSLv3 must not be used. For cardholder environments, SSL does not count as strong cryptography under PCI DSS, so this finding will also block a clean result in your PCI DSS Requirement 11.3 internal and ASV scans.

How to confirm it on the host

Reproduce the finding from a machine that can reach the flagged port:

# Protocol versions and ciphers offered on the port (look for an "SSLv3:" section)
nmap -sV --script ssl-enum-ciphers -p 443 host.example.com

# SSL 2.0 specifically
nmap -sV --script sslv2 -p 443 host.example.com

# Direct SSL 3.0 handshake attempt
openssl s_client -connect host.example.com:443 -ssl3

Treat the -ssl3 test with care: the OpenSSL documentation notes that not all protocol options are available, depending on how it was built. An “unknown option” error or instant failure from a build without SSL 3.0 proves nothing about the server.

Next, find which software owns the port, since that decides where the fix goes:

# Windows
Get-NetTCPConnection -LocalPort 443 -State Listen | Select-Object LocalAddress, OwningProcess
Get-ItemProperty 'HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Server'

# Linux
ss -ltnp 'sport = :443'

If the SSL 3.0 key does not exist, Windows uses its built-in default. According to Microsoft, SSL 3.0 is disabled by default from Windows 10 version 1607 and Windows Server 2016 onward, and SSL 2.0 is not supported at all on those versions. On Windows Server 2012 R2 and earlier, SSL 3.0 is enabled by default on the server side. A flagged 2016 or later host therefore usually has Enabled = 1 set explicitly, or the port is served by a non-Schannel stack such as a Java application server or software that bundles its own OpenSSL.

How to fix it

Windows Server and IIS (Schannel)

Back up the protocol keys first, then disable SSL 2.0 and SSL 3.0 for the server role and restart:

reg export "HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols" C:schannel-protocols.reg /y

$base = 'HKLM:SYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocols'
foreach ($proto in 'SSL 2.0', 'SSL 3.0') {
    $key = "$base$protoServer"
    if (-not (Test-Path $key)) { New-Item -Path $key -Force | Out-Null }
    New-ItemProperty -Path $key -Name 'Enabled' -Value 0 -PropertyType DWord -Force | Out-Null
    New-ItemProperty -Path $key -Name 'DisabledByDefault' -Value 1 -PropertyType DWord -Force | Out-Null
}
Restart-Computer

Microsoft’s POODLE advisory (3009008) only requires Enabled = 0 under SCHANNELProtocolsSSL 3.0Server; many hardening baselines also add DisabledByDefault = 1, as above. The advisory calls for a restart because services reuse Schannel credential handles until they restart. The same values under a Client subkey stop outbound SSL 3.0; test that separately.

Schannel protocol values have no dedicated Group Policy setting. For a fleet, push them as Group Policy Preferences registry items (Computer Configuration > Preferences > Windows Settings > Registry) or with your configuration management tool.

Apache httpd (mod_ssl)

Since Apache 2.4.17 the default is SSLProtocol all -SSLv3, so a flagged 2.4 server almost always has an explicit override somewhere. Find it, replace it, and reload:

grep -Rni "SSLProtocol" /etc/httpd /etc/apache2 2>/dev/null

# Global SSL config and every <VirtualHost *:443>
SSLProtocol -all +TLSv1.2 +TLSv1.3

apachectl configtest && apachectl graceful

TLSv1.3 requires OpenSSL 1.1.1 or later; drop it from the line on older builds. If Apache proxies to TLS back ends, check SSLProxyProtocol too.

nginx

nginx disabled SSLv3 by default in version 1.9.1, so a flagged nginx server has SSLv3 listed explicitly:

grep -Rn "ssl_protocols" /etc/nginx

# In the http {} block (and in mail {} or stream {} if you terminate TLS there)
ssl_protocols TLSv1.2 TLSv1.3;

nginx -t && nginx -s reload

Set it at the http level. The nginx documentation warns that when the directive is set per server, the value from the default server for that address and port can be used instead.

Appliances, load balancers and embedded devices

For firewalls, printers, BMCs, storage arrays and OT gear, apply a firmware update first, then raise the minimum TLS version in the management UI. On load balancers, change the client-facing SSL profile, since that is what the scanner talks to. If a device cannot be fixed, restrict its management port to an admin network and document the exception. Probe these devices gently; see our guide to scanning fragile OT and embedded devices.

If SSL 3.0 has to stay for a while: TLS_FALLBACK_SCSV

Tenable’s solution for 78479 allows TLS Fallback SCSV (RFC 7507) as a stopgap on services that must keep SSLv3. It stops an attacker from forcing a downgrade from TLS to SSL 3.0. OpenSSL added it in 1.0.1j, 1.0.0o and 0.9.8zc, so check the library version the service actually loads, not just the system package (openssl version shows the command-line build). It only works when both client and server support it, it does nothing for clients that can only speak SSL 3.0, and SSL 3.0 remains enabled, so 20007 stays open. To test, offer a version below the server’s highest (here TLS 1.2 against a TLS 1.3 server); a server that supports SCSV answers with an inappropriate fallback alert:

openssl s_client -connect host.example.com:443 -tls1_2 -fallback_scsv

How to verify the fix and rescan

1. Rerun nmap --script ssl-enum-ciphers and --script sslv2 against every port listed in the original finding. The SSLv3 section and the SSLv2 output should be gone.
2. On Windows, confirm the registry values with Get-ItemProperty and that the host was restarted after the change.
3. Rescan with the same scanner and policy. Nessus 20007 and 78479, Qualys QID 38606 and 38603, and both Greenbone NVTs should no longer report for those ports.

What can break and how to roll back

• Clients that only speak SSL 3.0 (very old browsers, embedded clients, legacy SDKs) will fail to connect. With TLS 1.2 as the minimum, as in the Apache and nginx lines above, TLS 1.0 and 1.1 clients fail too, so check access logs for old protocol versions first.
• The Schannel change is server-wide. Microsoft notes it disables SSL 3.0 for all server software on the system, IIS included.
• Rollback on Windows: Microsoft’s documented undo is deleting the subkey and restarting: reg delete "HKLMSYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Server" /f.
• Rollback on Apache or nginx: restore the previous directive, run apachectl configtest or nginx -t, then reload.

Common false positive reasons

True false positives are rare, since the scanner must negotiate the old protocol to report it. “Fixed but still flagged” usually means one of these:

• TLS terminates in front of the host. A load balancer, WAF or reverse proxy answers on the scanned address, so the fix belongs there.
• No restart. Schannel services and web servers keep using the old settings until they are restarted or reloaded.
• nginx default server. The default server’s ssl_protocols value can apply to other server blocks on the same address and port.
• A different port or stack. Mail STARTTLS, LDAPS, database ports, a Java service on Windows or a bundled OpenSSL each need their own fix.
• Misleading homemade checks. Microsoft documents that all Windows versions accept an SSLv2-format ClientHello even when SSL 2.0 is disabled, so a script that only checks whether the server replied can falsely report SSL 2.0.

FAQ

Does enabling TLS_FALLBACK_SCSV close Nessus 20007?

No. SCSV blocks forced downgrades, but SSL 3.0 is still accepted, which is exactly what 20007 detects. Only disabling SSL 2.0 and 3.0 closes it.

Is SSL 3.0 enabled by default on Windows Server?

Not on Windows Server 2016 or later, where it is disabled by default and SSL 2.0 is not supported at all. On Windows Server 2012 R2 and earlier, SSL 3.0 is enabled by default on the server side.

Do I need to reboot after changing the Schannel registry keys?

Microsoft’s advisory says to restart the computer. At minimum, every Schannel-based service must restart.

Should I disable TLS 1.0 and 1.1 at the same time?

This finding only needs SSL 2.0 and 3.0 off; TLS 1.0 and 1.1 raise separate findings. Tenable recommends TLS 1.2 or higher, so going straight there saves a second change window if your clients support it.

Tracking this finding across many hosts

When this finding turns up on dozens of hosts from more than one scanner, a self-hosted platform such as SITEY can import the Nessus, Qualys and Greenbone results into one queue, although duplicates are merged per scanner, so a Nessus and a Qualys record for the same port stay separate. It can also generate host-specific registry or configuration scripts that its agents run on Windows and Linux endpoints only after a human approves them, then retest to confirm closure (per-finding retest is available for Nessus results).

Sources

• Tenable: Nessus plugin 20007, SSL Version 2 and 3 Protocol Detection
• Microsoft Security Advisory 3009008: Vulnerability in SSL 3.0 Could Allow Information Disclosure
• Microsoft Learn: Protocols in TLS/SSL (Schannel SSP)
• Apache HTTP Server: mod_ssl SSLProtocol directive
• nginx: ngx_http_ssl_module ssl_protocols directive