You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Stefan Seelmann (Jira)" <ji...@apache.org> on 2021/06/20 10:36:00 UTC
[jira] [Commented] (DIRSTUDIO-1220) Directory Studio doesn't use
the SASL confidentiality layer after negotiating its use
[ https://issues.apache.org/jira/browse/DIRSTUDIO-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17366138#comment-17366138 ]
Stefan Seelmann commented on DIRSTUDIO-1220:
--------------------------------------------
Implemented SASL security layer in the LDAP API https://issues.apache.org/jira/browse/DIRAPI-373:
https://github.com/apache/directory-ldap-api/commit/2cf66a14c58d4c0ddd3dd3700566a4e72cdb3518
Use that LDAP API version and added tests:
https://github.com/apache/directory-studio/commit/18ad16e89deb2998ee0fef0f16a9a85a0df1ddd2
> 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
> Priority: Major
> Fix For: 2.0.0-M17
>
>
> 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
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org