Open Stack

I presume with your usage of the term CNAME you actually mean the x509
'common name' or 'CN', not DNS canonical names(CNAMEs)? That does bring up
the point that we should verify all clients/servers work correctly with
certificates using subjectAltNames.

Nate
On Oct 30, 2012 6:05 AM, <stuart.mclaren at hp.com> wrote:

> Hi Rob,
>
> For python-glanceclient, which is now using pyopenssl, we are checking
> the server cert, but probably need to also add the 'CNAME is valid for
> the server' check -- I'd be interested if you could confirm this.
>
> If so, would adding something like 'match_hostname' from:
>
> http://svn.python.org/**projects/python/branches/pep-**0384/Lib/ssl.py<http://svn.python.org/projects/python/branches/pep-0384/Lib/ssl.py>
>
> into the 'verify_callback' function be appropriate?
>
> Also, will openssl check that the certificate is in date by default, or
> should an explicit check for this also be added to the 'verify_callback'?
>
> Thanks,
>
> -Stuart
>
>  Date: Tue, 30 Oct 2012 08:31:07 +0000
>> From: "Clark, Robert Graham" <robert.clark at hp.com>
>> To: OpenStack List <openstack-dev at lists.**openstack.org<openstack-dev at lists.openstack.org>
>> >
>> Subject: [openstack-dev] [OSSG] SSL Review
>> Message-ID: <CCB540CA.E6B5%robert.clark@**hp.com<CCB540CA.E6B5%25robert.clark at hp.com>
>> >
>> Content-Type: text/plain; charset="us-ascii"
>>
>> All,
>>
>> During the summit Bryan highlighted the poor SSL implementations being
>> used in various OpenStack clients, with some doing no verification at all.
>>
>> Sadly the state of OpenStack internally (where SSL can be enabled) is
>> often little better. I'm going to start a body of work to navigate through
>> the code and check exactly what is (or isn't) enabled for each SSL
>> interface on offer.
>>
>> I'm planning on checking the ability to execute a wide range of controls
>> because we want this 'enhanced' level of security on some particular
>> interfaces.
>>
>> (For each interface)
>> Fundamental:
>>         * Certificate provided is signed by a CA that the client
>> recognises as a
>> valid trust anchor
>>         * Certificate is in-date
>>         * No support for known-poor algorithms
>>         * Service offering SSL cannot be forced into plaintext
>>         * SSLv3 TLSv1 Minimum
>>
>> Standard:
>>         * Revocation information is checked (CRL/OCSP)
>>         * CNAME is valid for the server
>>
>> Enhanced:
>>         * Support only for strongest available algorithms
>>         * X.509v3 Extended Key Usage flags OID verified
>>         * Client Certificates have Role-Specific CNAME and verification is
>> supported
>>
>> Please comment or add things to the list, also if you've already done some
>> similar work please drop me a line so I can include your results.
>>
>> Finally, if you want to help do some of this please feel free!
>>
>> -Rob
>>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121030/21f816e6/attachment-0001.html>