Open Stack

Nate,

It absolutely makes a bunch of sense to standardise on something but understanding what and why will be tricky. I'm hoping that the SSL Review will inform the decision somewhat.

-Rob

Robert,

Yeah, I've noticed similar issues with subjectAltNames in the past. For keystone, which uses python-httplib2, it currently only works with subjectAltNames if you have the CN repeated otherwise it only thinks the names in the subjectAltNames are the valid hostnames and doesn't even use the CN. I would call that a bug in httplib2. I also don't think httplib2 currently works when IPs are used in the subjectAltName because it only looks at ones with 'DNS' tagged names.

Separate but related, would it be worthwhile making all the clients standardize on a particular SSL http library? Some use python-httplib, python-httplib2, etc...

Nate

On Oct 30, 2012 11:47 AM, "Clark, Robert Graham" <robert.clark at hp.com<mailto:robert.clark at hp.com>> wrote:
Hi Nate,

In this context yes, when I (or my esteemed colleague Stuart) mention
CNAME we actually mean the x509 Common Name otherwise referred to as CN.

You make a good point around subjectAlternativeNames, whenever a
certificate is presented we should check against the CN and the SANs, if
the certificate has SANs.

There's often confusion as to wether the stated CN of a certificate should
appear in the SANs, this often gets people confused so to get ahead of
that, here's what RFC 5280 Section 4.1.2.6 has to say:

"""
The subject field identifies the entity associated with the public key
stored in the subject public key field. The subject name MAY be carried in
the subject field and/or the subjectAltName extension.However, there are
some compatibility issues with some TLS implementations, LDAP appears to
require the Common Name to be repeated in the SAN.
"""

I'm going to add this into the 'standard' grade of SSL, below.



>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<mailto: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
>
>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<mailto:robert.clark at hp.com>>
>To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
>Subject: [openstack-dev] [OSSG] SSL Review
>Message-ID: <CCB540CA.E6B5%robert.clark at hp.com<mailto:CCB540CA.E6B5%25robert.clark at hp.com>
><mailto:CCB540CA.E6B5%25robert.clark at hp.com<mailto:CCB540CA.E6B5%2525robert.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)
>        * CN is valid for the server
          * SANs checked for valid match
>
>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<mailto:OpenStack-dev at lists.openstack.org>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev