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
