OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Documentation/4941
Full headers

From: guenther+ldapdev@sendmail.com
Subject: incorrect description of TLS_REQCERT setting
Compose comment
Download message
State:
1 replies: 1
4 followups: 1 2 3 4

Major security issue: yes  no

Notes:

Notification:


Date: Mon, 30 Apr 2007 08:47:42 GMT
From: guenther+ldapdev@sendmail.com
To: openldap-its@OpenLDAP.org
Subject: incorrect description of TLS_REQCERT setting
Full_Name: Philip Guenther
Version: 2.3.27
OS: linux and solaris
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (64.58.1.252)


The description of the TLS_REQCERT setting in the ldap.conf(5) manpage does not
match the actual operation of the code.  In particular:
- clients don't 'request' server certs in TLS.  They get one if the cipher
suite
  uses them, otherwise they don't
- 'allow' checks the identity of the server vs its cert (per RFC 4513,
  section 3.1.3) and will terminate the connection if they don't match
- 'try' is the same as 'demand' and 'hard'


Here's a possible patch to ldap.conf.5 to fix the above.  A reference to the RFC
should perhaps be added to the text.  I was also tempted to add a sentence to
the lead-in to clarify that the setting has no effect if the negotiated cipher
suite doesn't use certs, as a clarification of the "if any" in the existing
lead-in, but that's minor.  Simply having an even slightly correct description
of 'allow' is the important thing.

--- ldap.conf.5 26 Jan 2006 05:57:49 -0000
+++ ldap.conf.5 30 Apr 2007 08:39:53 -0000
@@ -249,22 +249,20 @@
 .RS
 .TP
 .B never
-The client will not request or check any server certificate.
+The client will not check the server certificate at all.
 .TP
 .B allow
-The server certificate is requested. If no certificate is provided,
-the session proceeds normally. If a bad certificate is provided, it will
-be ignored and the session proceeds normally.
-.TP
-.B try
-The server certificate is requested. If no certificate is provided,
-the session proceeds normally. If a bad certificate is provided,
+The client will only verify that name used to connect to the server
+matches one of the server certificate's subjectAltName or CN values.
+If no match is found, the session is immediately terminated.
+.TP
+.B try | demand | hard
+These keywords are equivalent.
+The client will verify the server certificate is valid and matches the
+name used to connect (as for 'allow').
+If a bad or mismatched certificate is provided,
 the session is immediately terminated.
-.TP
-.B demand | hard
-These keywords are equivalent. The server certificate is requested. If no
-certificate is provided, or a bad certificate is provided, the session
-is immediately terminated. This is the default setting.
+This is the default setting.
 .RE
 .TP
 .B TLS_CRLCHECK <level>


Followup 1

