[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=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-unsubscr...@directory.apache.org For additional commands, e-mail: dev-h...@directory.apache.org
[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=16810706#comment-16810706 ] Hugh Cole-Baker commented on DIRSTUDIO-1220: I should add that on Mac, I have JNDI available as an alternative choice for the API, but I have a colleague on Linux who does not have that option in Directory Studio - I think because he's using Java 11 and JNDI was disabled in Java 9+ (DIRSTUDIO-1187). So I would like to find a solution for using Apache LDAP API with our LDAP server. > 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 > > 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)
[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=16810693#comment-16810693 ] Hugh Cole-Baker commented on DIRSTUDIO-1220: I'm using the Apache LDAP API. If I keep all other settings the same but change the API to use JNDI, the issue doesn't occur and I can connect successfully. With JNDI I can see in the network traffic that all packets after the successful SASL GSSAPI "handshake" are protected with SASL GSSAPI confidentiality protection, as expected. > 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 > > 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)
[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=16810664#comment-16810664 ] Lothar Haeger commented on DIRSTUDIO-1220: -- Which API do you use in that connection, JNDI or the Apache LDAP API (--> connection properties)? Does the issue occur with both of them or is it limited to one? > 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 > > 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)
