Uploaded image for project: 'Directory Client API'
  1. Directory Client API
  2. DIRAPI-227

Bind user dn and password sent in clear after receiving PROTOCOL_ERROR during ldaps connection

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.0-M28
    • Fix Version/s: 1.0.0
    • Labels:
      None

      Description

      I was attempting to use M28 and was having issues getting LDAPS to work (startTLS appeared to work just fine). After several repeated bind and unbind operations, the LDAPS connection would eventually fail with a PROTOCOL_ERROR and never bind again. However, when it was attempting to bind after receiving that error, it would then send the bind user and password in the clear. This was confirmed by looking in the LDAP server logs and also by Wireshark.

      I ran with debug turned on and this is what it receives during a failure (which is after a long string of successes, by the way). I omitted my project's code from the trace for clarity:

      14:53:55,447 | DEBUG | tp1920834220-484 | ry.ldap.client.api.LdapNetworkConnection 1028 | ts-ldapclaimshandler | Bind request
      14:53:55,450 | DEBUG | tp1920834220-484 | ry.ldap.client.api.LdapNetworkConnection 1270 | ts-ldapclaimshandler | Sending request
      MessageType : BIND_REQUEST
      Message ID : 1
      BindRequest
      Version : '3'
      Name : 'cn=admin'
      Simple authentication : '(omitted-for-safety)'

      14:53:55,450 | DEBUG | tp1920834220-484 | ry.ldap.client.api.LdapNetworkConnection 280 | ts-ldapclaimshandler | Adding <1, org.apache.directory.ldap.client.api.future.BindFuture>
      14:53:55,654 | DEBUG | NioProcessor-3 | .ldap.client.api.LdapNetworkConnection$1 660 | ts-ldapclaimshandler | received a NoD, closing everything
      14:53:55,654 | DEBUG | NioProcessor-3 | .ldap.client.api.LdapNetworkConnection$1 665 | ts-ldapclaimshandler | closing BindFuture[msgId : 1, size : 0, Canceled :false]
      14:53:55,656 | DEBUG | tp1920834220-484 | ry.ldap.client.api.LdapNetworkConnection 1201 | ts-ldapclaimshandler | Bind failed : MessageType : BIND_RESPONSE
      Message ID : -1
      BindResponse
      Ldap Result
      Result code : (PROTOCOL_ERROR) protocolError
      Matched Dn : 'null'
      Diagnostic message : 'PROTOCOL_ERROR: The server will disconnect!'

      14:53:55,656 | ERROR | tp1920834220-484 | rity.sts.claimsHandler.RoleClaimsHandler 238 | ts-ldapclaimshandler | Unable to set role claims.
      org.apache.directory.api.ldap.model.exception.LdapProtocolErrorException: PROTOCOL_ERROR: The server will disconnect!
      at org.apache.directory.api.ldap.model.message.ResultCodeEnum.processResponse(ResultCodeEnum.java:2163)
      at org.apache.directory.ldap.client.api.LdapNetworkConnection.bind(LdapNetworkConnection.java:1035)

        Activity

        Hide
        elecharny Emmanuel Lecharny added a comment -

        I mark it as solved, as we have switched to a version of MINA which solves the issue.

        Show
        elecharny Emmanuel Lecharny added a comment - I mark it as solved, as we have switched to a version of MINA which solves the issue.
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Seems like this should be fixed, as DIRMINA-1044 has been fixed, and we are now using MINA-2.0.16 in trunk.

        Show
        elecharny Emmanuel Lecharny added a comment - Seems like this should be fixed, as DIRMINA-1044 has been fixed, and we are now using MINA-2.0.16 in trunk.
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Ok, it seems that when the SSL Handshake fails, the session is not deleted, then every message being sent is in clear. This is a bug in MINA (DIRMINA-1044) that should be fixed in the next version.

        As soon as we have a MINA release, we will use it in the LDAP API.

        Show
        elecharny Emmanuel Lecharny added a comment - Ok, it seems that when the SSL Handshake fails, the session is not deleted, then every message being sent is in clear. This is a bug in MINA ( DIRMINA-1044 ) that should be fixed in the next version. As soon as we have a MINA release, we will use it in the LDAP API.
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Question : seems like a NoticeOfDisconnect is received (which means the remote server has closed the connection). What happens to the connection then ? Is it simply reused ? If so, I bet that the SSL negociation will not occur at all.

        Is there a way for you to create a plain new connection with the SSL setup ?

        Show
        elecharny Emmanuel Lecharny added a comment - Question : seems like a NoticeOfDisconnect is received (which means the remote server has closed the connection). What happens to the connection then ? Is it simply reused ? If so, I bet that the SSL negociation will not occur at all. Is there a way for you to create a plain new connection with the SSL setup ?
        Show
        stustison Scott Tustison added a comment - You can find all of the code here: https://github.com/codice/ddf-security/blob/master/sts/security-sts-ldapclaimshandler/src/main/java/ddf/security/sts/claimsHandler/ClaimsHandlerManager.java https://github.com/codice/ddf-security/blob/master/sts/security-sts-ldapclaimshandler/src/main/java/ddf/security/sts/claimsHandler/LdapClaimsHandler.java That was for a slightly earlier release (M24) as we've moved that repository into another. But the same issue existed for LDAPS. Hope that helps.
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Here, what would be useful is the code you use to connect.

        Show
        elecharny Emmanuel Lecharny added a comment - Here, what would be useful is the code you use to connect.
        Hide
        stustison Scott Tustison added a comment -

        I forgot to also include that the OpenDJ server version that I was using was 2.4.6. Hopefully that will help you reproduce this!

        Show
        stustison Scott Tustison added a comment - I forgot to also include that the OpenDJ server version that I was using was 2.4.6. Hopefully that will help you reproduce this!

          People

          • Assignee:
            Unassigned
            Reporter:
            stustison Scott Tustison
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development