On Thu, 21 Aug 2025 18:44:26 GMT, Michael Osipov <d...@openjdk.org> wrote:
> My "here" was > > > Not an LDAP expert, but I see that `abandonRequest()` still wants to write > > into outStream. If the SASL/GSS context is already disposed by now what > > stream should this be? Should it be reverted back to the raw stream? > > However, I'm not sure if this correct. This means the security guaranteed by > the SASL layer is lost and I also don't know if the peer can parse it > correctly. > > @michael-o What have JDK 8 and `ldapsearch` done? Did they send error > messages in the clear? JDK 8 is here: https://mail.openjdk.org/pipermail/security-dev/2025-April/045574.html Create a TLS connection to Active Directory, bind with SASL GSSAPI and require SASL integrity. Now, this is thrown by Java 8: > Exception in thread "main" javax.naming.NamingException: LDAP > connection has been closed; remaining name '' at > com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:133) at > com.sun.jndi.ldap.Connection.readReply(Connection.java:469) at > com.sun.jndi.ldap.LdapClient.getSearchReply(LdapClient.java:638) at > com.sun.jndi.ldap.LdapClient.search(LdapClient.java:561) at > com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:2014) at > com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1873) at > com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1798) at > com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392) > at > com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358) > at > com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:341) > at > javax.naming.directory.InitialDirContext.search(InitialDirContext.java:267) > at DirTest.main(DirTest.java:24) `ldapsearch`: This is how ldapsearch(1) handles it: > $ ldapsearch -O minssf=1 -d 10 -H ldaps://ad001.siemens.net -s base -Y GSSAPI > namingContexts > ... > sb_sasl_generic_pkt_length: received illegal packet length of 813957120 bytes > sasl_generic_read: want=16, got=16 > 0000: 00 7e 02 01 00 78 84 00 00 00 5d 0a 01 02 04 00 .~...x....]..... > sb_sasl_cyrus_decode: failed to decode packet: generic failure > sb_sasl_generic_read: failed to decode packet > ldap_read: want=8 error=Input/output error > ber_get_next failed, errno=5. > > # numResponses: 0 > ldap_result: Can't contact LDAP server (-1) > tls_write: want=31, written=31 > 0000: 15 03 03 00 1a df 9c b5 96 48 55 9d 1e 65 dc eb .........HU..e.. > 0010: a1 ca 00 a5 96 10 be 5c 23 32 b9 90 68 c4 04 .......#2..h.. libldap does properly signal in the invalid buffer size and shows the connection closure. I think I have described the issue quite well in https://mail.openjdk.org/pipermail/security-dev/2025-April/045574.html. pcap and keylog file are available for inspection. The opposite side does not send an `abandonRequest`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26566#issuecomment-3214219907
