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

[Sean Mullan]

Thanks for that extra info.

I think it would be much cleaner to avoid having to set that property 
and instead start the handshake synchronously if the 
"com.sun.jndi.ldap.tls.cbtype" property is set. This way only one 
property needs to be set and you don't need to guess what an acceptable 
value is for the timeout property, which could also cause the connection 
to be interrupted before the TLS handshake is complete if you use too 
small of a value.

Or better yet, there may be another way to do this with JSSE where you 
wait for the TLS connection to complete. I'll ask my team and get back 
to you.

--Sean


On 7/6/20 6:06 PM, Aleks Efimov wrote:
> Hi Sean,
> 
> Alexey answered the same question for me:
> 
>> 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:
>> Connection.java
>>>> 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
> 
> The full context of LDAP Connection code that initiates the SSL 
> handshake could be viewed here:
> https://github.com/openjdk/jdk/blob/master/src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java#L345
> 
> -- Aleksei
> 
> On 06/07/2020 21:11, Sean Mullan wrote:
>> Hi Alexey,
>>
>> This may have been discussed already, but can you explain why the 
>> "com.sun.jndi.ldap.connect.timeout" property needs to be set in order 
>> to use this feature? That property is mostly used in tests to avoid 
>> long socket timeouts, etc.
>>
>> Why does that need to be set? What problem are you trying to solve?
>>
>> --Sean
>>
>>
>> On 7/3/20 11:31 AM, Alexey Bakhtin wrote:
>>>
>>>> I would suggest removing it. At least for the SASL GSS-API mech, it 
>>>> seems the GSSContext object will not be leaked and no one has a 
>>>> chance to call setChannelBinding again on it.
>>>>
>>>> There is no spec saying setChannelBinding() can only be called once, 
>>>> so I'd rather we don't enforce that, although you might say there is 
>>>> no need to call it twice.
>>>
>>> OK.
>>> GSSContextImpl class is removed from patch.
>>>
>>> Webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v11
>>>
>>> Thank you
>>> Alexey
>>>
>