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:
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
Alexey
> On 27 May 2020, at 16:13, Aleks Efimov <aleksej.efi...@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 <e...@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-boun...@openjdk.java.net> im Auftrag von
>>> Alexey Bakhtin <ale...@azul.com>
>>> Gesendet: Mittwoch, Mai 27, 2020 11:43 AM
>>> An: Valerie Peng
>>> Cc: security-...@openjdk.java.net; core-libs-dev@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/
