Eireocean Absent Member.
Absent Member.
283 views

Nessus LDAP Scan Results - SSL

Morning,

We often have Nessus scans performed against our servers and the common vulnerabilities are as follows :


  • SSL Certificate Signed Using Weak Hashing Algorithm
  • SSL Medium Strength Cipher Suites Supported
  • SSL Certificate Cannot Be Trusted
  • SSL Self-Signed Certificate
  • SSL Null Cipher Suites Supported
  • SSL Weak Cipher Suites Supported
  • SSL/TLS EXPORT_RSA <= 512-bit Cipher Suites Supported (FREAK)



Now we are correcting the certificate issue but the main query involves why SSL is available via port 389 and why it is available in general even though it has been disabled. Only feedback I have found is that the scan is a false positive because it is not usable and is there for backward compatibility.

Regards

Shaun
Labels (1)
0 Likes
2 Replies
Knowledge Partner
Knowledge Partner

Re: Nessus LDAP Scan Results - SSL

On 02/20/2019 12:14 AM, Eireocean wrote:
>
> Morning,
>
> We often have Nessus scans performed against our servers and the common
> vulnerabilities are as follows :
>
> - SSL Certificate Signed Using Weak Hashing Algorithm


This indicates your certificate came from an older version of eDirectory.
I am going to guess you are on eDirectory 8.8, or maybe even older, or at
least that you were on that version when certificates were minted. The
world has changed dramatically in its tolerance of things like SHA1 and
various ciphersuites, particularly since 2013, and since CAs last for ten
(10) years by default (if not longer manually) then this is certainly
possible, even if you happen to upgrade eDirectory today without also
recreating certs.

> - SSL Medium Strength Cipher Suites Supported


This is something you can configure from the LDAP Server (I think, or LDAP
Group) object linked to this NCP (eDirectory) Server object. You can
change out to High strength ciphersuites, or disable the TCP 389 port
entirely, in which case it should not be open at all, so something is
amiss there for you.

> - SSL Certificate Cannot Be Trusted


You can fix this if you want, but it's likely all about being from a
trusted third-party CA like Digicert, and if that's not the case then
you'll see this, but that's all it means.

> - SSL Self-Signed Certificate


Same as the previous comment, likely.

> - SSL Null Cipher Suites Supported


This is very odd; it means you are not setting things as you should,
locking down ciphersuites on those LDAP objects mentioned above. Do this,
for sure.

> - SSL Weak Cipher Suites Supported


Same as the previous comment, maybe coupled with a need to upgrade to a
current (9.x) version of eDirectory.

> - SSL/TLS EXPORT_RSA <= 512-bit Cipher Suites Supported (FREAK)


Same as the previous comment.

> Now we are correcting the certificate issue but the main query involves
> why SSL is available via port 389 and why it is available in general
> even though it has been disabled. Only feedback I have found is that the
> scan is a false positive because it is not usable and is there for
> backward compatibility.


This should not be the case. There is the option to disable the port
entirely, and it will not open (for listening) if done, so pursue that.
Disabling this way has been an option since at least eDirectory 8.7, if
not 8.6, which was current a couple decades ago.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Nessus LDAP Scan Results - SSL

Could the "SSL is available via port 389" be because it is configured to
support the start_tls against port 389?



On 2/20/19 7:00 AM, ab wrote:
> On 02/20/2019 12:14 AM, Eireocean wrote:
>>
>> Morning,
>>
>> We often have Nessus scans performed against our servers and the common
>> vulnerabilities are as follows :
>>
>> - SSL Certificate Signed Using Weak Hashing Algorithm

>
> This indicates your certificate came from an older version of eDirectory.
> I am going to guess you are on eDirectory 8.8, or maybe even older, or at
> least that you were on that version when certificates were minted. The
> world has changed dramatically in its tolerance of things like SHA1 and
> various ciphersuites, particularly since 2013, and since CAs last for ten
> (10) years by default (if not longer manually) then this is certainly
> possible, even if you happen to upgrade eDirectory today without also
> recreating certs.
>
>> - SSL Medium Strength Cipher Suites Supported

>
> This is something you can configure from the LDAP Server (I think, or LDAP
> Group) object linked to this NCP (eDirectory) Server object. You can
> change out to High strength ciphersuites, or disable the TCP 389 port
> entirely, in which case it should not be open at all, so something is
> amiss there for you.
>
>> - SSL Certificate Cannot Be Trusted

>
> You can fix this if you want, but it's likely all about being from a
> trusted third-party CA like Digicert, and if that's not the case then
> you'll see this, but that's all it means.
>
>> - SSL Self-Signed Certificate

>
> Same as the previous comment, likely.
>
>> - SSL Null Cipher Suites Supported

>
> This is very odd; it means you are not setting things as you should,
> locking down ciphersuites on those LDAP objects mentioned above. Do this,
> for sure.
>
>> - SSL Weak Cipher Suites Supported

>
> Same as the previous comment, maybe coupled with a need to upgrade to a
> current (9.x) version of eDirectory.
>
>> - SSL/TLS EXPORT_RSA <= 512-bit Cipher Suites Supported (FREAK)

>
> Same as the previous comment.
>
>> Now we are correcting the certificate issue but the main query involves
>> why SSL is available via port 389 and why it is available in general
>> even though it has been disabled. Only feedback I have found is that the
>> scan is a false positive because it is not usable and is there for
>> backward compatibility.

>
> This should not be the case. There is the option to disable the port
> entirely, and it will not open (for listening) if done, so pursue that.
> Disabling this way has been an option since at least eDirectory 8.7, if
> not 8.6, which was current a couple decades ago.
>


--
tBM
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.