Directory Studio doesn't use the SASL confidentiality layer after negotiating its use

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:

1. Client obtains a Kerberos service ticket for the LDAP server and passes it in the bind request for SASL GSSAPI authentication
2. 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.
3. 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".
4. Server replies with a bind response with result code 0 (success).
5. 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!
6. 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)
7. 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.
8. 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.

1. 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.