Reuse of a closed TCP connection

[sfieux]

Hi,

I found something but I don't know if it's an issue with LiQID, with the underlying javax.naming.directory classes or if it's just me, so I figured I would share it here.

We use LiQID to authenticate to a distant LDAP server via LDAPS. So we have a web client sending an authentication request to our server, our server uses LiQID to delegate the authentication to a distant LDAP server, with at least one firewall between our server and the LDAP. Our server authentication code looks like this:

public User authenticate(String username, String password) {
        User user = null;
        // Check the user password
        if (ldapHelper.checkCredentials(username, password)) {
            // Get user info
            LdapUser ldapUser = (LdapUser) ldapHelper.getUser(username);
           // Here we check that the user is authorized to access the application
          (...)

From time to time, the getUser hangs for more than 60s, which makes the authentication request abort. While investigating with network traces, I found out that this was caused by a connection reuse:

• The server contacts the LDAP for the checkCredentials method:
  • TCP syn-synack-ack
  • TLS handshake, key exchange
  • LDAPS stuff
  • end of TCP connection: end requested by server with the FIN flag, LDAP answers FIN-ACK, that is acknowledged by ACK, the connection should now be closed on both sides.
• The server contacts the LDAP for the getUser method:
  • no syn-ack, no TLS handshake,
  • sends directly a LDAPS data packet using a new source port

This LDAPS data packet is often processed by the LDAP, but from time to time it's dropped either by the LDAP or the firewall (LDAP-side network traces never shows this packet). After a some failed TCP retransmissions, the connection starts from scratch, syn/synack/ack and TLS handshake. It's too late however, the request took more than 60 seconds, our server has already given up on the request and sent an error to the client.

For now we solved the problem with a ldapHelper.reload(); between the two connections, which forces the second one to start a brand new clean TCP connection.

Is the above described behavior expected?

Thanks for reading it all

[phaus]

Hi @sfieux thx for this analysis. I will have a look into this issue.