A lot of my recent commits are actually intended for OpenLDAP 2.5. A few of the recent TLS-related changes added to the libldap API, so one way or another they will require a library version bump. The question is whether these changes should go into the next 2.4 release: channel binding support OpenSSL elliptic curve support logging tls version/cipher info
It seems that given the heightened awareness of encryption matters due to recent revelations about NSA data gathering, it might be a good idea to include these in 2.4 as well. Any opinions?
Howard Chu wrote:
A lot of my recent commits are actually intended for OpenLDAP 2.5. A few of the recent TLS-related changes added to the libldap API, so one way or another they will require a library version bump. The question is whether these changes should go into the next 2.4 release: channel binding support OpenSSL elliptic curve support logging tls version/cipher info
Currently I'm not keen on elliptic curves.
Channel binding is interesting but AFAICS current implementations of SCRAM-SHA-1 still require the userPassword to be in clear-text. So this is not urgent for now.
But I'd like to see better support soon for getting tls version/cipher info in the logs (ITS#7683). This is much needed to evaluate a certain server deployment.
Furthermore also important is more information retrievable by the client:
1. I re-new my feature request "Retrieve LDAP server cert" (ITS#7398). Another reason for this feature is e.g. client-side cert pinning or similar.
2. I'd also like to see a LDAP option for retrieving the actually negotiated tls version/cipher info via ldap_get_option(). I know of LDAP_OPT_X_TLS_CIPHER_SUITE but a client may enable different features based on cipher actually negotiated.
Ciao, Michael.
Michael Ströder wrote:
- I'd also like to see a LDAP option for retrieving the actually negotiated
tls version/cipher info via ldap_get_option(). I know of LDAP_OPT_X_TLS_CIPHER_SUITE but a client may enable different features based on cipher actually negotiated.
Filed ITS#7686 for that.
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
A lot of my recent commits are actually intended for OpenLDAP 2.5. A few of the recent TLS-related changes added to the libldap API, so one way or another they will require a library version bump. The question is whether these changes should go into the next 2.4 release: channel binding support OpenSSL elliptic curve support logging tls version/cipher info
Currently I'm not keen on elliptic curves.
Agreed. They seem like a trap, frankly. Especially since it's already known that there's a flaw in Dual_EC_DRBG whose very existence is due to the NSA.
Channel binding is interesting but AFAICS current implementations of SCRAM-SHA-1 still require the userPassword to be in clear-text. So this is not urgent for now.
The Cyrus-SASL implementation actually looks for authpassword too, in which case it can use a prehashed password as in RFC5803. A bit of a shame that they don't support {scheme}-prefixed userPassword values, as RFC2307 uses.
But I'd like to see better support soon for getting tls version/cipher info in the logs (ITS#7683). This is much needed to evaluate a certain server deployment.
That should be no problem.
Furthermore also important is more information retrievable by the client:
- I re-new my feature request "Retrieve LDAP server cert" (ITS#7398). Another
reason for this feature is e.g. client-side cert pinning or similar.
Will look into it.
- I'd also like to see a LDAP option for retrieving the actually negotiated
tls version/cipher info via ldap_get_option(). I know of LDAP_OPT_X_TLS_CIPHER_SUITE but a client may enable different features based on cipher actually negotiated.
Currently these are provided via two new ldap_pvt_tls_get_ functions. (It was just easier this way, since slapd doesn't have an LDAP* session handle.) I suppose for the client side we can provide them via ldap_get_option() as well, but the underlying ldap_pvt functions will be there anyway.
Ciao, Michael.
Michael Ströder wrote:
- I re-new my feature request "Retrieve LDAP server cert" (ITS#7398). Another
reason for this feature is e.g. client-side cert pinning or similar.
Rereading the ITS, still the question - you just want the DER blob returned?
Howard Chu wrote:
Michael Ströder wrote:
- I re-new my feature request "Retrieve LDAP server cert" (ITS#7398). Another
reason for this feature is e.g. client-side cert pinning or similar.
Rereading the ITS, still the question - you just want the DER blob returned?
Yes, that would be sufficient. I'd to the parsing/fingerprinting within the client.
What else would you view as interesting?
Ciao, Michael.
-
Howard Chu -
Michael Ströder