New SSL features for Nginx.

[Brice Figureau]

On 22/07/09 21:24, Igor Sysoev wrote:
> On Wed, Jul 22, 2009 at 09:13:55PM +0200, Brice Figureau wrote:
> 
>> On 22/07/09 20:43, Igor Sysoev wrote:
>>> On Wed, Jul 22, 2009 at 07:20:39PM +0200, Brice Figureau wrote:
>>>
>>>> On 22/07/09 14:16, Igor Sysoev wrote:
>>>>> On Wed, Jul 22, 2009 at 12:21:23PM +0200, Brice Figureau wrote:
>>>>>
>>>>>> Hi Igor,
>>>>>>
>>>>>> On Wed, 2009-07-22 at 12:44 +0400, Igor Sysoev wrote:
>>>>>>> On Tue, Jul 21, 2009 at 08:02:05PM +0200, Brice Figureau wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> For Puppet[1] Nginx deployement (that is using Nginx as a front-end 
>>>>>>>> load-balancers to puppetmasters[2]), I had to create the following 
>>>>>>>> two patches, to match Apache behaviour:
>>>>>>>>
>>>>>>>> * The first patch allows:
>>>>>>>> + a new variant of ssl_client_verify: optional. In this mode, if the 
>>>>>>>> client sends a certificate it is verified, but if the client doesn't 
>>>>>>>> send a certificate, the connection is authorized too.
>>>>>>>>
>>>>>>>> + a new variable: $ssl_client_verify which contains, either NONE, 
>>>>>>>> SUCCESS or FAILURE depending on the verification status. It can be 
>>>>>>>> used to send information to the upstream about the client 
>>>>>>>> verification.
>>>>>>>>
>>>>>>>> * The second patch adds CRL support to the client certificate 
>>>>>>>> verification:
>>>>>>>>
>>>>>>>> ssl_crl /path/to/crl.pem;
>>>>>>>>
>>>>>>>> Nginx then verifies the client certificate hasn't been revoked in the 
>>>>>>>> given CRL before allowing the connection to proceed.
>>>>>>>>
>>>>>>>> For access to the patches, please see my last blog article:
>>>>>>>> http://www.masterzen.fr/2009/07/21/new-ssl-features-for-nginx/
>>>>>>>>
>>>>>>>> It would be great if those patches could be merged in the official 
>>>>>>>> Nginx source tree.
>>>>>>> Thank you, I have looked the patches, it was really surpise for me that
>>>>>>> OpenSSL 0.9.7 supports CRL. I read in old enough book "Network Security
>>>>>>> with OpenSSL" written when 0.9.7 was being developed, that OpenSSL has
>>>>>>> no built-in CRL support. 
>>>>>> Ah, ok. I based all my development on OpenSSL 0.9.8, since that's what
>>>>>> I'm building Nginx againt. And definitely there is CRL support.
>>>>>> Is OpenSSL 0.9.7 a strict dependency for Nginx?
>>>>> No. I think this code should be just "#ifdef'ed X509_V_FLAG_CRL_CHECK".
>>>> I'm OK with this. BTW, I checked and CRL support was added in 0.9.7.
>>>>
>>>>>>> Then I have looked in Apache's mod_ssl sources and
>>>>>>> its CRL support seemed to me very heavy: mod_ssl does a lot of useless
>>>>>>> operations.
>>>>>> Which ones?
>>>>>> What I don't get is why they're doing the CRL verification themselves.
>>>>> Because mod_ssl were developed before 0.9.7.
>>>> Yes, I do think so. But it's error-prone and certainly less efficient.
>>>>
>>>>>> I found this comment in the code:
>>>>>>    * OpenSSL provides the general mechanism to deal with CRLs but does
>>>>>> not
>>>>>>    * use them automatically when verifying certificates, so we do it
>>>>>>    * explicitly here. We will check the CRL for the currently checked
>>>>>>    * certificate, if there is such a CRL in the store.
>>>>>>
>>>>>> This seems wrong to me, as I already tested, and it works fine at least
>>>>>> in version 0.9.8.
>>>>> Yes, this implementation. However, I made mistake: it's not too heavy as
>>>>> it seemed to me first time I have looked.
>>>>>
>>>>>>> I think that it's enough to store hash of only public key of
>>>>>>> all CRL certificates (including intermediate ones). 
>>>>>> Why reinvent the wheel?
>>>>>> The CRL is a standard thing (see RFC 3280), and basically this is a DER
>>>>>> encoded ASN1 structure containing the list of the revoked certificates
>>>>>> serial number, signed by the CA cert.
>>>>>>
>>>>>>> Have you looked
>>>>>>> how CRL is implemented in OpenSSL ?
>>>>>> Yes, I did. It is pretty extensive, and matches RFC3280.
>>>>>>
>>>>>> I'll fetch OpenSSL 0.9.7 to see if it supports or not CRL, but I'd be
>>>>>> suprised it wouldn't.
>>>> 0.9.7 definitely supports CRL verification.
>>> Yes. When I mentioned the book, I meant that CRL were not supported
>>> at least in 0.9.6.
>>>
>>>>>> Thanks for reviewing the patch (at least the first one could be merged,
>>>>>> isn't it?).
>>>>> Probabaly, I will commit the patches in next 0.8.7.
>>>> Will you merge the CRL one (feel free to rewrite it if you prefer), too ?
>>> Yes, the single issue is name of directive: ssl_crl. Should it be longer 
>>> and
>>> more expressive ? Apache has SSLCARevocationFile.
>> Yes, the name is not very good but the other alternatives I thought 
>> about were too long:
>> ssl_certificate_revocation
>> ssl_ca_revocation
>> ssl_ca_certificate_revocation
>>
>> Maybe the best one is: ssl_ca_revocation?
>> But that'd be the only directive with CA in it, although that's what's 
>> is really the ssl_client_certificate one.
>>
>> So maybe, last try: ssl_client_revocation would be really better.
>>
>> What do you think?
> 
> Probably, ssl_client_revocation is better.
> Question to native speakers: should it be ssl_client_revocationS ?

My idea was that this directive was an abbrevation of 
ssl_client_revocation_file, so the 's' wasn't needed. But I'm not a 
native speaker, or in fact I'm a native speaker, but not of English :-)
--
Brice Figureau
My Blog: http://www.masterzen.fr/