RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Alexey Bakhtin alexey at azul.com
Wed May 27 14:57:08 UTC 2020

Hello Aleks,

I mean “com.sun.jndi.ldap.connect.timeout” property.
The positive value forces to start TLS handshake and wait for it completion during the connectTimeout milliseconds:
>> if (connectTimeout > 0) {
>>     int socketTimeout = sslSocket.getSoTimeout();
>>     sslSocket.setSoTimeout(connectTimeout); // reuse full timeout value
>>     sslSocket.startHandshake();
>>     sslSocket.setSoTimeout(socketTimeout);
>> }

Without this property handshake is started later asynchronously.
As result
>>    certs = ssock.getSession().getPeerCertificates();
in the LdapClient.java could return SSLPeerUnverifiedException().
This exception will be wrapped to NamingException and thrown to application.

This is not usually happens but I saw it on the slow connection


> On 27 May 2020, at 16:13, Aleks Efimov <aleksej.efimov at oracle.com> wrote:
> Hi Alexey,
> I have question about timeouts:
> LdapCtx has 2 timeout properties: connectTimeout and readTimeout.
> First one is for controlling the Socket::connect timeout (Connection::createSocket), another - for reading out the replies (Connection::readReply).
> Both of them have default values set to '-1' which means that the LDAP stack would not set any timeouts for connect and/or reading operations.
> Could you, please, share the failures you're observing with no connect timeout set?
> Best,
> Aleksei
> On 27/05/2020 11:48, Alexey Bakhtin wrote:
>> Hello Bernd,
>>> On 27 May 2020, at 13:12, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:
>>> LdapCtxt:
>>> 2568     /**
>>> 2569      * Sets the read timeout value
>>> 2570      */
>>> 2571     private void setChannelBindingType(String cbTypeProp) {
>> Thank you. This is misprint. Should be “Sets the channel binding type”
>> About timeout - Yes. It is required. Otherwise, LdapClient does not wait for TLS handshake completion and we can not get TLS server certificate before Channel Binding data is populated.
>> Actually, we can force to wait for handshake completion but what timeout should be set in this case.
>> As mentioned by Danial, information about new property and timeout should be documented in the release notes.
>> For the TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT type name, I do not think it is good approach. If you think different servers could accept different address types for the same Channel Binding type, It would be better to introduce separate boolean compatibility property like “com.sun.security.sasl.addrtype.compat”. In this case it would be applied not only for tls-server-end-point but for any provided Channel Bindings
>>> Not sure if that javadoc is the right one? And I also wonder if enforcing the timeout is needed, and if yes if it should be documented why. Was not obvious to me,
>>> what about having two type names (TlsChannelBindingType.TLS_SERVER_END_POINT and TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT?)
>>> This could be configured as a SASL property and it would add the benefit that you don't need the instance specific if in the gssstub native code if you instead have two different types values?
>>> Gruss
>>> Bernd
>>> Von: security-dev <security-dev-bounces at openjdk.java.net> im Auftrag von Alexey Bakhtin <alexey at azul.com>
>>> Gesendet: Mittwoch, Mai 27, 2020 11:43 AM
>>> An: Valerie Peng
>>> Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Thomas Maslen
>>> Betreff: Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
>>> Hello Valerie, Unfortunately, Windows LDAP server with LdapEnforceChannelBinding=2 does not accept GSS_C_AF_NULLADDR address type. This is exact reason of these changes. I ve tried to fix inconsistency of address type value in the latest webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v2/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20200527/4c7ae8d0/signature-0001.asc>

More information about the security-dev mailing list