innoq / LiQID

LDAP innoQ ID Manager
Apache License 2.0
6 stars 8 forks source link

Reuse of a closed TCP connection #38

Open sfieux opened 6 years ago

sfieux commented 6 years ago

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:

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 commented 6 years ago

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