Re: (ITS#4941) incorrect description of TLS_REQCERT setting

[hyc@symas.com]

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/