ldap.mechsAllowedToSendCredentials - only SASL?

[Bernd]

And just to add to my confusion, this seems that it only checks when
STARTTLS is actually requested but not used?
This code really needs revised documentation.

+        // If current connection is not encrypted, and context seen
to be secured with STARTTLS+        // or
'mechsAllowedToSendCredentials' is set to any value via system/context
environment properties+        if (!isConnectionEncrypted() &&
(contextSeenStartTlsEnabled || anyPropertyIsSet)) {


Am Mi., 21. Okt. 2020 um 19:26 Uhr schrieb Bernd <ecki at zusammenkunft.net>:

> BTW: the security patch looks like "simple" is supposed to be rejected
> when a principal is set, however this is not the case in my tests. Maybe
> the method is not called correctly in this case?
>
>  if ("simple".equalsIgnoreCase(authMechanism) &&
> !envprops.containsKey(SECURITY_PRINCIPAL)) {
>
> Gruss
> Bernd
>
> Am Mi., 21. Okt. 2020 um 18:21 Uhr schrieb Bernd <ecki at zusammenkunft.net>:
>
>> Hello,
>>
>> I am looking at 11.0.9 PSU  (as of Zulu 11.43-sa) about the
>> CVE-2020-14781 / JDK-8237990 fix and try to understand if my customers
>> might be affected.
>>
>> jdk.jndi.ldap.mechsAllowedToSendCredentials
>>
>> It was not obvious to me, how the mechanism restriction works.
>>
>> According to Oracle and Redhat release notes it only looks at clear /
>> non-TLS.
>>
>> - Can you confirm that SASL with wrapping is not considered as encrypted
>> in this case?
>>
>> - Can you confirm it only applies to SASL based negotiation? (in my test
>> SIMPLE with cleartext passwords works just fine)
>>
>> - Can you confirm it does not apply to "secure" mechanisms like
>> DIGEST-MD5 or different methods like GSSAPI or SIMPLE?
>>
>> Gruss
>> Bernd
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20201021/8fa67099/attachment.htm>