Open Stack

On Jul 17, 2014, at 4:59 PM, Stephen Balukoff <sbalukoff at bluebox.net> wrote:

> From the comments there, I think the reason for storing the subjectAltNames was to minimize the number of calls we will need to make to barbican, and because the barbican container is immutable, and therefore the list of subjectAltNames won't change so long as the container exists, and we don't have to worry about cache invalidation. (Because really, storing the subjectAltNames locally is a cache.)  We could accomplish the same thing by storing the cert (NOT the key) in our database as well and extracting the information from the x509 cert that we want on the fly. But this also seems like we're doing more work than necessary to keep extracting the same data from the same certificate that will never change.

    I'm more forgiving of duplicating work at API time but not on every backend LB https request. Thats insane.
The question for me is more of a balancing act between attempting "Single Source of Truth" design versus painful repeated computation. which I though repeating the computations at the API layer was acceptable. If we are disciplined enough to guarantee the cert won't fall out of sync with the entries in the database I'm fine with not reparseing the X509 on the fly. I just don't know what level of trust we have for our selves.


> How we store this in the database is something I'm less opinionated about, but your idea that storing this data in a separate table seems to make sense.
> 
> Do you really see a need to be concerned with anything but GEN_DNS entries here? Or put another way, is there an application that would likely be used in load balancing that makes use of any subjectAltName entries that are not DNSNames? (I'm pretty sure that's all that all the major browsers look at anyway-- and I don't see them changing any time soon since this satisfies the need for implementing SNI.)  Secondary to this, does supporting other subjectAltName types in our code cause any extra significant complication?  

    Well no GEN_DNS is it for now but to make the code https://github.com/pyca/pyopenssl/pull/143 more attractive for merging to the pyopenssl folks I implemented most of the other entry types as well but we can ignore all but the dNSName entries.

> In practice, I think anything that does TERMINATED_HTTPS as the listener protocol is only going to care about dNSName entries and ignore the rest-- but if supporting the rest opens the door for more general-purpose forms of TLS, I don't see harm in extracting these other subjectAltName types from the x509 cert. It certainly "feels" more correct to treat these for what they are: the tuples you've described.
> 
> Thanks,
> Stephen
> 
> 
> 
> On Thu, Jul 17, 2014 at 2:29 PM, Carlos Garza <carlos.garza at rackspace.com> wrote:
> I added the following comments to patch 14 but I'm not -1 it but I think its a mistake
> to assume the altSubjectName is a string type. See below.
> 
> --- Comments on patch 14 below ----
> 
> SubjectAltNames are not a string and should be thought
>  of as an array of tuples. Example
>  [('dNSName','www.somehost.com'),
> ('dirNameCN','www.somehostFromAltCN.org'),
> ('dirNameCN','www.anotherHostFromAltCN.org')]
> 
> for right now we only care about entries that are of type dNSName
> or the entries that are of type DirName that also contain a CN in the DirName container. All other AltNames can be ignores as they don't seem to be apart of hostname validation in PKIX
> 
>     Also we don't need to store these in the object model. since these
> can be extracted from the X509 on the fly. Just be aware though that
> the SubjectAltName should not be treated as a simple string but as a
> list of (general_name_type,general_name_value) tuples
> 
> were really close to the end but we can't mess this one up.
> 
>     I'm flexible if you want these values store in the database
> or not. If we do store it in a database we need a table called
> general_names that contains varchars for type and value for
> now with what ever you guys want to use for the keys. to
> map back to the tls_container_id. unless we want with a
> firm decision on what strings in type should map to
> GEN_DNS and GEN_DIRNAME CN entries from the
> OpenSSL layer.
> 
> For now we can skip GEN_DIRNAME entries since RFC2818 doesn't mandate its support and I'm not sure if fetching the CN from the DirName is in practice now. I'm leery of using CN's from DirName entries as I can imagine people signing differen't X509Names as a DirName with no intention of host name validation. Excample
> "(dirName, 'cn=john.garza,ou=people,o=somecompany)"
> 
> dNSName and DirName encodings are mentioned in RFC2459. if you want a more formal definition.
> 
> On Jul 17, 2014, at 10:19 AM, Stephen Balukoff <sbalukoff at bluebox.net> wrote:
> 
> > Ok, folks!
> >
> > Per the IRC meeting this morning, we came to the following consensus regarding how TLS certificates are handled, how SAN is handled, and how hostname conflict resolution is handled. I will be responding to all three of the currently ongoing mailing list discussions with this info:
> >
> >       • Driver does not have to use SAN that is passed from API layer, but SAN will be available to drivers at the API layer. This will be mentioned explicitly in the spec.
> >       • Order is a mandatory attribute. It's intended to be used as a "hint" for hostname conflict resolution, but it's ultimately up to the driver to decide how to resolve the conflict. (In other words, although it is a mandatory attribute in our model, drivers are free to ignore it.)
> >       • Drivers are allowed to vary their behavior when choosing how to implement hostname conflict resolution since there is no single algorithm here that all vendors are able to support. (This is anticipated to be a rare edge case anyway.)
> > I think Evgeny will be updating the specs to reflect this decision so that it is documented--  we hope to get ultimate approval of the spec in the next day or two.
> >
> > Thanks,
> > Stephen
> >
> >
> >
> >
> > On Wed, Jul 16, 2014 at 7:31 PM, Stephen Balukoff <sbalukoff at bluebox.net> wrote:
> > Just saw this thread after responding to the other:
> >
> > I'm in favor of Evgeny's proposal. It sounds like it should resolve most (if not all) of the operators', vendors' and users' concerns with regard to handling TLS certificates.
> >
> > Stephen
> >
> >
> > On Wed, Jul 16, 2014 at 12:35 PM, Carlos Garza <carlos.garza at rackspace.com> wrote:
> >
> > On Jul 16, 2014, at 10:55 AM, Vijay Venkatachalam <Vijay.Venkatachalam at citrix.com>
> >  wrote:
> >
> > > Apologies for the delayed response.
> > >
> > > I am OK with displaying the certificates contents as part of the API, that should not harm.
> > >
> > > I think the discussion has to be split into 2 topics.
> > >
> > > 1.       Certificate conflict resolution. Meaning what is expected when 2 or more certificates become eligible during SSL negotiation
> > > 2.       SAN support
> > >
> >
> >     Ok cool that makes more sense. #2 seems to be met by Evgeny proposal. I'll let you folks decide the conflict resolution issue #1.
> >
> >
> > > I will send out 2 separate mails on this.
> > >
> > >
> > > From: Samuel Bercovici [mailto:SamuelB at Radware.com]
> > > Sent: Tuesday, July 15, 2014 11:52 PM
> > > To: OpenStack Development Mailing List (not for usage questions); Vijay Venkatachalam
> > > Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
> > >
> > > OK.
> > >
> > > Let me be more precise, extracting the information for view sake / validation would be good.
> > > Providing values that are different than what is in the x509 is what I am opposed to.
> > >
> > > +1 for Carlos on the library and that it should be ubiquitously used.
> > >
> > > I will wait for Vijay to speak for himself in this regard…
> > >
> > > -Sam.
> > >
> > >
> > > From: Stephen Balukoff [mailto:sbalukoff at bluebox.net]
> > > Sent: Tuesday, July 15, 2014 8:35 PM
> > > To: OpenStack Development Mailing List (not for usage questions)
> > > Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
> > >
> > > +1 to German's and  Carlos' comments.
> > >
> > > It's also worth pointing out that some UIs will definitely want to show SAN information and the like, so either having this available as part of the API, or as a standard library we write which then gets used by multiple drivers is going to be necessary.
> > >
> > > If we're extracting the Subject Common Name in any place in the code then we also need to be extracting the Subject Alternative Names at the same place. From the perspective of the SNI standard, there's no difference in how these fields should be treated, and if we were to treat SANs differently then we're both breaking the standard and setting a bad precedent.
> > >
> > > Stephen
> > >
> > >
> > > On Tue, Jul 15, 2014 at 9:35 AM, Carlos Garza <carlos.garza at rackspace.com> wrote:
> > >
> > > On Jul 15, 2014, at 10:55 AM, Samuel Bercovici <SamuelB at Radware.com>
> > >  wrote:
> > >
> > > > Hi,
> > > >
> > > >
> > > > Obtaining the domain name from the x509 is probably more of a driver/backend/device capability, it would make sense to have a library that could be used by anyone wishing to do so in their driver code.
> > >
> > >     You can do what ever you want in *your* driver. The code to extract this information will be apart of the API and needs to be mentioned in the spec now. PyOpenSSL with PyASN1 are the most likely candidates.
> > >
> > > Carlos D. Garza
> > > >
> > > > -Sam.
> > > >
> > > >
> > > >
> > > > From: Eichberger, German [mailto:german.eichberger at hp.com]
> > > > Sent: Tuesday, July 15, 2014 6:43 PM
> > > > To: OpenStack Development Mailing List (not for usage questions)
> > > > Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
> > > >
> > > > Hi,
> > > >
> > > > My impression was that the frontend would extract the names and hand them to the driver.  This has the following advantages:
> > > >
> > > > ·         We can be sure all drivers can extract the same names
> > > > ·         No duplicate code to maintain
> > > > ·         If we ever allow the user to specify the names on UI rather in the certificate the driver doesn’t need to change.
> > > >
> > > > I think I saw Adam say something similar in a comment to the code.
> > > >
> > > > Thanks,
> > > > German
> > > >
> > > > From: Evgeny Fedoruk [mailto:EvgenyF at Radware.com]
> > > > Sent: Tuesday, July 15, 2014 7:24 AM
> > > > To: OpenStack Development Mailing List (not for usage questions)
> > > > Subject: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509
> > > >
> > > > Hi All,
> > > >
> > > > Since this issue came up from TLS capabilities RST doc review, I opened a ML thread for it to make the decision.
> > > > Currently, the document says:
> > > >
> > > > “
> > > > For SNI functionality, tenant will supply list of TLS containers in specific
> > > > Order.
> > > > In case when specific back-end is not able to support SNI capabilities,
> > > > its driver should throw an exception. The exception message should state
> > > > that this specific back-end (provider) does not support SNI capability.
> > > > The clear sign of listener's requirement for SNI capability is
> > > > a none empty SNI container ids list.
> > > > However, reference implementation must support SNI capability.
> > > >
> > > > Specific back-end code may retrieve SubjectCommonName and/or altSubjectNames
> > > > from the certificate which will determine the hostname(s) the certificate
> > > > is associated with.
> > > >
> > > > The order of SNI containers list may be used by specific back-end code,
> > > > like Radware's, for specifying priorities among certificates.
> > > > In case when two or more uploaded certificates are valid for the same DNS name
> > > > and the tenant has specific requirements around which one wins this collision,
> > > > certificate ordering provides a mechanism to define which cert wins in the
> > > > event of a collision.
> > > > Employing the order of certificates list is not a common requirement for
> > > > all back-end implementations.
> > > > “
> > > >
> > > > The question is about SCN and SAN extraction from X509.
> > > > 1.       Extraction of SCN/ SAN should be done while provisioning and not during TLS handshake
> > > > 2.       Every back-end code/driver must(?) extract SCN and(?) SAN and use it for certificate determination for host
> > > >
> > > > Please give your feedback
> > > >
> > > > Thanks,
> > > > Evg
> > > > _______________________________________________
> > > > OpenStack-dev mailing list
> > > > 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
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> > >
> > > --
> > > Stephen Balukoff
> > > Blue Box Group, LLC
> > > (800)613-4305 x807
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > 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
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > --
> > Stephen Balukoff
> > Blue Box Group, LLC
> > (800)613-4305 x807
> >
> >
> >
> > --
> > Stephen Balukoff
> > Blue Box Group, LLC
> > (800)613-4305 x807
> > _______________________________________________
> > OpenStack-dev mailing list
> > 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> -- 
> Stephen Balukoff 
> Blue Box Group, LLC 
> (800)613-4305 x807
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev