Issue 4941 - incorrect description of TLS_REQCERT setting
Summary: incorrect description of TLS_REQCERT setting
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: documentation (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-30 08:47 UTC by guenther@sendmail.com
Modified: 2014-08-01 21:04 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description guenther@sendmail.com 2007-04-30 08:47:42 UTC
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>

Comment 1 Howard Chu 2007-04-30 12:51:33 UTC
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/

Comment 2 guenther@sendmail.com 2007-04-30 16:27:25 UTC
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

Comment 3 Howard Chu 2007-07-03 14:47:53 UTC
moved from Incoming to Documentation
Comment 4 Howard Chu 2007-07-03 15:00:42 UTC
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/

Comment 5 Gavin Henry 2008-02-19 21:04:39 UTC
Is this text correct then?
Comment 6 Gavin Henry 2008-04-16 08:13:57 UTC
changed state Open to Test
Comment 7 Howard Chu 2009-03-19 19:12:51 UTC
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/

Comment 8 Gavin Henry 2009-09-22 20:39:19 UTC
changed notes
changed state Test to Closed
Comment 9 OpenLDAP project 2014-08-01 21:04:10 UTC
Fixed in HEAD and RE4