Resolved How to fix the TLS Poodle PCI Compliance issue

[Edi Duluman]

Hello!

As the title suggests, I'm having trouble achieving a PCI Compliance scan from ControlScan, given they have partnered now with a payment processor that we use, PayVision.

I have dealt with all the other issues, and this would be the last one.

IP Address: 136.243.78.229
Host: www.agency.as
Path: 

THREAT REFERENCE

Summary: 
server is susceptible to POODLE attack over TLS

Risk: High (3)
Port: 465/tcp
Protocol: tcp
Threat ID: misc_tls_poodletls

Details: SSL POODLE Attack
12/22/14
CVE 2014-8730
Only the SSLv3 protocol, and not the TLS protocol, is affected by this vulnerability. However, some TLS implementations, most notably in F5 and A10 devices, are known to be affected due to failure to enforce the protocol. 
Furthermore, even those clients and servers which correctly support TLS may still allow sessions to be downgraded to SSLv3 to allow compatibility with older peers. An attacker may be able to force this downgrade to occur by intercepting and modifying packets during the protocol negotiation phase, thus facilitating the POODLE attack.
10/15/14
CVE 2014-3566
The SSLv3 protocol, when used with CBC ciphers, is susceptible to an attack known as Padding Oracle On Downgraded Legacy Encryption (POODLE). The vulnerability arises because the padding is not deterministic and is not covered by the Message Authentication Code (MAC) and therefore cannot be verified during decryption. This may allow an invalid, specially crafted stream of ciphertext to have a one in 256 chance of being accepted. Each time such a stream is accepted, one byte of the plaintext data can be inferred.
An attacker who is able to intercept SSL sessions (as in a man-in-the-middle attack) can exploit this vulnerability using javascript code which forces a user's browser to send HTTPS requests to a server, and then modifying these requests such that the desired plaintext byte is aligned with the end of a block. If this is done repeatedly, the desired plaintext byte will eventually become known, and the attacker can move on to the next byte, and then the next, until the desired plaintext (for example, the user's session ID) is known in its entirety.

Information From Target:
Service: urd
Sent:
TLSv1 request with invalid padding
Received:
220 mobilselskapet.no ESMTP Postfix (Debian/GNU)

I have done all the changes in the main.cf file, disabled SSLv2 and SSLv3 ( took a peek at ssl_v3_disable.sh ) from Plesk KB.

It is weird that COMODO's SSL Analyzer results into the following:

TLS v1.1 Supported   Immune to TLS POODLE
TLS v1.0 Supported   Immune to TLS POODLE
SSL v3.0 Not Supported   Immune to SSLv3 POODLE
SSL v2.0 Not Supported   Immune to DROWN

Then, Qualys SSL Test returns the following:

POODLE (SSLv3) No, SSL 3 not supported
POODLE (TLS) No
Downgrade attack prevention Yes, TLS_FALLBACK_SCSV supported

But then, ControlScan's Compliance test reuslts into:

server is susceptible to POODLE attack over TLS

Risk: High (3)
Port: 465/tcp
Protocol: tcp
Threat ID: misc_tls_poodletls

Information From Target:
Service: urd
Sent:
TLSv1 request with invalid padding
Received:
220 mobilselskapet.no ESMTP Postfix (Debian/GNU)

Any suggestions ? I know it's not Plesk's fault but it's worth asking.

Cheers!

 

[Linulex]

port 465 isnt used anymore for smtps. just close port 465 in your firewall and the error will go away.

as @UFFH01 pointed out in my own question about 465.

https://talk.plesk.com/threads/is-it-safe-to-close-port-465.340203/

regards
Jan

 

[Edi Duluman]

Thank you very much! I did not know what else to do in order to overcome that issue. I'm running the last scan now and we should be good to go! Will update this with the result. Thank you

LE: This fixed the issue, thank you!