Showing results for 
Search instead for 
Did you mean: 


UnboundID james_Sheskier
0 Kudos


Is it possible to hide BIND credentials but not to use a full TLS session. Customer's clients do not support SASL but do support START_TLS/END_TLS.


Do the proxy and directory server support this? I have seen comments in the admin guide that START_TLS is supported but the an END_TLS will terminate the connection. Is that correct?


We keep getting referred to RFC 2830 which I believe is the START/END TLS support. Do the proxy and DS fully support this RFC?

UnboundID NeilW
0 Kudos


First, it should be noted that RFC 2830 has been superseded by RFCs 4511, and 4513, and our server is compliant with these RFCs. But to answer the question, it does not support closing the TLS layer while leaving the underlying connection intact, and this is an intentional design choice and one that is permitted by the specification in RC 4511.


I should point out that while there is an explicit StartTLS extended operation, there is no corresponding EndTLS operation. That is, there is no explicit LDAP request that a client can use to indicate that they want to convert a secure connection into an insecure one. The only way that a client (or server) could indicate that it wants to end the TLS session is to send a TLS closure alert.


This behavior is covered by RFC 4511 section 4.14.13. This states that there are two possible behaviors that clients and servers may exhibit:


  • When a protocol peer receives the initial TLS closure alert, it may choose to allow the LDAP message layer to remain intact. In this case, it MUST immediately transmit a TLS closure alert. Following this, it MAY send and receive LDAP PDUs.
  • Protocol peers may terminate the LDAP session after sending or receiving a TLS closure alert.


We have deliberately chosen to implement the second of these behaviors: if a client closes the TLS layer, we also close the underlying connection. This is more secure because it completely eliminates the possibility of inadvertent disclosure of sensitive information over a channel that might be mistakenly believed to be secure (for example, because the server was actively returning data for an ongoing search operation when the TLS closure alert was received).


Further, there really aren’t any compelling reasons to support closing a TLS session while leaving the underlying LDAP connection intact, although the customer might have a couple of misconceptions that might lead them to think that there is some benefit. They might include:


  • They think that TLS is slow, and they only want to incur the performance penalty for operations in which they know they’re transferring sensitive information. However, this is really not true because the vast majority of the cost of TLS encryption is paid up front, during the negotiation phase when the client and server need to use expensive asymmetric encryption in the course of generating the key for the much faster symmetric encryption. But once the TLS connection is established and the client and server are able to communicate securely, then there is really not that much overhead in encrypting that communication. However, if they want to re-establish TLS security on a connection that had previously been secured and de-secured, there will once again be a need for expensive negotiation on that connection (even if it might be somewhat cheaper due to TLS session reuse).
  • They think that the bind operation is the only operation that has anything worth protecting. That is definitely not true. The client may transfer sensitive information in other types of requests (for example, in a request to change their password or to modify information in their entry), and the server may transfer sensitive information in search result entries. If they close the TLS session after the bind, then those kinds of operations wouldn’t be protected. Further, even if they don’t expect to transfer sensitive information over an insecure connection, TLS offers integrity protection to ensure that a man-in-the-middle attacker can’t alter traffic between the client and server or inject its own requests and responses into the stream.
  • They think that they can use StartTLS to establish temporary security, perform a bind over that secure channel, then close the TLS session but continue using the connection in its authenticated state. That is probably not the case. In fact, the older RFC 2830 explicitly stated that was definitely not the case (section 5.2 states “Closure of the TLS connection MUST cause the LDAP association to move to an anonymous authentication and authorization state regardless of the state established over TLS and regardless of the authentication and authorization state prior to TLS connection establishment.”). RFC 4513 does back away from this and does allow for some leeway here (section B.3.4 states “Closing a TLS layer on an LDAP session changes the authentication and authorization state of the LDAP session based on local policy. Specifically, this means that implementations are not required to change the authentication and authorization states to anonymous upon TLS closure.”), but in practice, I would expect that most servers that support using a connection after TLS closure do revert the connection to an unauthenticated state.


Our recommendation is to always keep the security layer in place for all connections. Once you have the security layer in place, there isn’t much performance overhead in keeping it in place, and it affords a tremendous amount of protection for the communication. If there is some legitimate need to have some communication occur in the clear and other communication be performed securely, then they could maintain separate connection pools for each purpose, and choose a connection from the appropriate pool based on whether they need it to be secure or in the clear.

UnboundID _-rc-_
0 Kudos


If by "hide" you mean protect user BIND credentials with TLS, that is possible by binding anonymously then issuing a StartTLS Extended Request. PingDirectory ACLs allow StartTLS operations by anonymous users.  Once the connection is protected by TLS the application can request an authenticated BIND request where the password is protected by TLS security. NOTE: the credentials are not "hidden" just encrypted within the TLS session.


As for "END_TLS", there is no such construct in RFC 2830 nor it's successor RFC 4511. A connection which has been stepped up using StartTLS could issue a TLS close_notify alert message to revert to a non-TLS LDAP session but I've never seen an app do this.  


Generally after an authenticated session the client will gracefully close the TCP-TLS connection, this is by far the most common use-case. Each connection would start anonymously then use StartTLS to negotiate a TLS-protected session, perform a BIND, other operations, then a graceful close.


If the StartTLS connection is established from an LDAPConnectionPool, the application could revert the connection to an unauthenticated session with an anonymous bind. It's also possible to re-BIND with a different set of credentials without reverting to an anonymous connection.


There is also an UNBIND operation but it is rarely used in practice as it is a courtesy operation before closing the TCP connection.



If the client is referring to this section in RFC 4511, maybe you can get more information on reverting a non-TLS connection after using StartTLS. Again, this would be extremely unusual if the point is to protect authenticated user BIND credentials.


4.14.3.  Removal of the TLS Layer

   Either the client or server MAY remove the TLS layer and leave the
   LDAP message layer intact by sending and receiving a TLS closure

   The initiating protocol peer sends the TLS closure alert and MUST
   wait until it receives a TLS closure alert from the other peer before
   sending further LDAP PDUs.

   When a protocol peer receives the initial TLS closure alert, it may
   choose to allow the LDAP message layer to remain intact.  In this
   case, it MUST immediately transmit a TLS closure alert.  Following
   this, it MAY send and receive LDAP PDUs.