Hugh Cole-Baker created DIRSTUDIO-1220:
------------------------------------------
Summary: Directory Studio doesn't use the SASL confidentiality
layer after negotiating its use
Key: DIRSTUDIO-1220
URL: https://issues.apache.org/jira/browse/DIRSTUDIO-1220
Project: Directory Studio
Issue Type: Bug
Components: studio-connection
Environment: Apache Directory Studio is running on Mac OS 10.14 with
jdk1.8.0_201.
Reporter: Hugh Cole-Baker
There is an issue connecting to an OpenLDAP server configured with
olcSaslSecProps: noplain,noanonymous,minssf=1
i.e. The server requires some form of transport encryption. Having a different
issue with StartTLS (DIRSTUDIO-1219), I tried relying on the SASL
confidentiality layer that SASL's GSSAPI mechanism can provide, to meet the
requirement for encryption. I have chosen "No encryption" i.e. no SSL or
StartTLS, in the Network Parameters, and then GSSAPI authentication method and
Quality of Protection: Authentication with integrity and privacy protection in
the SASL settings.
When connecting to the server, what I can see happening when looking at the
network traffic with Wireshark is:
# Client obtains a Kerberos service ticket for the LDAP server and passes it
in the bind request for SASL GSSAPI authentication
# Server replies with a bind response, continuing SASL GSSAPI authentication,
result code 14 (SASL bind in progress), with a 4 byte message wrapped using
GSS_Wrap. The 4 bytes are 0x06 0x01 0x00 0x00 - referring to RFC4752, the first
byte indicates the server supports "Integrity protection" and/or
"Confidentiality protection" but not "No security layer", as expected.
# Client replies with a bind request, continuing SASL GSSAPI authentication,
with a 4 byte message wrapped using GSS_Wrap. The 4 bytes are 0x04 0x01 0x00
0x00 - again referring to RFC4752, the first byte indicates the client has
selected "Confidentiality protection".
# Server replies with a bind response with result code 0 (success).
# Client sends a search request with base DN: "", scope: base, filter:
(objectClass=*), for attributes: subschemaSubentry, **with no confidentiality
protection**. This is the point where the client violates the protocol
described in RFC4752 - after negotiating confidentiality protection, the client
needs to actually use it!
# Server interprets the lack of confidentiality protection as an error and
immediately drops the connection (this makes sense from the server's POV as it
could indicate an attempted man-in-the-middle attack)
# Client immediately re-connects to the server, **doesn't bother to bind at
all** and then issues more search requests on the base object, cn=Subschema,
etc.
# An error message appears in Directory Studio "Error while opening connection
- Missing schema location in RootDSE, using default schema" - this is
presumably because the connection isn't bound, and the server limits what it
will disclose to un-bound clients.
# Directory Studio can't browse the directory at all because it's not properly
bound.
As you can see, there's possibly two issues here - definitely an issue with the
SASL GSSAPI mechanism, and possibly also an issue with the reconnect logic.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
