Re: [openstack-dev] [Neutron][LBaaS] TLS capability - Certificate conflict resolution
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:26 PM, Stephen Balukoff sbaluk...@bluebox.net wrote: Hi Vijay, On Wed, Jul 16, 2014 at 9:07 AM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Do you know if the SSL/SNI IETF spec details about conflict resolution. I am assuming not. Because of this ambiguity each backend employs its own mechanism to resolve conflicts. There are 3 choices now 1. The LBaaS extension does not allow conflicting certificates to be bound using validation 2. Allow each backend conflict resolution mechanism to get into the spec 3. Does not specify anything in the spec, no mechanism introduced and let the driver deal with it. Both HA proxy and Radware uses configuration as a mechanism to resolve. Radware uses order while HA Proxy uses externally specified DNS names. NetScaler implementation uses the best possible match algorithm For ex, let’s say 3 certs are bound to the same endpoint with the following SNs www.finance.abc.com *.finance.abc.com *.*.abc.com If the host request is payroll.finance.abc.com we shall use *. finance.abc.com If it is payroll.engg.abc.com we shall use *.*.abc.com NetScaler won’t not allow 2 certs to have the same SN. Did you mean CN as in Common Name above? In any case, it sounds like: 1. Conflicts are going to be relatively rare in any case 2. Conflict resolution as such can probably be left to the vendor. Since the Neutron LBaaS reference implementation uses HAProxy, it seems logical that this should be considered normal behavior for the Neutron LBaaS service-- though again the slight variations in vendor implementations for conflict resolution are unlikely to cause serious issues for most users. If NetScaler runs into a situation where the SCN of a cert conflicts with the SCN or SAN of another cert, then perhaps they can return an 'UnsupportedConfigruation' error or whatnot? (I believe we're trying to get the ability to return such errors with the flavor framework, correct?) In any case, is there any reason to delay going forward with a model and code that: A. Uses an 'order' attribute on the SNI-related objects to resolve name conflicts. B. Includes a ubiquitous library for extracting SCN and SAN that any driver may use if they don't use the 'order' attribute? Thanks, Stephen -- 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS] TLS capability - Certificate conflict resolution
Do you know if the SSL/SNI IETF spec details about conflict resolution. I am assuming not. Because of this ambiguity each backend employs its own mechanism to resolve conflicts. There are 3 choices now 1. The LBaaS extension does not allow conflicting certificates to be bound using validation 2. Allow each backend conflict resolution mechanism to get into the spec 3. Does not specify anything in the spec, no mechanism introduced and let the driver deal with it. Both HA proxy and Radware uses configuration as a mechanism to resolve. Radware uses order while HA Proxy uses externally specified DNS names. NetScaler implementation uses the best possible match algorithm For ex, let’s say 3 certs are bound to the same endpoint with the following SNs www.finance.abc.comhttp://www.finance.abc.com *.finance.abc.com *.*.abc.com If the host request is payroll.finance.abc.com we shall use *.finance.abc.com If it is payroll.engg.abc.com we shall use *.*.abc.com NetScaler won’t not allow 2 certs to have the same SN. From: Samuel Bercovici [mailto:samu...@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:sbaluk...@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.ga...@rackspace.commailto:carlos.ga...@rackspace.com wrote: On Jul 15, 2014, at 10:55 AM, Samuel Bercovici samu...@radware.commailto:samu...@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.eichber...@hp.commailto:german.eichber...@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:evge...@radware.commailto:evge...@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
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - Certificate conflict resolution
On Jul 16, 2014, at 11:07 AM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Do you know if the SSL/SNI IETF spec details about conflict resolution. I am assuming not. The specs I have seen just describe SNI as a way of passing an intended host name in the clear during the TLS handshake. The specs do not describe the behavior of what the server should do with the SNI host or what peer certificate they should return based on it. The whole idea of SNI was that the server or something like a load balancer(Like we are doing) could make decisions based on this unencrypted value on the server side with out even knowing the private key. IE a loadbalancer doesn't even need to interact with the handshake(I've seen at least one tool that doesn't even use an SSL library to peek at the SNI host (looking at blue box)) and simply forward they tcp stream an appropriate back end node, at which point the back end interacts with the TLS handshake. In short the SAN SCN cruft was added to the spec as a convience method so that users could just upload their X509 set for SNI vs the original plan to upload a set of (hostname,X509ContainerId) tuples. The RFC seems to implie that it intends to deprecate the use of the SubjectCN to store the hostname for web certificates but since its so popular I'm guessing that'll never happen. By the way: RFC 2818 (HTTP-TLS) does dicate that if a subjectAltName extention with a dNSName entry exists then the dNSNames entries should be used for PKIX validation and not the SubjectCN. so PKIX validation that ignores the subjectAltName is already breaking RFC2818. Because of this ambiguity each backend employs its own mechanism to resolve conflicts. There are 3 choices now 1. The LBaaS extension does not allow conflicting certificates to be bound using validation 2. Allow each backend conflict resolution mechanism to get into the spec 3. Does not specify anything in the spec, no mechanism introduced and let the driver deal with it. I propose another optionspecifically #1 is not acceptable. 4. The spec should mandate that each driver document their SNI behavior and more specifically behavior on conflicts resolution. The vendor documentation doesn't have to be in the same spec or even in the lbaas project it just has to be documented some where central side beside with other vendors docs. Both HA proxy and Radware uses configuration as a mechanism to resolve. Radware uses order while HA Proxy uses externally specified DNS names. NetScaler implementation uses the best possible match algorithm For ex, let’s say 3 certs are bound to the same endpoint with the following SNs www.finance.abc.com *.finance.abc.com *.*.abc.com If the host request is payroll.finance.abc.com we shall use *.finance.abc.com If it is payroll.engg.abc.com we shall use *.*.abc.com NetScaler won’t not allow 2 certs to have the same SN. In this case NetScaler could document the behavior of their driver at that case. From: Samuel Bercovici [mailto:samu...@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:sbaluk...@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.ga...@rackspace.com wrote: On Jul 15, 2014, at 10:55 AM, Samuel Bercovici samu...@radware.com wrote: Hi, Obtaining the domain name from the x509 is probably more of a
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - Certificate conflict resolution
Hi Vijay, On Wed, Jul 16, 2014 at 9:07 AM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Do you know if the SSL/SNI IETF spec details about conflict resolution. I am assuming not. Because of this ambiguity each backend employs its own mechanism to resolve conflicts. There are 3 choices now 1. The LBaaS extension does not allow conflicting certificates to be bound using validation 2. Allow each backend conflict resolution mechanism to get into the spec 3. Does not specify anything in the spec, no mechanism introduced and let the driver deal with it. Both HA proxy and Radware uses configuration as a mechanism to resolve. Radware uses order while HA Proxy uses externally specified DNS names. NetScaler implementation uses the best possible match algorithm For ex, let’s say 3 certs are bound to the same endpoint with the following SNs www.finance.abc.com *.finance.abc.com *.*.abc.com If the host request is payroll.finance.abc.com we shall use *. finance.abc.com If it is payroll.engg.abc.com we shall use *.*.abc.com NetScaler won’t not allow 2 certs to have the same SN. Did you mean CN as in Common Name above? In any case, it sounds like: 1. Conflicts are going to be relatively rare in any case 2. Conflict resolution as such can probably be left to the vendor. Since the Neutron LBaaS reference implementation uses HAProxy, it seems logical that this should be considered normal behavior for the Neutron LBaaS service-- though again the slight variations in vendor implementations for conflict resolution are unlikely to cause serious issues for most users. If NetScaler runs into a situation where the SCN of a cert conflicts with the SCN or SAN of another cert, then perhaps they can return an 'UnsupportedConfigruation' error or whatnot? (I believe we're trying to get the ability to return such errors with the flavor framework, correct?) In any case, is there any reason to delay going forward with a model and code that: A. Uses an 'order' attribute on the SNI-related objects to resolve name conflicts. B. Includes a ubiquitous library for extracting SCN and SAN that any driver may use if they don't use the 'order' attribute? Thanks, Stephen -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
