<div dir="ltr"><div dir="ltr">And just to add to my confusion, this seems that it only checks when STARTTLS is actually requested but not used?</div><div dir="ltr">This code really needs revised documentation.<div><pre style="color:rgb(0,0,0)"><span class="gmail-new" style="color:blue">+        // If current connection is not encrypted, and context seen to be secured with STARTTLS</span>
<span class="gmail-new" style="color:blue">+        // or 'mechsAllowedToSendCredentials' is set to any value via system/context environment properties</span>
<span class="gmail-new" style="color:blue">+        if (!isConnectionEncrypted() && (contextSeenStartTlsEnabled || anyPropertyIsSet)) {</span></pre></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mi., 21. Okt. 2020 um 19:26 Uhr schrieb Bernd <<a href="mailto:ecki@zusammenkunft.net">ecki@zusammenkunft.net</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">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?<div><br></div><div><span style="color:blue"> if ("simple".equalsIgnoreCase(authMechanism) && !envprops.containsKey(SECURITY_PRINCIPAL)) {</span><br></div><div><span style="color:blue"><br></span></div><div><span style="color:blue">Gruss</span></div><div><span style="color:blue">Bernd</span></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mi., 21. Okt. 2020 um 18:21 Uhr schrieb Bernd <<a href="mailto:ecki@zusammenkunft.net" target="_blank">ecki@zusammenkunft.net</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><font face="arial, sans-serif">Hello,</font><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">I am looking at 11.0.9 PSU  (as of Zulu 11.43-sa) about the </font><span style="color:rgb(37,37,37);font-family:"Red Hat Text",Overpass,Helvetica,sans-serif;font-size:16px">CVE-2020-14781</span><font face="arial, sans-serif"> / </font><span style="background-color:rgb(251,249,248);color:rgb(0,0,0);font-family:OracleSansVF,OracleSansVFCyGr,-apple-system,BlinkMacSystemFont,"Segoe UI","Helvetica Neue",sans-serif;font-size:16px;text-align:-webkit-right">JDK-8237990 </span><span style="font-family:arial,sans-serif">fix and try to understand if my customers might be affected.</span></div><div><span style="font-family:arial,sans-serif"><br></span></div><div><pre style="white-space:pre-wrap;margin:1em;padding-bottom:1em;color:rgb(0,0,0)">jdk.jndi.ldap.mechsAllowedToSendCredentials</pre></div><div><span style="font-family:arial,sans-serif">It was not obvious to </span>me, how<span style="font-family:arial,sans-serif"> the mechanism restriction works.</span><br></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">According to Oracle and Redhat release notes it only looks at clear / non-TLS.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">- Can you confirm that SASL with wrapping is not considered as encrypted in this case?</font></div><div><br></div><div><font face="arial, sans-serif">- Can you confirm it only applies to SASL based negotiation? (in my test SIMPLE with cleartext passwords works just fine)</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">- Can you confirm it does not apply to "secure" mechanisms like DIGEST-MD5 or different methods like GSSAPI or SIMPLE?</font></div><div><br></div><div><font face="arial, sans-serif">Gruss</font></div><div><font face="arial, sans-serif">Bernd</font></div></div></div></div></div></div>
</blockquote></div>
</blockquote></div>