Download message
Date: Mon, 30 Apr 2007 05:51:33 -0700
From: Howard Chu <hyc@symas.com>
To: guenther+ldapdev@sendmail.com
CC: openldap-its@openldap.org
Subject: Re: (ITS#4941) incorrect description of TLS_REQCERT setting
guenther+ldapdev@sendmail.com wrote:
> Full_Name: Philip Guenther
> Version: 2.3.27
> OS: linux and solaris
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (64.58.1.252)
> 
> 
> The description of the TLS_REQCERT setting in the ldap.conf(5) manpage does
not
> match the actual operation of the code.  In particular:
> - clients don't 'request' server certs in TLS.  They get one if the cipher
> suite
>   uses them, otherwise they don't
> - 'allow' checks the identity of the server vs its cert (per RFC 4513,
>   section 3.1.3) and will terminate the connection if they don't match
> - 'try' is the same as 'demand' and 'hard'

Not quite. With both "allow" and "try" it's OK if the server provides no 
certificate. The difference is, with "try", if a cert is provided, it 
must be valid.
> 
> 
> Here's a possible patch to ldap.conf.5 to fix the above.  A reference to
the RFC
> should perhaps be added to the text.  I was also tempted to add a sentence
to
> the lead-in to clarify that the setting has no effect if the negotiated
cipher
> suite doesn't use certs, as a clarification of the "if any" in the existing
> lead-in, but that's minor.  Simply having an even slightly correct
description
> of 'allow' is the important thing.
> 
> --- ldap.conf.5 26 Jan 2006 05:57:49 -0000
> +++ ldap.conf.5 30 Apr 2007 08:39:53 -0000
> @@ -249,22 +249,20 @@
>  .RS
>  .TP
>  .B never
> -The client will not request or check any server certificate.
> +The client will not check the server certificate at all.
>  .TP
>  .B allow
> -The server certificate is requested. If no certificate is provided,
> -the session proceeds normally. If a bad certificate is provided, it will
> -be ignored and the session proceeds normally.
> -.TP
> -.B try
> -The server certificate is requested. If no certificate is provided,
> -the session proceeds normally. If a bad certificate is provided,
> +The client will only verify that name used to connect to the server
> +matches one of the server certificate's subjectAltName or CN values.
> +If no match is found, the session is immediately terminated.
> +.TP
> +.B try | demand | hard
> +These keywords are equivalent.
> +The client will verify the server certificate is valid and matches the
> +name used to connect (as for 'allow').
> +If a bad or mismatched certificate is provided,
>  the session is immediately terminated.
> -.TP
> -.B demand | hard
> -These keywords are equivalent. The server certificate is requested. If no
> -certificate is provided, or a bad certificate is provided, the session
> -is immediately terminated. This is the default setting.
> +This is the default setting.
>  .RE
>  .TP
>  .B TLS_CRLCHECK <level>
> 
> 
> 


-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/



Followup 2

Download message
Date: Mon, 30 Apr 2007 10:27:25 -0600
From: Philip Guenther <guenther@sendmail.com>
To: Howard Chu <hyc@symas.com>
cc: guenther+ldapdev@sendmail.com, openldap-its@openldap.org
Subject: Re: (ITS#4941) incorrect description of TLS_REQCERT setting
On Mon, 30 Apr 2007, Howard Chu wrote:
> guenther+ldapdev@sendmail.com wrote:
...
>> - 'allow' checks the identity of the server vs its cert (per RFC 4513,
>>   section 3.1.3) and will terminate the connection if they don't match
>> - 'try' is the same as 'demand' and 'hard'
>
> Not quite. With both "allow" and "try" it's OK if the server provides no 
> certificate.

That's true of 'demand' and 'hard' as well.  The only difference between 
'try' and 'demand' in the code is that the latter passes 
SSL_CTX_set_verify() the SSL_VERIFY_FAIL_IF_NO_PEER_CERT flag, but that 
flag has NO EFFECT on SSL clients.  This is documented on the 
SSL_CTX_set_verify() manpage and confirmed by grepping the openssl source 
for it.

If you don't believe me, I suggest you try configuring your server to 
accept the ADH suites (don't forget to set TLSDHParamFile to /dev/null) 
and give ldapsearch a whirl with
 	LDAPTLS_REQCERT=hard
 	LDAPTLS_CIPHER_SUITE=ADH-AES256-SHA

in your environment.  That's what I did.


Philip Guenther



Followup 3

Download message
Date: Tue, 03 Jul 2007 08:00:42 -0700
From: Howard Chu <hyc@symas.com>
To: Philip Guenther <guenther@sendmail.com>
CC: guenther+ldapdev@sendmail.com, openldap-its@openldap.org
Subject: Re: (ITS#4941) incorrect description of TLS_REQCERT setting
Philip Guenther wrote:
> On Mon, 30 Apr 2007, Howard Chu wrote:
>> guenther+ldapdev@sendmail.com wrote:
> ...
>>> - 'allow' checks the identity of the server vs its cert (per RFC
4513,
>>>   section 3.1.3) and will terminate the connection if they don't
match
>>> - 'try' is the same as 'demand' and 'hard'
>> Not quite. With both "allow" and "try" it's OK if the server provides
no 
>> certificate.
> 
> That's true of 'demand' and 'hard' as well.  The only difference between 
> 'try' and 'demand' in the code is that the latter passes 
> SSL_CTX_set_verify() the SSL_VERIFY_FAIL_IF_NO_PEER_CERT flag, but that 
> flag has NO EFFECT on SSL clients.  This is documented on the 
> SSL_CTX_set_verify() manpage and confirmed by grepping the openssl source 
> for it.
> 
> If you don't believe me, I suggest you try configuring your server to 
> accept the ADH suites (don't forget to set TLSDHParamFile to /dev/null) 
> and give ldapsearch a whirl with
>  	LDAPTLS_REQCERT=hard
>  	LDAPTLS_CIPHER_SUITE=ADH-AES256-SHA
> 
> in your environment.  That's what I did.

When this text was written, there was no support for anonymous cipher suites. 
So the meaning of the text is: assuming a cipher suite that actually uses 
certificates, the client would proceed even if the server didn't provide a 
cert. It's entirely possible that this circumstance has been overcome by other 
developments. Most likely this hasn't been a valid use case for quite a long 
time. But it has nothing to do with Diffie-Hellman key exchanges...

-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/



Reply 1

Resend
From: Gavin Henry <openldap-its@OpenLDAP.org>
To: openldap-its@OpenLDAP.org
Subject: Re: incorrect description of TLS_REQCERT setting (ITS#4941)
Date: Tue Feb 19 21:04:39 2008
Is this text correct then?


Followup 4

Download message
Date: Thu, 19 Mar 2009 12:12:51 -0700
From: Howard Chu <hyc@symas.com>
To: Philip Guenther <guenther@sendmail.com>
CC: guenther+ldapdev@sendmail.com, openldap-its@openldap.org
Subject: Re: (ITS#4941) incorrect description of TLS_REQCERT setting
Howard Chu wrote:
> Philip Guenther wrote:
>> On Mon, 30 Apr 2007, Howard Chu wrote:
>>> guenther+ldapdev@sendmail.com wrote:
>> ...
>>>> - 'allow' checks the identity of the server vs its cert (per
RFC 4513,
>>>>    section 3.1.3) and will terminate the connection if they
don't match
>>>> - 'try' is the same as 'demand' and 'hard'
>>> Not quite. With both "allow" and "try" it's OK if the server
provides no
>>> certificate.
>>
>> That's true of 'demand' and 'hard' as well.  The only difference
between
>> 'try' and 'demand' in the code is that the latter passes
>> SSL_CTX_set_verify() the SSL_VERIFY_FAIL_IF_NO_PEER_CERT flag, but that
>> flag has NO EFFECT on SSL clients.  This is documented on the
>> SSL_CTX_set_verify() manpage and confirmed by grepping the openssl
source
>> for it.
>>
>> If you don't believe me, I suggest you try configuring your server to
>> accept the ADH suites (don't forget to set TLSDHParamFile to /dev/null)
>> and give ldapsearch a whirl with
>>   	LDAPTLS_REQCERT=hard
>>   	LDAPTLS_CIPHER_SUITE=ADH-AES256-SHA
>>
>> in your environment.  That's what I did.
>
> When this text was written, there was no support for anonymous cipher
suites.
> So the meaning of the text is: assuming a cipher suite that actually uses
> certificates, the client would proceed even if the server didn't provide a
> cert. It's entirely possible that this circumstance has been overcome by
other
> developments. Most likely this hasn't been a valid use case for quite a
long
> time. But it has nothing to do with Diffie-Hellman key exchanges...

Aside from clarifying that we're assuming the use of X.509 certificates in the 
first place, this text is correct. I note that GnuTLS also works with OpenPGP 
keys, but I've never tested that here. Anyway, the current description is also 
accurate for GnuTLS.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org