2:34 a.m.
Hello,
quoting ldap.conf(5):
TLS_REQCERT <level>
...
try The server certificate is requested. If no certificate is
provided, the session proceeds normally. If a bad certificate is provided, the
session is immediately terminated.
...
I'd like to try the "If no certificate is provided" part, but can't
manage to do
so. I tried configuring the server to
1) not use any CA certificate or server certificate,
2) only use the CA certificate without any server certificate,
3) specify CA certificate dir with no certs in it,
4) specify CA certificate dir with a valid CA cert and no server certs.
In any case, the client (ldapsearch) doesn't even connect to the server, stating
either "SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure" or simply failing
to connect with "Can't contact LDAP server (-1)". The server is listening
on
ldap and ldaps. I tested this using both ldaps and StartTLS.
That leads me to a conclusion that what I'm trying to achieve is not achievable
and that the manpage should be changed.
Is the manpage wrong or is there any other way I can test the client with no
server certificate provided?
Cheers,
--
Jan Synacek
Software Engineer, Red Hat
5:23 a.m.
On Tue, Nov 12, 2013 at 2:34 AM, Jan Synacek <jsynacek(a)redhat.com> wrote:
TLS_REQCERT <level>
...
try The server certificate is requested. If no certificate is
provided, the session proceeds normally. If a bad certificate is provided, the
session is immediately terminated.
Is the manpage wrong or is there any other way I can test the client with no
server certificate provided?
While troubleshooting an LDAP issue, I stumbled across an IRC log or
mailing list comment (can't remember exactly) which basically said
that try == hard and the manpage was inaccurate to say anything else
(paraphrased). I have not perused the openldap server or client code
to verify the accuracy of that statement, but the comment (and your
results) matches my experience when troubleshooting.
...Todd
--
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine
5:26 a.m.
On Tue, Nov 12, 2013 at 2:34 AM, Jan Synacek <jsynacek(a)redhat.com> wrote:
Is the manpage wrong or is there any other way I can test the client
with no
server certificate provided?
I forgot to answer the second part. I just use accept. With tcpdump,
you can verify if it is or is not using encryption. It doesn't do
cert chain checking so it will accept self-signed certs.
...Todd
--
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine
11:02 p.m.
New subject: Antw: Re: TLS_REQCERT and no server certificate
Hi!
"It doesn't do cert chain checking so it will accept self-signed certs."
Even if it does cert chain checking, a self-signed certificate will be accepted! What are
you saying?
Regards,
Ulrich
>> Todd Lyons <tlyons(a)ivenue.com> schrieb am 12.11.2013 um
14:26 in Nachricht
<CAFG21ogCpL1q4hBU-y1tqLxRML1xrMN3tVkB-qj23mzBUZJGLg(a)mail.gmail.com>:
On Tue, Nov 12, 2013 at 2:34 AM, Jan Synacek
<jsynacek(a)redhat.com> wrote:
> Is the manpage wrong or is there any other way I can test the client with no
> server certificate provided?
I forgot to answer the second part. I just use accept. With tcpdump,
you can verify if it is or is not using encryption. It doesn't do
cert chain checking so it will accept self-signed certs.
...Todd
--
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine
11:40 p.m.
New subject: Antw: Re: TLS_REQCERT and no server certificate
On Wed, 13 Nov 2013, Ulrich Windl wrote:
"It doesn't do cert chain checking so it will accept
self-signed certs."
Even if it does cert chain checking, a self-signed certificate will be
accepted! What are you saying?
His use of the phrase "cert chain checking" was misleading.
With 'allow', the ldap client library doesn't care whether the cert's
signature can be validated back to a known-and-trusted root CA.
(If you copied the self-signed cert into the client's trusted CA file or
directory, then you might be able to use 'TLS_REQCERT demand' and be
secure from MitM attacks.)
Philip Guenther
7:37 a.m.
On Tue, 12 Nov 2013, Jan Synacek wrote:
quoting ldap.conf(5):
TLS_REQCERT <level>
...
try The server certificate is requested. If no certificate is
provided, the session proceeds normally. If a bad certificate is
provided, the session is immediately terminated.
...
Yeah, that text is bogus. At least with OpenLDAP 2.4.37 and OpenSSL
version 1.0.1c and earlier, 'TLS_REQCERT try' is exactly the same as
'TLS_REQCERT demand'. The only difference in the OpenLDAP source is that
'demand' sets the SSL_VERIFY_FAIL_IF_NO_PEER_CERT option...which is
documented by OpenSSL as having NO EFFECT on the SSL client side, which
can be confirmed in the OpenSSL source.
(c.f. ITS #4941 for when I tried to get this text fixed. Closed with no
changes.)
I'd like to try the "If no certificate is provided"
part, but can't
manage to do so.
Almost all TLS cipher suites, including the most deployed ones, require
the server to have a certificate, period. If you look at the output of
"openssl ciphers -v", the ciphers which have an 'Au' field of RSA, DSS,
ECDH, or ECDSA can only be used if the server has a certificate of the
indicated type.
So if you rule those out, you end up with basically three choices:
1) "Au=None": the anonymous ciphers. Possible, but they are trivially
subject to Man-in-the-Middle attacks, so TLS implementations disable
them by default.
(In theory they can be used securely via a channel-binding in a SASL
layer which supports integrity protections, but I haven't seen anyone
on list saying they've actually got that working. I lost track of
where the SASL bits stand on that after there was confusion on the IETF
mailing lists about what the protocols actually required. <sigh>)
2) "Au=PSK": pre-shared keys. Looks like these require a callback to
be configured on the server, but code to do that hasn't been added to
OpenLDAP. Good luck finding a client that would be able to use it.
3) "Au=SOMETHING_ELSE": something unusual like a Kerberos cipher suite.
Again, those require C code changes to enable their use, as well as
whatever infrastructure is behind them, which you didn't mention so
I'll assume you don't have.
So, right now, which one of those were you planning on using?
Philip Guenther
11:20 p.m.
New subject: Antw: Re: TLS_REQCERT and no server certificate
>> Philip Guenther <guenther+ldaptech(a)sendmail.com>
schrieb am 12.11.2013 um 16:37
in Nachricht
<alpine.BSO.2.11.1311120655310.19673(a)morgaine.local>:
On Tue, 12 Nov 2013, Jan Synacek wrote:
> quoting ldap.conf(5):
>
> TLS_REQCERT <level>
> ...
> try The server certificate is requested. If no certificate is
Maybe that should read "... If no VALID certificate is..."
> provided, the session proceeds normally. If a bad certificate is
> provided, the session is immediately terminated.
> ...
Yeah, that text is bogus. At least with OpenLDAP 2.4.37 and OpenSSL
version 1.0.1c and earlier, 'TLS_REQCERT try' is exactly the same as
'TLS_REQCERT demand'. The only difference in the OpenLDAP source is that
'demand' sets the SSL_VERIFY_FAIL_IF_NO_PEER_CERT option...which is
documented by OpenSSL as having NO EFFECT on the SSL client side, which
can be confirmed in the OpenSSL source.
(c.f. ITS #4941 for when I tried to get this text fixed. Closed with no
changes.)
> I'd like to try the "If no certificate is provided" part, but can't
> manage to do so.
Almost all TLS cipher suites, including the most deployed ones, require
the server to have a certificate, period. If you look at the output of
Yes, but the certificate could be expired or mismatching the host, etc.
"openssl ciphers -v", the ciphers which have an
'Au' field of RSA, DSS,
ECDH, or ECDSA can only be used if the server has a certificate of the
indicated type.
So if you rule those out, you end up with basically three choices:
1) "Au=None": the anonymous ciphers. Possible, but they are trivially
subject to Man-in-the-Middle attacks, so TLS implementations disable
them by default.
(In theory they can be used securely via a channel-binding in a SASL
layer which supports integrity protections, but I haven't seen anyone
on list saying they've actually got that working. I lost track of
where the SASL bits stand on that after there was confusion on the IETF
mailing lists about what the protocols actually required. <sigh>)
2) "Au=PSK": pre-shared keys. Looks like these require a callback to
be configured on the server, but code to do that hasn't been added to
OpenLDAP. Good luck finding a client that would be able to use it.
3) "Au=SOMETHING_ELSE": something unusual like a Kerberos cipher suite.
Again, those require C code changes to enable their use, as well as
whatever infrastructure is behind them, which you didn't mention so
I'll assume you don't have.
So, right now, which one of those were you planning on using?
Philip Guenther
11:55 p.m.
New subject: Antw: Re: TLS_REQCERT and no server certificate
On Wed, 13 Nov 2013, Ulrich Windl wrote:
>>> Philip Guenther <guenther+ldaptech(a)sendmail.com>
schrieb am 12.11.2013 um 16:37
in Nachricht <alpine.BSO.2.11.1311120655310.19673(a)morgaine.local>:
> On Tue, 12 Nov 2013, Jan Synacek wrote:
>> quoting ldap.conf(5):
>>
>> TLS_REQCERT <level>
>> ...
>> try The server certificate is requested. If no certificate is
>> provided, the session proceeds normally.
Maybe that should read "... If no VALID certificate is..."
I can't tell whether you're claiming that's how the code
* _does_ behave, and you've tested it
* _does_ behave, but you haven't tested it, OR
* _should_ behave, in your opinion.
> Almost all TLS cipher suites, including the most deployed ones,
> require the server to have a certificate, period. If you look at the
> output of
Yes, but the certificate could be expired or mismatching the host, etc.
I see no guarantee from OpenLDAP docs or code or OpenSSL docs or code that
such a setup would not fail immediately. I'm not going to bother checking
because such a setup would be be insecure and a waste of resources.
"What problem are you trying to solve?"
Philip Guenther
4:01 a.m.
New subject: Antw: Re: TLS_REQCERT and no server certificate
On 11/13/2013 08:20 AM, Ulrich Windl wrote:
>>> Philip Guenther <guenther+ldaptech(a)sendmail.com>
schrieb am 12.11.2013 um 16:37
in Nachricht <alpine.BSO.2.11.1311120655310.19673(a)morgaine.local>:
> On Tue, 12 Nov 2013, Jan Synacek wrote:
>> quoting ldap.conf(5):
>>
>> TLS_REQCERT <level>
>> ...
>> try The server certificate is requested. If no certificate is
Maybe that should read "... If no VALID certificate is..."
I guess that's what "If a bad certificate is provided" means.
--
Jan Synacek
Software Engineer, Red Hat
4:02 a.m.
On 11/12/2013 04:37 PM, Philip Guenther wrote:
On Tue, 12 Nov 2013, Jan Synacek wrote:
> quoting ldap.conf(5):
>
> TLS_REQCERT <level>
> ...
> try The server certificate is requested. If no certificate is
> provided, the session proceeds normally. If a bad certificate is
> provided, the session is immediately terminated.
> ...
Yeah, that text is bogus. At least with OpenLDAP 2.4.37 and OpenSSL
version 1.0.1c and earlier, 'TLS_REQCERT try' is exactly the same as
'TLS_REQCERT demand'. The only difference in the OpenLDAP source is that
'demand' sets the SSL_VERIFY_FAIL_IF_NO_PEER_CERT option...which is
documented by OpenSSL as having NO EFFECT on the SSL client side, which
can be confirmed in the OpenSSL source.
(c.f. ITS #4941 for when I tried to get this text fixed. Closed with no
changes.)
> I'd like to try the "If no certificate is provided" part, but can't
> manage to do so.
Almost all TLS cipher suites, including the most deployed ones, require
the server to have a certificate, period. If you look at the output of
"openssl ciphers -v", the ciphers which have an 'Au' field of RSA, DSS,
ECDH, or ECDSA can only be used if the server has a certificate of the
indicated type.
So if you rule those out, you end up with basically three choices:
1) "Au=None": the anonymous ciphers. Possible, but they are trivially
subject to Man-in-the-Middle attacks, so TLS implementations disable
them by default.
(In theory they can be used securely via a channel-binding in a SASL
layer which supports integrity protections, but I haven't seen anyone
on list saying they've actually got that working. I lost track of
where the SASL bits stand on that after there was confusion on the IETF
mailing lists about what the protocols actually required. <sigh>)
2) "Au=PSK": pre-shared keys. Looks like these require a callback to
be configured on the server, but code to do that hasn't been added to
OpenLDAP. Good luck finding a client that would be able to use it.
3) "Au=SOMETHING_ELSE": something unusual like a Kerberos cipher suite.
Again, those require C code changes to enable their use, as well as
whatever infrastructure is behind them, which you didn't mention so
I'll assume you don't have.
So, right now, which one of those were you planning on using?
Neither of them. All I wanted to do was to "provide no server certificate" and
verify that "TLS_REQCERT try" really did what it claimed.
Anyway, thank you for the complex explanation!
Philip Guenther
Cheers,
--
Jan Synacek
Software Engineer, Red Hat
3247
days inactive
3248
days old
openldap-technical@openldap.org
9 comments
4 participants
participants (4)
-
Jan Synacek -
Philip Guenther -
Todd Lyons -
Ulrich Windl