Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SubjectAlternativeNames (SAN)
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:41 PM, Stephen Balukoff sbaluk...@bluebox.net wrote: Vijay-- I'm confused: If NetScaler doesn't actually look at the SAN, isn't it not actually following the SNI standard? (RFC2818 page 4, paragraph 2, as I think Carlos pointed out in another thread.) Or at least, isn't that ignoring how every major browser on the market that support SNI operates? Anyway, per the other thread we've had on this, and Evgeny's proposal there, do you see harm in having SAN available at the API level (informationally, at least). In any case, duplication of code is something I think we can all agree is not desirable, and because so many other implementations are likely to need the SAN info, it should be available to drivers via a universal library (as Carlos is describing). Stephen On Wed, Jul 16, 2014 at 3:43 PM, Eichberger, German german.eichber...@hp.com wrote: +1 for not duplicating code For me it's scary as well if different implementation exhibit different behavior. This very contrary to what we would like to do with exposing LBs only as flavor... German -Original Message- From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Wednesday, July 16, 2014 2:05 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SubjectAlternativeNames (SAN) On Jul 16, 2014, at 3:49 PM, Carlos Garza carlos.ga...@rackspace.com wrote: On Jul 16, 2014, at 12:30 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: We will have the code that will parse the X509 in the API scope of the code. The validation I'm refering to is making sure the key matches the cert used and that we mandate that at a minimum the backend driver support RSA and that since the X509 validation is happeneing at the api layer this same module will also handling the extraction of the SANs. I am proposing that the methods that can extract the SAN SCN from the x509 be present in the api portion of the code and that drivers can call these methods if they need too. Infact I'm already working to get these extraction methods contributed to the PyOpenSSL project so that they will already available at a more fundemental layer then our nuetron/LBAAS code. At the very least I want to spec to declare that SAN SCN and parsing must be made available from the API layer. If the PyOpenSSL has the methods available at that time then I we can simply write wrappers for this in the API or simple write more higher level methods in the API module. I meant to say bottom line I want the parsing code exposed in the API and not duplicated in everyone elses driver. I am partioally open to the idea of letting the driver handle the behavior of the cert parsing. Although I defer this to the rest of the folks as I get this feeling having differn't implementations exhibiting differen't behavior may sound scary. I think it is best not to mention about SAN in the OpenStack TLS spec. It is expected that the backend should implement according to the SSL/SNI IETF spec. Let's leave the implementation/validation part to the driver. For ex. NetScaler does not support SAN and the NetScaler driver could either throw an error if certs with SAN are used or ignore it. How is netscaler making the decision when choosing the cert to associate with the SNI handshake? Does anyone see a requirement for detailing? Thanks, Vijay V. From: Vijay Venkatachalam Sent: Wednesday, July 16, 2014 8:54 AM To: 'Samuel Bercovici'; 'OpenStack Development Mailing List (not for usage questions)' Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SubjectAlternativeNames (SAN)
I think it is best not to mention about SAN in the OpenStack TLS spec. It is expected that the backend should implement according to the SSL/SNI IETF spec. Let’s leave the implementation/validation part to the driver. For ex. NetScaler does not support SAN and the NetScaler driver could either throw an error if certs with SAN are used or ignore it. Does anyone see a requirement for detailing? Thanks, Vijay V. From: Vijay Venkatachalam Sent: Wednesday, July 16, 2014 8:54 AM To: 'Samuel Bercovici'; 'OpenStack Development Mailing List (not for usage questions)' Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 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 I will send out 2 separate mails on this. 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.
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SubjectAlternativeNames (SAN)
On Jul 16, 2014, at 12:30 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: We will have the code that will parse the X509 in the API scope of the code. The validation I'm refering to is making sure the key matches the cert used and that we mandate that at a minimum the backend driver support RSA and that since the X509 validation is happeneing at the api layer this same module will also handling the extraction of the SANs. I am proposing that the methods that can extract the SAN SCN from the x509 be present in the api portion of the code and that drivers can call these methods if they need too. Infact I'm already working to get these extraction methods contributed to the PyOpenSSL project so that they will already available at a more fundemental layer then our nuetron/LBAAS code. At the very least I want to spec to declare that SAN SCN and parsing must be made available from the API layer. If the PyOpenSSL has the methods available at that time then I we can simply write wrappers for this in the API or simple write more higher level methods in the API module. Bottom line I I am partioally open to the idea of letting the driver handle the behavior of the cert parsing. Although I defer this to the rest of the folks as I get this feeling having differn't implementations exhibiting differen't behavior may sound scary. I think it is best not to mention about SAN in the OpenStack TLS spec. It is expected that the backend should implement according to the SSL/SNI IETF spec. Let’s leave the implementation/validation part to the driver. For ex. NetScaler does not support SAN and the NetScaler driver could either throw an error if certs with SAN are used or ignore it. How is netscaler making the decision when choosing the cert to associate with the SNI handshake? Does anyone see a requirement for detailing? Thanks, Vijay V. From: Vijay Venkatachalam Sent: Wednesday, July 16, 2014 8:54 AM To: 'Samuel Bercovici'; 'OpenStack Development Mailing List (not for usage questions)' Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 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 I will send out 2 separate mails on this. 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 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:
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SubjectAlternativeNames (SAN)
On Jul 16, 2014, at 3:49 PM, Carlos Garza carlos.ga...@rackspace.com wrote: On Jul 16, 2014, at 12:30 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: We will have the code that will parse the X509 in the API scope of the code. The validation I'm refering to is making sure the key matches the cert used and that we mandate that at a minimum the backend driver support RSA and that since the X509 validation is happeneing at the api layer this same module will also handling the extraction of the SANs. I am proposing that the methods that can extract the SAN SCN from the x509 be present in the api portion of the code and that drivers can call these methods if they need too. Infact I'm already working to get these extraction methods contributed to the PyOpenSSL project so that they will already available at a more fundemental layer then our nuetron/LBAAS code. At the very least I want to spec to declare that SAN SCN and parsing must be made available from the API layer. If the PyOpenSSL has the methods available at that time then I we can simply write wrappers for this in the API or simple write more higher level methods in the API module. I meant to say bottom line I want the parsing code exposed in the API and not duplicated in everyone elses driver. I am partioally open to the idea of letting the driver handle the behavior of the cert parsing. Although I defer this to the rest of the folks as I get this feeling having differn't implementations exhibiting differen't behavior may sound scary. I think it is best not to mention about SAN in the OpenStack TLS spec. It is expected that the backend should implement according to the SSL/SNI IETF spec. Let’s leave the implementation/validation part to the driver. For ex. NetScaler does not support SAN and the NetScaler driver could either throw an error if certs with SAN are used or ignore it. How is netscaler making the decision when choosing the cert to associate with the SNI handshake? Does anyone see a requirement for detailing? Thanks, Vijay V. From: Vijay Venkatachalam Sent: Wednesday, July 16, 2014 8:54 AM To: 'Samuel Bercovici'; 'OpenStack Development Mailing List (not for usage questions)' Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 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 I will send out 2 separate mails on this. 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 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
Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SubjectAlternativeNames (SAN)
Vijay-- I'm confused: If NetScaler doesn't actually look at the SAN, isn't it not actually following the SNI standard? (RFC2818 page 4, paragraph 2, as I think Carlos pointed out in another thread.) Or at least, isn't that ignoring how every major browser on the market that support SNI operates? Anyway, per the other thread we've had on this, and Evgeny's proposal there, do you see harm in having SAN available at the API level (informationally, at least). In any case, duplication of code is something I think we can all agree is not desirable, and because so many other implementations are likely to need the SAN info, it should be available to drivers via a universal library (as Carlos is describing). Stephen On Wed, Jul 16, 2014 at 3:43 PM, Eichberger, German german.eichber...@hp.com wrote: +1 for not duplicating code For me it's scary as well if different implementation exhibit different behavior. This very contrary to what we would like to do with exposing LBs only as flavor... German -Original Message- From: Carlos Garza [mailto:carlos.ga...@rackspace.com] Sent: Wednesday, July 16, 2014 2:05 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] TLS capability - SubjectAlternativeNames (SAN) On Jul 16, 2014, at 3:49 PM, Carlos Garza carlos.ga...@rackspace.com wrote: On Jul 16, 2014, at 12:30 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: We will have the code that will parse the X509 in the API scope of the code. The validation I'm refering to is making sure the key matches the cert used and that we mandate that at a minimum the backend driver support RSA and that since the X509 validation is happeneing at the api layer this same module will also handling the extraction of the SANs. I am proposing that the methods that can extract the SAN SCN from the x509 be present in the api portion of the code and that drivers can call these methods if they need too. Infact I'm already working to get these extraction methods contributed to the PyOpenSSL project so that they will already available at a more fundemental layer then our nuetron/LBAAS code. At the very least I want to spec to declare that SAN SCN and parsing must be made available from the API layer. If the PyOpenSSL has the methods available at that time then I we can simply write wrappers for this in the API or simple write more higher level methods in the API module. I meant to say bottom line I want the parsing code exposed in the API and not duplicated in everyone elses driver. I am partioally open to the idea of letting the driver handle the behavior of the cert parsing. Although I defer this to the rest of the folks as I get this feeling having differn't implementations exhibiting differen't behavior may sound scary. I think it is best not to mention about SAN in the OpenStack TLS spec. It is expected that the backend should implement according to the SSL/SNI IETF spec. Let's leave the implementation/validation part to the driver. For ex. NetScaler does not support SAN and the NetScaler driver could either throw an error if certs with SAN are used or ignore it. How is netscaler making the decision when choosing the cert to associate with the SNI handshake? Does anyone see a requirement for detailing? Thanks, Vijay V. From: Vijay Venkatachalam Sent: Wednesday, July 16, 2014 8:54 AM To: 'Samuel Bercovici'; 'OpenStack Development Mailing List (not for usage questions)' Subject: RE: [openstack-dev] [Neutron][LBaaS] TLS capability - SNI - Extracting SubjectCommonName and/or SubjectAlternativeNames from X509 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 I will send out 2 separate mails on this. 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
