There are two issues with sslcert.lua that prevent it from working with LDAP in certain cases.
STARTTLS vs version detection
When version detection is used against an ldaps port, for example 636/tcp, it would identify the port as ldap over an ssl tunnel. sslcert.lua, not knowing about the already discovered tunnel suppor,t would look up the service name, ldap, to see if it needed to use a STARTTLS helper function, would find it in the list, try to negotiate STARTTLS, and then fail. Without version detection enabled it would label the port as ldapssl, fail to find it in the table, and then successfully negotiate a TLS tunnel.
Since this issue is due to the version detection changing the label to something in the STARTTLS table and version detection will know the tunnel type at this point I have a commit that fixes this problem by checking to see if the port.version.service_tunnel is ssl before calling the STARTTLS functions.
STARTTLS request
The LDAP STARTTLS related request is not encoded correctly. It was being encoded as a standard ASN.1 octet string ( tag 0x04 ). This failed to work and was not parsed as valid in Wireshark.
Per RFC4511 Section 4.12 the requestName, in this case the OID for STARTTLS, is an octet encoded string with a Context specific tag of 0 meaning that it should be encoded with tag 0x80.
After this change has been made STARTTLS functions correctly against LDAP services that support it.
I will be committing code momentarily that addresses both of the issues above. It has been tested against Windows Active Directory (with and without support for STARTTLS) and OpenLDAP (with STARTTLS support) servers.
The following commands were used and returned the expected results:
There are two issues with
sslcert.lua
that prevent it from working with LDAP in certain cases.STARTTLS vs version detection
When version detection is used against an
ldaps
port, for example 636/tcp, it would identify the port asldap
over anssl
tunnel.sslcert.lua
, not knowing about the already discovered tunnel suppor,t would look up the service name,ldap
, to see if it needed to use aSTARTTLS
helper function, would find it in the list, try to negotiate STARTTLS, and then fail. Without version detection enabled it would label the port as ldapssl, fail to find it in the table, and then successfully negotiate a TLS tunnel.Since this issue is due to the version detection changing the label to something in the STARTTLS table and version detection will know the tunnel type at this point I have a commit that fixes this problem by checking to see if the
port.version.service_tunnel
isssl
before calling the STARTTLS functions.STARTTLS request
The LDAP STARTTLS related request is not encoded correctly. It was being encoded as a standard ASN.1 octet string ( tag 0x04 ). This failed to work and was not parsed as valid in Wireshark.
Code link
Per RFC4511 Section 4.12 the requestName, in this case the OID for STARTTLS, is an octet encoded string with a Context specific tag of 0 meaning that it should be encoded with tag 0x80.
After this change has been made STARTTLS functions correctly against LDAP services that support it.
I will be committing code momentarily that addresses both of the issues above. It has been tested against Windows Active Directory (with and without support for STARTTLS) and OpenLDAP (with STARTTLS support) servers.
The following commands were used and returned the expected results:
The text was updated successfully, but these errors were encountered: