[New Feature FS] SSL Offload Support for Cloudstack

[Syed Ahmed <sa...@cloudops.com>]

Hi,

I have been working on adding SSL offload functionality to cloudstack 
and make it work for Netscaler. I have an initial design documented at 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support 
and I would really love your feedback. The bug for this is 
https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .

Thanks,
-Syed

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Syed Ahmed <sa...@cloudops.com>]

> Additionally, I don't see that the code handles the
> chain also.  I could be wrong, but just from reading the code it seems
> to assume the "cert" string produces a single cert.  Correct me if I'm
> wrong.

You are right. This just handles a single certificate. It does not
handle trust chains.

>  (Don't let people remove a cert that is currently used).

You bring up an good point. I assumed that if the user deletes a
certificate, we internally go ahead and remove all the bindings from
LB rules. This happens with VM instances. The difference that I see is
if you remove the certificate, the LB goes down but if you remove an
instance the LB may still work.

>  I'm guessing you won't need to create any
> new managers, so that probably won't apply.

If I am giving the functionality of updating a certificate then my
CertificateService should call the resource layer for updating on the
device as well. Now from you mail what I understand is this has to be
done by creating a manager. So either we go ahead and drop the
updateCertificate call or we will have to add a manager for this. I
prefer dropping the updateCert call as I don't see anyone updating
cert contents frequently.

Thanks
-Syed







On Wed, Oct 9, 2013 at 1:02 AM, Darren Shepherd
<da...@gmail.com> wrote:
> I'm not too sure that its going to be worth it to reuse
> KeyStoreManager.  That code is for storage of certs for the systemvm.
> So you need to ensure that your changes don't overlap with the
> systemvm code.  Additionally, I don't see that the code handles the
> chain also.  I could be wrong, but just from reading the code it seems
> to assume the "cert" string produces a single cert.  Correct me if I'm
> wrong.
>
> The absolute key thing for this feature, in my mind, is getting the
> input validation right.  If you don't give useful errors, you'll be
> handling requests from people not being able to insert a cert, and the
> default errors from java are typically not very useful.
>
> Regarding design.  API Commands should synchronously call a Service
> class, this is the create() method of an async command or execute() of
> a non async command.  That service method should do no more than input
> validation and saving things to the database.  If you need to
> communicate to resources, then it should be an async api command.  The
> async portion of the API command, this would be the execute() method,
> should also call the service class.  Since you ideally did all the
> input validation in the sync portion, not much validation should
> happen at this point.  But there may be some more intensive validation
> you want to do at this point.  After validation, the service class
> should call the manager.  The manager does the real business logic.
>
> So you have two groups of functionality.  Managing SSL certs and then
> apply SSL to LB.  For the SSL cert management, I'd probably create a
> new CertificateService.  I think all the functionality is really just
> manipulating the DB, so all the calls can be sync.  (Don't let people
> remove a cert that is currently used).

> Now one of my pet peeves in ACS is that Service interface and Manager
> interface are always implemented by the same class.  This is bad, you
> end up bluring the lines of the architecture and code becomes a big
> blob, so avoid doing that.
>
> Darren
>
> On Tue, Oct 8, 2013 at 4:44 PM, Syed Ahmed <sa...@cloudops.com> wrote:
>> Thanks Edison for the reply.
>>
>> I see that there is already an implementation of KeystoreManager  which does
>> certificate validation and saves it in the keystore table. Also, the API
>> (UploadCustomCertificate) is only  callable from admin. I could add
>> functionality to this class for handling certificate chain  and also make
>> sure the table stores the account_id as well. We could reduce creating one
>> table by reusing the keystore table.
>>
>> I have a question about terminology. What is a service and a manager because
>> I see them both being used. In my case, I assume that my CertificateService
>> will have the KeystoreManager injected and the Service will serve as a proxy
>> between the Resource layer and the KeystoreManager which is the Db layer.
>> Will this approach work?
>>
>> Thanks
>> -Syed
>>
>>
>>
>> On Tue 08 Oct 2013 06:56:34 PM EDT, Edison Su wrote:
>>>
>>> There is command in ACS, UploadCustomCertificateCmd, which can receive ssl
>>> cert, key can chain as input. Maybe can share some code?
>>>
>>>> -----Original Message-----
>>>> From: Darren Shepherd [mailto:darren.s.shepherd@gmail.com]
>>>> Sent: Tuesday, October 08, 2013 1:54 PM
>>>> To: dev@cloudstack.apache.org
>>>> Subject: Re: [New Feature FS] SSL Offload Support for Cloudstack
>>>>
>>>> The API should do input validation on the SSL cert, key and chain.
>>>> Getting those three pieces of info is usually difficult for most people
>>>> to get
>>>> right as they don't really know what those three things are.  There's
>>>> about a
>>>> 80% chance most calls will fail.  If you rely on the provider it will
>>>> probably just
>>>> give back some general failure message that we won't be able to map back
>>>> to
>>>> the user as useful information.
>>>>
>>>> I would implement the cert management as a separate CertificateService.
>>>>
>>>> Darren
>>>>
>>>> On Tue, Oct 8, 2013 at 1:31 PM, Syed Ahmed <sy...@gmail.com>
>>>> wrote:
>>>>>
>>>>> A question about implementation. I was looking at other commands and
>>>>> the
>>>>> execute() method for each of the other commands seem to call a service
>>>>> ( _lbservice for example ) which takes care of updating the DB and
>>>>> calling the resource layer. Should the Certificate management be
>>>>> implemented as a service or is there something else that I can use? An
>>>>> example would be immensely helpful.
>>>>>
>>>>> Thanks
>>>>> -Syed
>>>>>
>>>>>
>>>>>
>>>>> On Tue 08 Oct 2013 03:22:14 PM EDT, Syed Ahmed wrote:
>>>>>>
>>>>>>
>>>>>> Thanks for the feedback guys. Really appreciate it.
>>>>>>
>>>>>> 1) Changing the name to SSL Termination.
>>>>>>
>>>>>> I don't have a problem with that. I was looking at Netscaler all the
>>>>>> time and they call it SSL offloading. But I agree that termination is
>>>>>> a more general term.
>>>>>> I have changed the name. The new page is at
>>>>>>
>>>>>>
>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Terminatio
>>>>>>
>>>>>> n+Support
>>>>>>
>>>>>>
>>>>>> 2) Specify the protocol type.
>>>>>>
>>>>>> Currently the protocol type of a loadbalncer gets set by checking the
>>>>>> source and destination port ( see getNetScalerProtocol() in
>>>>>> NetscalerResouce.java ) . So, we should change that and add another
>>>>>> optional field in the createLoadBalancerRule for protocol.
>>>>>>
>>>>>> 3) Certificate chain as a seperate parameter.
>>>>>>
>>>>>> Again, I was looking at Netscaler as an example but separating the
>>>>>> chain and certificate makes sense. I have updated the document
>>>>>> accordingly.
>>>>>>
>>>>>> I was assuming that the certificate parsing/validation would be done
>>>>>> by the device and we would just pass the certficate data as-is. But
>>>>>> if we are adding chains separately, we should have the ability to
>>>>>> parse and combine the chain and certificate for some devices as you
>>>>
>>>> mentioned.
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> -Syed
>>>>>>
>>>>>>
>>>>>> On Tue 08 Oct 2013 02:49:52 PM EDT, Chip Childers wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Technicality here, can we call the functionality SSL termination?
>>>>>>>> While technically we are "offloading" ssl from the VM, offloading
>>>>>>>> typically carries a connotation that its being done in hardware. So
>>>>>>>> we are really talking about SSL termination.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> +1 - completely agree. There's certainly the possibility of an
>>>>>>> *implementation* being true offloading, but I'd generalize to
>>>>>>> "termination" to account for a non-hardware offload of the crypto
>>>>>>> processing.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Couple comments. I wouldn't want to assume anything about SSL
>>>>
>>>> based
>>>>>>>>
>>>>>>>> on port numbers. So instead specify the protocol
>>>>>>>> (http/https/ssl/tcp) for the front and back side of the load
>>>>>>>> balancer. Additionally, I'd prefer the chain not be in the cert.
>>>>>>>> When configuring some backends you need the cert and chain
>>>>>>>> separate. It would be easier if they were stored that way.
>>>>>>>> Otherwise you have to do logic of parsing all the certs in the
>>>>>>>> "keystore"
>>>>
>>>> and look for the one that matches the key.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Also +1 to this. Cert chains may be optional, certainly, but should
>>>>>>> actually be separate from the actual cert in the configuration. The
>>>>>>> implementation may need to combine them into one document, but
>>>>>>> that's implementation specific.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Otherwise, awesome feature. I'll tell you, from an impl
>>>>>>>> perspective, parsing and validating the SSL certs is a pain. I can
>>>>>>>> probably find some java code to help out here on this as I've done
>>>>>>>> this before in the past.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Yes, this is a sorely needed feature. I'm happy to see this be added
>>>>>>> to the Netscaler plugin, and await a time when HA proxy has a stable
>>>>>>> release that includes SSL term.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Darren
>>>>>>>>
>>>>>>>> On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed <sa...@cloudops.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I have been working on adding SSL offload functionality to
>>>>>>>>> cloudstack and make it work for Netscaler. I have an initial
>>>>>>>>> design documented at
>>>>>>>>>
>>>>>>>>>
>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offload
>>>>>>>>>
>>>>>>>>> ing+Support
>>>>>>>>>
>>>>>>>>> and I would really love your feedback. The bug for this is
>>>>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> -Syed
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>
>>

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Darren Shepherd <da...@gmail.com>]

I'm not too sure that its going to be worth it to reuse
KeyStoreManager.  That code is for storage of certs for the systemvm.
So you need to ensure that your changes don't overlap with the
systemvm code.  Additionally, I don't see that the code handles the
chain also.  I could be wrong, but just from reading the code it seems
to assume the "cert" string produces a single cert.  Correct me if I'm
wrong.

The absolute key thing for this feature, in my mind, is getting the
input validation right.  If you don't give useful errors, you'll be
handling requests from people not being able to insert a cert, and the
default errors from java are typically not very useful.

Regarding design.  API Commands should synchronously call a Service
class, this is the create() method of an async command or execute() of
a non async command.  That service method should do no more than input
validation and saving things to the database.  If you need to
communicate to resources, then it should be an async api command.  The
async portion of the API command, this would be the execute() method,
should also call the service class.  Since you ideally did all the
input validation in the sync portion, not much validation should
happen at this point.  But there may be some more intensive validation
you want to do at this point.  After validation, the service class
should call the manager.  The manager does the real business logic.

So you have two groups of functionality.  Managing SSL certs and then
apply SSL to LB.  For the SSL cert management, I'd probably create a
new CertificateService.  I think all the functionality is really just
manipulating the DB, so all the calls can be sync.  (Don't let people
remove a cert that is currently used).  For associating SSL cert to
LB, you can probably piggy back on the existing LB services/managers.

Now one of my pet peeves in ACS is that Service interface and Manager
interface are always implemented by the same class.  This is bad, you
end up bluring the lines of the architecture and code becomes a big
blob, so avoid doing that.  I'm guessing you won't need to create any
new managers, so that probably won't apply.

Darren

On Tue, Oct 8, 2013 at 4:44 PM, Syed Ahmed <sa...@cloudops.com> wrote:
> Thanks Edison for the reply.
>
> I see that there is already an implementation of KeystoreManager  which does
> certificate validation and saves it in the keystore table. Also, the API
> (UploadCustomCertificate) is only  callable from admin. I could add
> functionality to this class for handling certificate chain  and also make
> sure the table stores the account_id as well. We could reduce creating one
> table by reusing the keystore table.
>
> I have a question about terminology. What is a service and a manager because
> I see them both being used. In my case, I assume that my CertificateService
> will have the KeystoreManager injected and the Service will serve as a proxy
> between the Resource layer and the KeystoreManager which is the Db layer.
> Will this approach work?
>
> Thanks
> -Syed
>
>
>
> On Tue 08 Oct 2013 06:56:34 PM EDT, Edison Su wrote:
>>
>> There is command in ACS, UploadCustomCertificateCmd, which can receive ssl
>> cert, key can chain as input. Maybe can share some code?
>>
>>> -----Original Message-----
>>> From: Darren Shepherd [mailto:darren.s.shepherd@gmail.com]
>>> Sent: Tuesday, October 08, 2013 1:54 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: [New Feature FS] SSL Offload Support for Cloudstack
>>>
>>> The API should do input validation on the SSL cert, key and chain.
>>> Getting those three pieces of info is usually difficult for most people
>>> to get
>>> right as they don't really know what those three things are.  There's
>>> about a
>>> 80% chance most calls will fail.  If you rely on the provider it will
>>> probably just
>>> give back some general failure message that we won't be able to map back
>>> to
>>> the user as useful information.
>>>
>>> I would implement the cert management as a separate CertificateService.
>>>
>>> Darren
>>>
>>> On Tue, Oct 8, 2013 at 1:31 PM, Syed Ahmed <sy...@gmail.com>
>>> wrote:
>>>>
>>>> A question about implementation. I was looking at other commands and
>>>> the
>>>> execute() method for each of the other commands seem to call a service
>>>> ( _lbservice for example ) which takes care of updating the DB and
>>>> calling the resource layer. Should the Certificate management be
>>>> implemented as a service or is there something else that I can use? An
>>>> example would be immensely helpful.
>>>>
>>>> Thanks
>>>> -Syed
>>>>
>>>>
>>>>
>>>> On Tue 08 Oct 2013 03:22:14 PM EDT, Syed Ahmed wrote:
>>>>>
>>>>>
>>>>> Thanks for the feedback guys. Really appreciate it.
>>>>>
>>>>> 1) Changing the name to SSL Termination.
>>>>>
>>>>> I don't have a problem with that. I was looking at Netscaler all the
>>>>> time and they call it SSL offloading. But I agree that termination is
>>>>> a more general term.
>>>>> I have changed the name. The new page is at
>>>>>
>>>>>
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Terminatio
>>>>>
>>>>> n+Support
>>>>>
>>>>>
>>>>> 2) Specify the protocol type.
>>>>>
>>>>> Currently the protocol type of a loadbalncer gets set by checking the
>>>>> source and destination port ( see getNetScalerProtocol() in
>>>>> NetscalerResouce.java ) . So, we should change that and add another
>>>>> optional field in the createLoadBalancerRule for protocol.
>>>>>
>>>>> 3) Certificate chain as a seperate parameter.
>>>>>
>>>>> Again, I was looking at Netscaler as an example but separating the
>>>>> chain and certificate makes sense. I have updated the document
>>>>> accordingly.
>>>>>
>>>>> I was assuming that the certificate parsing/validation would be done
>>>>> by the device and we would just pass the certficate data as-is. But
>>>>> if we are adding chains separately, we should have the ability to
>>>>> parse and combine the chain and certificate for some devices as you
>>>
>>> mentioned.
>>>>>
>>>>>
>>>>> Thanks
>>>>> -Syed
>>>>>
>>>>>
>>>>> On Tue 08 Oct 2013 02:49:52 PM EDT, Chip Childers wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Technicality here, can we call the functionality SSL termination?
>>>>>>> While technically we are "offloading" ssl from the VM, offloading
>>>>>>> typically carries a connotation that its being done in hardware. So
>>>>>>> we are really talking about SSL termination.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> +1 - completely agree. There's certainly the possibility of an
>>>>>> *implementation* being true offloading, but I'd generalize to
>>>>>> "termination" to account for a non-hardware offload of the crypto
>>>>>> processing.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Couple comments. I wouldn't want to assume anything about SSL
>>>
>>> based
>>>>>>>
>>>>>>> on port numbers. So instead specify the protocol
>>>>>>> (http/https/ssl/tcp) for the front and back side of the load
>>>>>>> balancer. Additionally, I'd prefer the chain not be in the cert.
>>>>>>> When configuring some backends you need the cert and chain
>>>>>>> separate. It would be easier if they were stored that way.
>>>>>>> Otherwise you have to do logic of parsing all the certs in the
>>>>>>> "keystore"
>>>
>>> and look for the one that matches the key.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Also +1 to this. Cert chains may be optional, certainly, but should
>>>>>> actually be separate from the actual cert in the configuration. The
>>>>>> implementation may need to combine them into one document, but
>>>>>> that's implementation specific.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Otherwise, awesome feature. I'll tell you, from an impl
>>>>>>> perspective, parsing and validating the SSL certs is a pain. I can
>>>>>>> probably find some java code to help out here on this as I've done
>>>>>>> this before in the past.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes, this is a sorely needed feature. I'm happy to see this be added
>>>>>> to the Netscaler plugin, and await a time when HA proxy has a stable
>>>>>> release that includes SSL term.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Darren
>>>>>>>
>>>>>>> On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed <sa...@cloudops.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I have been working on adding SSL offload functionality to
>>>>>>>> cloudstack and make it work for Netscaler. I have an initial
>>>>>>>> design documented at
>>>>>>>>
>>>>>>>>
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offload
>>>>>>>>
>>>>>>>> ing+Support
>>>>>>>>
>>>>>>>> and I would really love your feedback. The bug for this is
>>>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> -Syed
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>
>

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Syed Ahmed <sa...@cloudops.com>]

Thanks Edison for the reply.

I see that there is already an implementation of KeystoreManager  which 
does certificate validation and saves it in the keystore table. Also, 
the API (UploadCustomCertificate) is only  callable from admin. I could 
 add functionality to this class for handling certificate chain  and 
also make sure the table stores the account_id as well. We could reduce 
creating one table by reusing the keystore table.

I have a question about terminology. What is a service and a manager 
because I see them both being used. In my case, I assume that my 
CertificateService will have the KeystoreManager injected and the 
Service will serve as a proxy between the Resource layer and the 
KeystoreManager which is the Db layer. Will this approach work?

Thanks
-Syed


On Tue 08 Oct 2013 06:56:34 PM EDT, Edison Su wrote:
> There is command in ACS, UploadCustomCertificateCmd, which can receive ssl cert, key can chain as input. Maybe can share some code?
>
>> -----Original Message-----
>> From: Darren Shepherd [mailto:darren.s.shepherd@gmail.com]
>> Sent: Tuesday, October 08, 2013 1:54 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [New Feature FS] SSL Offload Support for Cloudstack
>>
>> The API should do input validation on the SSL cert, key and chain.
>> Getting those three pieces of info is usually difficult for most people to get
>> right as they don't really know what those three things are.  There's about a
>> 80% chance most calls will fail.  If you rely on the provider it will probably just
>> give back some general failure message that we won't be able to map back to
>> the user as useful information.
>>
>> I would implement the cert management as a separate CertificateService.
>>
>> Darren
>>
>> On Tue, Oct 8, 2013 at 1:31 PM, Syed Ahmed <sy...@gmail.com>
>> wrote:
>>> A question about implementation. I was looking at other commands and
>>> the
>>> execute() method for each of the other commands seem to call a service
>>> ( _lbservice for example ) which takes care of updating the DB and
>>> calling the resource layer. Should the Certificate management be
>>> implemented as a service or is there something else that I can use? An
>>> example would be immensely helpful.
>>>
>>> Thanks
>>> -Syed
>>>
>>>
>>>
>>> On Tue 08 Oct 2013 03:22:14 PM EDT, Syed Ahmed wrote:
>>>>
>>>> Thanks for the feedback guys. Really appreciate it.
>>>>
>>>> 1) Changing the name to SSL Termination.
>>>>
>>>> I don't have a problem with that. I was looking at Netscaler all the
>>>> time and they call it SSL offloading. But I agree that termination is
>>>> a more general term.
>>>> I have changed the name. The new page is at
>>>>
>>>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Terminatio
>>>> n+Support
>>>>
>>>>
>>>> 2) Specify the protocol type.
>>>>
>>>> Currently the protocol type of a loadbalncer gets set by checking the
>>>> source and destination port ( see getNetScalerProtocol() in
>>>> NetscalerResouce.java ) . So, we should change that and add another
>>>> optional field in the createLoadBalancerRule for protocol.
>>>>
>>>> 3) Certificate chain as a seperate parameter.
>>>>
>>>> Again, I was looking at Netscaler as an example but separating the
>>>> chain and certificate makes sense. I have updated the document
>>>> accordingly.
>>>>
>>>> I was assuming that the certificate parsing/validation would be done
>>>> by the device and we would just pass the certficate data as-is. But
>>>> if we are adding chains separately, we should have the ability to
>>>> parse and combine the chain and certificate for some devices as you
>> mentioned.
>>>>
>>>> Thanks
>>>> -Syed
>>>>
>>>>
>>>> On Tue 08 Oct 2013 02:49:52 PM EDT, Chip Childers wrote:
>>>>>
>>>>>
>>>>> On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote:
>>>>>>
>>>>>>
>>>>>> Technicality here, can we call the functionality SSL termination?
>>>>>> While technically we are "offloading" ssl from the VM, offloading
>>>>>> typically carries a connotation that its being done in hardware. So
>>>>>> we are really talking about SSL termination.
>>>>>
>>>>>
>>>>>
>>>>> +1 - completely agree. There's certainly the possibility of an
>>>>> *implementation* being true offloading, but I'd generalize to
>>>>> "termination" to account for a non-hardware offload of the crypto
>>>>> processing.
>>>>>
>>>>>>
>>>>>>
>>>>>> Couple comments. I wouldn't want to assume anything about SSL
>> based
>>>>>> on port numbers. So instead specify the protocol
>>>>>> (http/https/ssl/tcp) for the front and back side of the load
>>>>>> balancer. Additionally, I'd prefer the chain not be in the cert.
>>>>>> When configuring some backends you need the cert and chain
>>>>>> separate. It would be easier if they were stored that way.
>>>>>> Otherwise you have to do logic of parsing all the certs in the "keystore"
>> and look for the one that matches the key.
>>>>>
>>>>>
>>>>>
>>>>> Also +1 to this. Cert chains may be optional, certainly, but should
>>>>> actually be separate from the actual cert in the configuration. The
>>>>> implementation may need to combine them into one document, but
>>>>> that's implementation specific.
>>>>>
>>>>>>
>>>>>>
>>>>>> Otherwise, awesome feature. I'll tell you, from an impl
>>>>>> perspective, parsing and validating the SSL certs is a pain. I can
>>>>>> probably find some java code to help out here on this as I've done
>>>>>> this before in the past.
>>>>>
>>>>>
>>>>>
>>>>> Yes, this is a sorely needed feature. I'm happy to see this be added
>>>>> to the Netscaler plugin, and await a time when HA proxy has a stable
>>>>> release that includes SSL term.
>>>>>
>>>>>>
>>>>>>
>>>>>> Darren
>>>>>>
>>>>>> On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed <sa...@cloudops.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have been working on adding SSL offload functionality to
>>>>>>> cloudstack and make it work for Netscaler. I have an initial
>>>>>>> design documented at
>>>>>>>
>>>>>>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offload
>>>>>>> ing+Support
>>>>>>>
>>>>>>> and I would really love your feedback. The bug for this is
>>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -Syed
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>

RE: [New Feature FS] SSL Offload Support for Cloudstack

[Edison Su <Ed...@citrix.com>]

There is command in ACS, UploadCustomCertificateCmd, which can receive ssl cert, key can chain as input. Maybe can share some code?

> -----Original Message-----
> From: Darren Shepherd [mailto:darren.s.shepherd@gmail.com]
> Sent: Tuesday, October 08, 2013 1:54 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [New Feature FS] SSL Offload Support for Cloudstack
> 
> The API should do input validation on the SSL cert, key and chain.
> Getting those three pieces of info is usually difficult for most people to get
> right as they don't really know what those three things are.  There's about a
> 80% chance most calls will fail.  If you rely on the provider it will probably just
> give back some general failure message that we won't be able to map back to
> the user as useful information.
> 
> I would implement the cert management as a separate CertificateService.
> 
> Darren
> 
> On Tue, Oct 8, 2013 at 1:31 PM, Syed Ahmed <sy...@gmail.com>
> wrote:
> > A question about implementation. I was looking at other commands and
> > the
> > execute() method for each of the other commands seem to call a service
> > ( _lbservice for example ) which takes care of updating the DB and
> > calling the resource layer. Should the Certificate management be
> > implemented as a service or is there something else that I can use? An
> > example would be immensely helpful.
> >
> > Thanks
> > -Syed
> >
> >
> >
> > On Tue 08 Oct 2013 03:22:14 PM EDT, Syed Ahmed wrote:
> >>
> >> Thanks for the feedback guys. Really appreciate it.
> >>
> >> 1) Changing the name to SSL Termination.
> >>
> >> I don't have a problem with that. I was looking at Netscaler all the
> >> time and they call it SSL offloading. But I agree that termination is
> >> a more general term.
> >> I have changed the name. The new page is at
> >>
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Terminatio
> >> n+Support
> >>
> >>
> >> 2) Specify the protocol type.
> >>
> >> Currently the protocol type of a loadbalncer gets set by checking the
> >> source and destination port ( see getNetScalerProtocol() in
> >> NetscalerResouce.java ) . So, we should change that and add another
> >> optional field in the createLoadBalancerRule for protocol.
> >>
> >> 3) Certificate chain as a seperate parameter.
> >>
> >> Again, I was looking at Netscaler as an example but separating the
> >> chain and certificate makes sense. I have updated the document
> >> accordingly.
> >>
> >> I was assuming that the certificate parsing/validation would be done
> >> by the device and we would just pass the certficate data as-is. But
> >> if we are adding chains separately, we should have the ability to
> >> parse and combine the chain and certificate for some devices as you
> mentioned.
> >>
> >> Thanks
> >> -Syed
> >>
> >>
> >> On Tue 08 Oct 2013 02:49:52 PM EDT, Chip Childers wrote:
> >>>
> >>>
> >>> On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote:
> >>>>
> >>>>
> >>>> Technicality here, can we call the functionality SSL termination?
> >>>> While technically we are "offloading" ssl from the VM, offloading
> >>>> typically carries a connotation that its being done in hardware. So
> >>>> we are really talking about SSL termination.
> >>>
> >>>
> >>>
> >>> +1 - completely agree. There's certainly the possibility of an
> >>> *implementation* being true offloading, but I'd generalize to
> >>> "termination" to account for a non-hardware offload of the crypto
> >>> processing.
> >>>
> >>>>
> >>>>
> >>>> Couple comments. I wouldn't want to assume anything about SSL
> based
> >>>> on port numbers. So instead specify the protocol
> >>>> (http/https/ssl/tcp) for the front and back side of the load
> >>>> balancer. Additionally, I'd prefer the chain not be in the cert.
> >>>> When configuring some backends you need the cert and chain
> >>>> separate. It would be easier if they were stored that way.
> >>>> Otherwise you have to do logic of parsing all the certs in the "keystore"
> and look for the one that matches the key.
> >>>
> >>>
> >>>
> >>> Also +1 to this. Cert chains may be optional, certainly, but should
> >>> actually be separate from the actual cert in the configuration. The
> >>> implementation may need to combine them into one document, but
> >>> that's implementation specific.
> >>>
> >>>>
> >>>>
> >>>> Otherwise, awesome feature. I'll tell you, from an impl
> >>>> perspective, parsing and validating the SSL certs is a pain. I can
> >>>> probably find some java code to help out here on this as I've done
> >>>> this before in the past.
> >>>
> >>>
> >>>
> >>> Yes, this is a sorely needed feature. I'm happy to see this be added
> >>> to the Netscaler plugin, and await a time when HA proxy has a stable
> >>> release that includes SSL term.
> >>>
> >>>>
> >>>>
> >>>> Darren
> >>>>
> >>>> On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed <sa...@cloudops.com>
> >>>> wrote:
> >>>>>
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I have been working on adding SSL offload functionality to
> >>>>> cloudstack and make it work for Netscaler. I have an initial
> >>>>> design documented at
> >>>>>
> >>>>>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offload
> >>>>> ing+Support
> >>>>>
> >>>>> and I would really love your feedback. The bug for this is
> >>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .
> >>>>>
> >>>>> Thanks,
> >>>>> -Syed
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> >

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Darren Shepherd <da...@gmail.com>]

BouncyCastle, its already in ACS.  Off list I'll send you some sample
code on how to validate this stuff.

Darren

On Tue, Oct 8, 2013 at 1:58 PM, Syed Ahmed <sa...@cloudops.com> wrote:
> Thanks Darren for your reply.
>
> Do you happen to have any info on a library that I can use for certificate
> validation?
>
> Thanks,
> -Syed
>
>
>
> On Tue 08 Oct 2013 04:53:40 PM EDT, Darren Shepherd wrote:
>>
>> The API should do input validation on the SSL cert, key and chain.
>> Getting those three pieces of info is usually difficult for most
>> people to get right as they don't really know what those three things
>> are.  There's about a 80% chance most calls will fail.  If you rely on
>> the provider it will probably just give back some general failure
>> message that we won't be able to map back to the user as useful
>> information.
>>
>> I would implement the cert management as a separate CertificateService.
>>
>> Darren
>>
>> On Tue, Oct 8, 2013 at 1:31 PM, Syed Ahmed <sy...@gmail.com>
>> wrote:
>>>
>>> A question about implementation. I was looking at other commands and the
>>> execute() method for each of the other commands seem to call a service (
>>> _lbservice for example ) which takes care of updating the DB and calling
>>> the
>>> resource layer. Should the Certificate management be implemented as a
>>> service or is there something else that I can use? An example would be
>>> immensely helpful.
>>>
>>> Thanks
>>> -Syed
>>>
>>>
>>>
>>> On Tue 08 Oct 2013 03:22:14 PM EDT, Syed Ahmed wrote:
>>>>
>>>>
>>>> Thanks for the feedback guys. Really appreciate it.
>>>>
>>>> 1) Changing the name to SSL Termination.
>>>>
>>>> I don't have a problem with that. I was looking at Netscaler all the
>>>> time
>>>> and they call it SSL offloading. But I agree that termination is a
>>>> more general term.
>>>> I have changed the name. The new page is at
>>>>
>>>>
>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Termination+Support
>>>>
>>>>
>>>> 2) Specify the protocol type.
>>>>
>>>> Currently the protocol type of a loadbalncer gets set by checking the
>>>> source and destination port ( see getNetScalerProtocol() in
>>>> NetscalerResouce.java ) . So, we should change that and add another
>>>> optional field in the createLoadBalancerRule for protocol.
>>>>
>>>> 3) Certificate chain as a seperate parameter.
>>>>
>>>> Again, I was looking at Netscaler as an example but separating the
>>>> chain and certificate makes sense. I have updated the document
>>>> accordingly.
>>>>
>>>> I was assuming that the certificate parsing/validation would be done
>>>> by the device and we would just pass the certficate data as-is. But if
>>>> we are adding chains separately, we should have the ability to parse
>>>> and combine the chain and certificate for some devices as you mentioned.
>>>>
>>>> Thanks
>>>> -Syed
>>>>
>>>>
>>>> On Tue 08 Oct 2013 02:49:52 PM EDT, Chip Childers wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Technicality here, can we call the functionality SSL termination?
>>>>>> While technically we are "offloading" ssl from the VM, offloading
>>>>>> typically carries a connotation that its being done in hardware. So
>>>>>> we are really talking about SSL termination.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> +1 - completely agree. There's certainly the possibility of an
>>>>> *implementation* being true offloading, but I'd generalize to
>>>>> "termination" to account for a non-hardware offload of the crypto
>>>>> processing.
>>>>>
>>>>>>
>>>>>>
>>>>>> Couple comments. I wouldn't want to assume anything about SSL based
>>>>>> on port numbers. So instead specify the protocol (http/https/ssl/tcp)
>>>>>> for the front and back side of the load balancer. Additionally, I'd
>>>>>> prefer the chain not be in the cert. When configuring some backends
>>>>>> you need the cert and chain separate. It would be easier if they were
>>>>>> stored that way. Otherwise you have to do logic of parsing all the
>>>>>> certs in the "keystore" and look for the one that matches the key.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Also +1 to this. Cert chains may be optional, certainly, but should
>>>>> actually be separate from the actual cert in the configuration. The
>>>>> implementation may need to combine them into one document, but that's
>>>>> implementation specific.
>>>>>
>>>>>>
>>>>>>
>>>>>> Otherwise, awesome feature. I'll tell you, from an impl perspective,
>>>>>> parsing and validating the SSL certs is a pain. I can probably find
>>>>>> some java code to help out here on this as I've done this before in
>>>>>> the past.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Yes, this is a sorely needed feature. I'm happy to see this be added to
>>>>> the Netscaler plugin, and await a time when HA proxy has a stable
>>>>> release that includes SSL term.
>>>>>
>>>>>>
>>>>>>
>>>>>> Darren
>>>>>>
>>>>>> On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed <sa...@cloudops.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have been working on adding SSL offload functionality to
>>>>>>> cloudstack and
>>>>>>> make it work for Netscaler. I have an initial design documented at
>>>>>>>
>>>>>>>
>>>>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support
>>>>>>>
>>>>>>> and I would really love your feedback. The bug for this is
>>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -Syed
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>
>

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Syed Ahmed <sa...@cloudops.com>]

Thanks Darren for your reply.

Do you happen to have any info on a library that I can use for 
certificate validation?

Thanks,
-Syed


On Tue 08 Oct 2013 04:53:40 PM EDT, Darren Shepherd wrote:
> The API should do input validation on the SSL cert, key and chain.
> Getting those three pieces of info is usually difficult for most
> people to get right as they don't really know what those three things
> are.  There's about a 80% chance most calls will fail.  If you rely on
> the provider it will probably just give back some general failure
> message that we won't be able to map back to the user as useful
> information.
>
> I would implement the cert management as a separate CertificateService.
>
> Darren
>
> On Tue, Oct 8, 2013 at 1:31 PM, Syed Ahmed <sy...@gmail.com> wrote:
>> A question about implementation. I was looking at other commands and the
>> execute() method for each of the other commands seem to call a service (
>> _lbservice for example ) which takes care of updating the DB and calling the
>> resource layer. Should the Certificate management be implemented as a
>> service or is there something else that I can use? An example would be
>> immensely helpful.
>>
>> Thanks
>> -Syed
>>
>>
>>
>> On Tue 08 Oct 2013 03:22:14 PM EDT, Syed Ahmed wrote:
>>>
>>> Thanks for the feedback guys. Really appreciate it.
>>>
>>> 1) Changing the name to SSL Termination.
>>>
>>> I don't have a problem with that. I was looking at Netscaler all the time
>>> and they call it SSL offloading. But I agree that termination is a
>>> more general term.
>>> I have changed the name. The new page is at
>>>
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Termination+Support
>>>
>>>
>>> 2) Specify the protocol type.
>>>
>>> Currently the protocol type of a loadbalncer gets set by checking the
>>> source and destination port ( see getNetScalerProtocol() in
>>> NetscalerResouce.java ) . So, we should change that and add another
>>> optional field in the createLoadBalancerRule for protocol.
>>>
>>> 3) Certificate chain as a seperate parameter.
>>>
>>> Again, I was looking at Netscaler as an example but separating the
>>> chain and certificate makes sense. I have updated the document
>>> accordingly.
>>>
>>> I was assuming that the certificate parsing/validation would be done
>>> by the device and we would just pass the certficate data as-is. But if
>>> we are adding chains separately, we should have the ability to parse
>>> and combine the chain and certificate for some devices as you mentioned.
>>>
>>> Thanks
>>> -Syed
>>>
>>>
>>> On Tue 08 Oct 2013 02:49:52 PM EDT, Chip Childers wrote:
>>>>
>>>>
>>>> On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote:
>>>>>
>>>>>
>>>>> Technicality here, can we call the functionality SSL termination?
>>>>> While technically we are "offloading" ssl from the VM, offloading
>>>>> typically carries a connotation that its being done in hardware. So
>>>>> we are really talking about SSL termination.
>>>>
>>>>
>>>>
>>>> +1 - completely agree. There's certainly the possibility of an
>>>> *implementation* being true offloading, but I'd generalize to
>>>> "termination" to account for a non-hardware offload of the crypto
>>>> processing.
>>>>
>>>>>
>>>>>
>>>>> Couple comments. I wouldn't want to assume anything about SSL based
>>>>> on port numbers. So instead specify the protocol (http/https/ssl/tcp)
>>>>> for the front and back side of the load balancer. Additionally, I'd
>>>>> prefer the chain not be in the cert. When configuring some backends
>>>>> you need the cert and chain separate. It would be easier if they were
>>>>> stored that way. Otherwise you have to do logic of parsing all the
>>>>> certs in the "keystore" and look for the one that matches the key.
>>>>
>>>>
>>>>
>>>> Also +1 to this. Cert chains may be optional, certainly, but should
>>>> actually be separate from the actual cert in the configuration. The
>>>> implementation may need to combine them into one document, but that's
>>>> implementation specific.
>>>>
>>>>>
>>>>>
>>>>> Otherwise, awesome feature. I'll tell you, from an impl perspective,
>>>>> parsing and validating the SSL certs is a pain. I can probably find
>>>>> some java code to help out here on this as I've done this before in
>>>>> the past.
>>>>
>>>>
>>>>
>>>> Yes, this is a sorely needed feature. I'm happy to see this be added to
>>>> the Netscaler plugin, and await a time when HA proxy has a stable
>>>> release that includes SSL term.
>>>>
>>>>>
>>>>>
>>>>> Darren
>>>>>
>>>>> On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed <sa...@cloudops.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have been working on adding SSL offload functionality to
>>>>>> cloudstack and
>>>>>> make it work for Netscaler. I have an initial design documented at
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support
>>>>>>
>>>>>> and I would really love your feedback. The bug for this is
>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .
>>>>>>
>>>>>> Thanks,
>>>>>> -Syed
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Darren Shepherd <da...@gmail.com>]

The API should do input validation on the SSL cert, key and chain.
Getting those three pieces of info is usually difficult for most
people to get right as they don't really know what those three things
are.  There's about a 80% chance most calls will fail.  If you rely on
the provider it will probably just give back some general failure
message that we won't be able to map back to the user as useful
information.

I would implement the cert management as a separate CertificateService.

Darren

On Tue, Oct 8, 2013 at 1:31 PM, Syed Ahmed <sy...@gmail.com> wrote:
> A question about implementation. I was looking at other commands and the
> execute() method for each of the other commands seem to call a service (
> _lbservice for example ) which takes care of updating the DB and calling the
> resource layer. Should the Certificate management be implemented as a
> service or is there something else that I can use? An example would be
> immensely helpful.
>
> Thanks
> -Syed
>
>
>
> On Tue 08 Oct 2013 03:22:14 PM EDT, Syed Ahmed wrote:
>>
>> Thanks for the feedback guys. Really appreciate it.
>>
>> 1) Changing the name to SSL Termination.
>>
>> I don't have a problem with that. I was looking at Netscaler all the time
>> and they call it SSL offloading. But I agree that termination is a
>> more general term.
>> I have changed the name. The new page is at
>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Termination+Support
>>
>>
>> 2) Specify the protocol type.
>>
>> Currently the protocol type of a loadbalncer gets set by checking the
>> source and destination port ( see getNetScalerProtocol() in
>> NetscalerResouce.java ) . So, we should change that and add another
>> optional field in the createLoadBalancerRule for protocol.
>>
>> 3) Certificate chain as a seperate parameter.
>>
>> Again, I was looking at Netscaler as an example but separating the
>> chain and certificate makes sense. I have updated the document
>> accordingly.
>>
>> I was assuming that the certificate parsing/validation would be done
>> by the device and we would just pass the certficate data as-is. But if
>> we are adding chains separately, we should have the ability to parse
>> and combine the chain and certificate for some devices as you mentioned.
>>
>> Thanks
>> -Syed
>>
>>
>> On Tue 08 Oct 2013 02:49:52 PM EDT, Chip Childers wrote:
>>>
>>>
>>> On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote:
>>>>
>>>>
>>>> Technicality here, can we call the functionality SSL termination?
>>>> While technically we are "offloading" ssl from the VM, offloading
>>>> typically carries a connotation that its being done in hardware. So
>>>> we are really talking about SSL termination.
>>>
>>>
>>>
>>> +1 - completely agree. There's certainly the possibility of an
>>> *implementation* being true offloading, but I'd generalize to
>>> "termination" to account for a non-hardware offload of the crypto
>>> processing.
>>>
>>>>
>>>>
>>>> Couple comments. I wouldn't want to assume anything about SSL based
>>>> on port numbers. So instead specify the protocol (http/https/ssl/tcp)
>>>> for the front and back side of the load balancer. Additionally, I'd
>>>> prefer the chain not be in the cert. When configuring some backends
>>>> you need the cert and chain separate. It would be easier if they were
>>>> stored that way. Otherwise you have to do logic of parsing all the
>>>> certs in the "keystore" and look for the one that matches the key.
>>>
>>>
>>>
>>> Also +1 to this. Cert chains may be optional, certainly, but should
>>> actually be separate from the actual cert in the configuration. The
>>> implementation may need to combine them into one document, but that's
>>> implementation specific.
>>>
>>>>
>>>>
>>>> Otherwise, awesome feature. I'll tell you, from an impl perspective,
>>>> parsing and validating the SSL certs is a pain. I can probably find
>>>> some java code to help out here on this as I've done this before in
>>>> the past.
>>>
>>>
>>>
>>> Yes, this is a sorely needed feature. I'm happy to see this be added to
>>> the Netscaler plugin, and await a time when HA proxy has a stable
>>> release that includes SSL term.
>>>
>>>>
>>>>
>>>> Darren
>>>>
>>>> On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed <sa...@cloudops.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I have been working on adding SSL offload functionality to
>>>>> cloudstack and
>>>>> make it work for Netscaler. I have an initial design documented at
>>>>>
>>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support
>>>>>
>>>>> and I would really love your feedback. The bug for this is
>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .
>>>>>
>>>>> Thanks,
>>>>> -Syed
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Syed Ahmed <sy...@gmail.com>]

A question about implementation. I was looking at other commands and 
the execute() method for each of the other commands seem to call a 
service ( _lbservice for example ) which takes care of updating the DB 
and calling the resource layer. Should the Certificate management be 
implemented as a service or is there something else that I can use? An 
example would be immensely helpful.

Thanks
-Syed


On Tue 08 Oct 2013 03:22:14 PM EDT, Syed Ahmed wrote:
> Thanks for the feedback guys. Really appreciate it.
>
> 1) Changing the name to SSL Termination.
>
> I don't have a problem with that. I was looking at Netscaler all the time
> and they call it SSL offloading. But I agree that termination is a
> more general term.
> I have changed the name. The new page is at
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Termination+Support
>
>
> 2) Specify the protocol type.
>
> Currently the protocol type of a loadbalncer gets set by checking the
> source and destination port ( see getNetScalerProtocol() in
> NetscalerResouce.java ) . So, we should change that and add another
> optional field in the createLoadBalancerRule for protocol.
>
> 3) Certificate chain as a seperate parameter.
>
> Again, I was looking at Netscaler as an example but separating the
> chain and certificate makes sense. I have updated the document
> accordingly.
>
> I was assuming that the certificate parsing/validation would be done
> by the device and we would just pass the certficate data as-is. But if
> we are adding chains separately, we should have the ability to parse
> and combine the chain and certificate for some devices as you mentioned.
>
> Thanks
> -Syed
>
>
> On Tue 08 Oct 2013 02:49:52 PM EDT, Chip Childers wrote:
>>
>> On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote:
>>>
>>> Technicality here, can we call the functionality SSL termination?
>>> While technically we are "offloading" ssl from the VM, offloading
>>> typically carries a connotation that its being done in hardware. So
>>> we are really talking about SSL termination.
>>
>>
>> +1 - completely agree. There's certainly the possibility of an
>> *implementation* being true offloading, but I'd generalize to
>> "termination" to account for a non-hardware offload of the crypto
>> processing.
>>
>>>
>>>
>>> Couple comments. I wouldn't want to assume anything about SSL based
>>> on port numbers. So instead specify the protocol (http/https/ssl/tcp)
>>> for the front and back side of the load balancer. Additionally, I'd
>>> prefer the chain not be in the cert. When configuring some backends
>>> you need the cert and chain separate. It would be easier if they were
>>> stored that way. Otherwise you have to do logic of parsing all the
>>> certs in the "keystore" and look for the one that matches the key.
>>
>>
>> Also +1 to this. Cert chains may be optional, certainly, but should
>> actually be separate from the actual cert in the configuration. The
>> implementation may need to combine them into one document, but that's
>> implementation specific.
>>
>>>
>>>
>>> Otherwise, awesome feature. I'll tell you, from an impl perspective,
>>> parsing and validating the SSL certs is a pain. I can probably find
>>> some java code to help out here on this as I've done this before in
>>> the past.
>>
>>
>> Yes, this is a sorely needed feature. I'm happy to see this be added to
>> the Netscaler plugin, and await a time when HA proxy has a stable
>> release that includes SSL term.
>>
>>>
>>>
>>> Darren
>>>
>>> On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed <sa...@cloudops.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have been working on adding SSL offload functionality to
>>>> cloudstack and
>>>> make it work for Netscaler. I have an initial design documented at
>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support
>>>>
>>>> and I would really love your feedback. The bug for this is
>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .
>>>>
>>>> Thanks,
>>>> -Syed
>>>>
>>>>
>>>
>>>
>>
>
>

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Syed Ahmed <sa...@cloudops.com>]

Thanks for the feedback guys. Really appreciate it.

1) Changing the name to SSL Termination.

I don't have a problem with that. I was looking at Netscaler all the time
and they call it SSL offloading. But I agree that termination is a more 
general term.
I have changed the name. The new page is at 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Termination+Support

2) Specify the protocol type.

Currently the protocol type of a loadbalncer gets set by checking the 
source and destination port ( see getNetScalerProtocol() in 
NetscalerResouce.java ) . So, we should change that and add another 
optional field in the createLoadBalancerRule for protocol.

3) Certificate chain as a seperate parameter.

Again, I was looking at Netscaler as an example but separating the chain 
and certificate makes sense. I have updated the document accordingly.

I was assuming that the certificate parsing/validation would be done by 
the device and we would just pass the certficate data as-is. But if we 
are adding chains separately, we should have the ability to parse and 
combine the chain and certificate for some devices as you mentioned.

Thanks
-Syed


On Tue 08 Oct 2013 02:49:52 PM EDT, Chip Childers wrote:
>
> On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote:
>>
>> Technicality here, can we call the functionality SSL termination?
>> While technically we are "offloading" ssl from the VM, offloading
>> typically carries a connotation that its being done in hardware. So
>> we are really talking about SSL termination.
>
>
> +1 - completely agree. There's certainly the possibility of an
> *implementation* being true offloading, but I'd generalize to
> "termination" to account for a non-hardware offload of the crypto
> processing.
>
>>
>>
>> Couple comments. I wouldn't want to assume anything about SSL based
>> on port numbers. So instead specify the protocol (http/https/ssl/tcp)
>> for the front and back side of the load balancer. Additionally, I'd
>> prefer the chain not be in the cert. When configuring some backends
>> you need the cert and chain separate. It would be easier if they were
>> stored that way. Otherwise you have to do logic of parsing all the
>> certs in the "keystore" and look for the one that matches the key.
>
>
> Also +1 to this. Cert chains may be optional, certainly, but should
> actually be separate from the actual cert in the configuration. The
> implementation may need to combine them into one document, but that's
> implementation specific.
>
>>
>>
>> Otherwise, awesome feature. I'll tell you, from an impl perspective,
>> parsing and validating the SSL certs is a pain. I can probably find
>> some java code to help out here on this as I've done this before in
>> the past.
>
>
> Yes, this is a sorely needed feature. I'm happy to see this be added to
> the Netscaler plugin, and await a time when HA proxy has a stable
> release that includes SSL term.
>
>>
>>
>> Darren
>>
>> On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed <sa...@cloudops.com> wrote:
>>>
>>> Hi,
>>>
>>> I have been working on adding SSL offload functionality to 
>>> cloudstack and
>>> make it work for Netscaler. I have an initial design documented at
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support
>>> and I would really love your feedback. The bug for this is
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .
>>>
>>> Thanks,
>>> -Syed
>>>
>>>
>>
>>
>

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Chip Childers <ch...@sungard.com>]

On Tue, Oct 08, 2013 at 11:41:42AM -0700, Darren Shepherd wrote:
> Technicality here, can we call the functionality SSL termination?
> While technically we are "offloading" ssl from the VM, offloading
> typically carries a connotation that its being done in hardware.  So
> we are really talking about SSL termination.

+1 - completely agree.  There's certainly the possibility of an
*implementation* being true offloading, but I'd generalize to
"termination" to account for a non-hardware offload of the crypto
processing.

> 
> Couple comments.  I wouldn't want to assume anything about SSL based
> on port numbers.  So instead specify the protocol (http/https/ssl/tcp)
> for the front and back side of the load balancer.  Additionally, I'd
> prefer the chain not be in the cert.  When configuring some backends
> you need the cert and chain separate.  It would be easier if they were
> stored that way.  Otherwise you have to do logic of parsing all the
> certs in the "keystore" and look for the one that matches the key.

Also +1 to this.  Cert chains may be optional, certainly, but should
actually be separate from the actual cert in the configuration.  The
implementation may need to combine them into one document, but that's
implementation specific.

> 
> Otherwise, awesome feature.  I'll tell you, from an impl perspective,
> parsing and validating the SSL certs is a pain.  I can probably find
> some java code to help out here on this as I've done this before in
> the past.

Yes, this is a sorely needed feature.  I'm happy to see this be added to
the Netscaler plugin, and await a time when HA proxy has a stable
release that includes SSL term.

> 
> Darren
> 
> On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed <sa...@cloudops.com> wrote:
> > Hi,
> >
> > I have been working on adding SSL offload functionality to cloudstack and
> > make it work for Netscaler. I have an initial design documented at
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support
> > and I would really love your feedback. The bug for this is
> > https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .
> >
> > Thanks,
> > -Syed
> >
> >
> 

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Darren Shepherd <da...@gmail.com>]

Technicality here, can we call the functionality SSL termination?
While technically we are "offloading" ssl from the VM, offloading
typically carries a connotation that its being done in hardware.  So
we are really talking about SSL termination.

Couple comments.  I wouldn't want to assume anything about SSL based
on port numbers.  So instead specify the protocol (http/https/ssl/tcp)
for the front and back side of the load balancer.  Additionally, I'd
prefer the chain not be in the cert.  When configuring some backends
you need the cert and chain separate.  It would be easier if they were
stored that way.  Otherwise you have to do logic of parsing all the
certs in the "keystore" and look for the one that matches the key.

Otherwise, awesome feature.  I'll tell you, from an impl perspective,
parsing and validating the SSL certs is a pain.  I can probably find
some java code to help out here on this as I've done this before in
the past.

Darren

On Tue, Oct 8, 2013 at 11:14 AM, Syed Ahmed <sa...@cloudops.com> wrote:
> Hi,
>
> I have been working on adding SSL offload functionality to cloudstack and
> make it work for Netscaler. I have an initial design documented at
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support
> and I would really love your feedback. The bug for this is
> https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .
>
> Thanks,
> -Syed
>
>

RE: [New Feature FS] SSL Offload Support for Cloudstack

[Animesh Chaturvedi <an...@citrix.com>]

Ok no problem I just resolve the ticket and tagged for 4.3

-----Original Message-----
From: Syed Ahmed [mailto:sahmed@cloudops.com] 
Sent: Wednesday, January 15, 2014 3:19 PM
To: dev@cloudstack.apache.org
Cc: Sheng Liang; Manan Shah; Ian Rae; Will Stevens; Pierre-Luc Bisaillon; Animesh Chaturvedi
Subject: Re: [New Feature FS] SSL Offload Support for Cloudstack

Yes the work is complete. This is available via the API. I will resolve the ticket.

Thanks,
-Syed

On Wed 15 Jan 2014 06:17:37 PM EST, Animesh Chaturvedi wrote:
> Syed
>
> I see the issue is not resolved and not tagged for 4.3. Is the work 
> all complete. If so can you resolve the ticket and tag for fixVersion 
> as 4.3
>
> Animesh
>
> -----Original Message-----
> From: Syed Ahmed [mailto:sahmed@cloudops.com]
> Sent: Tuesday, October 08, 2013 11:14 AM
> To: dev@cloudstack.apache.org
> Cc: Sheng Liang; Manan Shah; Ian Rae; Will Stevens; Pierre-Luc 
> Bisaillon
> Subject: [New Feature FS] SSL Offload Support for Cloudstack
>
> Hi,
>
> I have been working on adding SSL offload functionality to cloudstack 
> and make it work for Netscaler. I have an initial design documented at 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+
> Support and I would really love your feedback. The bug for this is
> https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .
>
> Thanks,
> -Syed
>
>

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Syed Ahmed <sa...@cloudops.com>]

Thanks

On Wed 15 Jan 2014 06:19:17 PM EST, Syed Ahmed wrote:
> Yes the work is complete. This is available via the API. I will
> resolve the ticket.
>
> Thanks,
> -Syed
>
> On Wed 15 Jan 2014 06:17:37 PM EST, Animesh Chaturvedi wrote:
>> Syed
>>
>> I see the issue is not resolved and not tagged for 4.3. Is the work
>> all complete. If so can you resolve the ticket and tag for fixVersion
>> as 4.3
>>
>> Animesh
>>
>> -----Original Message-----
>> From: Syed Ahmed [mailto:sahmed@cloudops.com]
>> Sent: Tuesday, October 08, 2013 11:14 AM
>> To: dev@cloudstack.apache.org
>> Cc: Sheng Liang; Manan Shah; Ian Rae; Will Stevens; Pierre-Luc Bisaillon
>> Subject: [New Feature FS] SSL Offload Support for Cloudstack
>>
>> Hi,
>>
>> I have been working on adding SSL offload functionality to cloudstack
>> and make it work for Netscaler. I have an initial design documented
>> at
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support
>>
>> and I would really love your feedback. The bug for this is
>> https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .
>>
>> Thanks,
>> -Syed
>>
>>
>
>

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Syed Ahmed <sa...@cloudops.com>]

Yes the work is complete. This is available via the API. I will resolve 
the ticket.

Thanks,
-Syed

On Wed 15 Jan 2014 06:17:37 PM EST, Animesh Chaturvedi wrote:
> Syed
>
> I see the issue is not resolved and not tagged for 4.3. Is the work all complete. If so can you resolve the ticket and tag for fixVersion as 4.3
>
> Animesh
>
> -----Original Message-----
> From: Syed Ahmed [mailto:sahmed@cloudops.com]
> Sent: Tuesday, October 08, 2013 11:14 AM
> To: dev@cloudstack.apache.org
> Cc: Sheng Liang; Manan Shah; Ian Rae; Will Stevens; Pierre-Luc Bisaillon
> Subject: [New Feature FS] SSL Offload Support for Cloudstack
>
> Hi,
>
> I have been working on adding SSL offload functionality to cloudstack and make it work for Netscaler. I have an initial design documented at https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support
> and I would really love your feedback. The bug for this is
> https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .
>
> Thanks,
> -Syed
>
>

RE: [New Feature FS] SSL Offload Support for Cloudstack

[Animesh Chaturvedi <an...@citrix.com>]

Syed

I see the issue is not resolved and not tagged for 4.3. Is the work all complete. If so can you resolve the ticket and tag for fixVersion as 4.3

Animesh

-----Original Message-----
From: Syed Ahmed [mailto:sahmed@cloudops.com] 
Sent: Tuesday, October 08, 2013 11:14 AM
To: dev@cloudstack.apache.org
Cc: Sheng Liang; Manan Shah; Ian Rae; Will Stevens; Pierre-Luc Bisaillon
Subject: [New Feature FS] SSL Offload Support for Cloudstack

Hi,

I have been working on adding SSL offload functionality to cloudstack and make it work for Netscaler. I have an initial design documented at https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Support
and I would really love your feedback. The bug for this is
https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .

Thanks,
-Syed

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Syed Ahmed <sa...@cloudops.com>]

Thanks Murali for your comments.

I have started implementing the API which consists of mostly 
certificate management, which is adding/deleting and listing SSL certs. 
I will implement the assign to loadbalancer and the resource specific 
code later.

Is it possible to submit my patch in two parts? The first part deals 
with certificate management and the second one deals with assignment of 
the certificate to loadbalancer. Both modules are independent and I 
feel like I would learn a lot as my first part is being reviewed and I 
can incorporate the  feedback from it onto my second part.

What do you guys think?

Thanks
-Syed


On Tue 15 Oct 2013 03:01:05 AM EDT, Murali Reddy wrote:

> On 11/10/13 9:31 PM, "Syed Ahmed" <sa...@cloudops.com> wrote:
>
>> Thanks for your valuable feedback Murali. Here are my comments.
>>
>>> IMO,
>>> its better we introduce new api's say
>>> registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer than
>>> force fit existing API's for associate/dis-associate certificates.
>>
>> Personally, I was going to do it this way. But I am not sure how good
>> of an idea it is to add a new api just for this feature as I can see
>> assignToLoadbalancer is semantically similar. But if everyone agrees I
>> have no problem with it.
>
> CloudStack already has distinct API's for each of the LB sub-functionality
> (health check, stickiness etc) [1]. We are not adding any redundant API,
> so resulting API are much cleaner just managing SSL termination for a LB
> rule.
>
>>
>>> On second thought may be an CloudStack usage event on assigning
>>> certificate seems good enough to me.
>>
>> So what I got from your earlier post was that when adding a  network
>> offering the provider can choose to enable SSL Termination or not as it
>> is a value added service. I was thinking of adding "SSL termination"
>> under supportedservices for the  createNetworkOffering API call. And
>> when someone calls the API to assign a cert to LB we can check if this
>> network offering has SSL termination enabled. Does this make sense?
>
> So there is notion of network service and network service capability [2].
> I would attribute 'SSL termination' as capability of LB service.
> createNetworkOffering API take a capability list. It does make sense to
> check if the network offering has SSL termination enabled when API to
> assign a cert to LB is called. Also note that, 'Network Elements' declare
> their capabilities for the supported services. So it can verified that
> service provider for LB actually supports 'SSL termination' capability
> while creating network offering.
>
>
>>
>> Also when you say usage event, what does this imply? I am sorry I am
>> not familiar with that term. Can you please elaborate.
>
> Its an event generated and persisted in the DB for every resource
> consumption and release. These events are used for billing etc. Please
> check publishUsageEvent calls in the code.
>
> [1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html
> [2] api/src/com/cloud/network/Network.java
>

RE: [New Feature FS] SSL Offload Support for Cloudstack

[Animesh Chaturvedi <an...@citrix.com>]

Darren, Murali

Can you review the final patch and if acceptable merge into master. Syed the deadline is hard. I will cut the branch on 11/08 late night or early morning next day

Animesh

> -----Original Message-----
> From: Syed Ahmed [mailto:sahmed@cloudops.com]
> Sent: Wednesday, November 06, 2013 8:26 AM
> To: dev@cloudstack.apache.org
> Cc: Murali Reddy; Darren Shepherd
> Subject: Re: [New Feature FS] SSL Offload Support for Cloudstack
> 
> Hi All,
> 
> Many thanks to Darren and Murali for reviewing my code. I feel that the
> code is in a good condition to be merged into the master. I see that the
> code freeze is at the end of this week. Is it possible for my patch to
> be merged by then? Is it a hard deadline?
> 
> Thanks,
> -Syed
> 
> On Mon 04 Nov 2013 11:45:15 AM EST, Syed Ahmed wrote:
> > Hi All,
> >
> > I would like to get this code into 4.3. Is it possible for this to be
> > reviewed? Is there anything needed from my side? I would be glad to
> > provide more information.
> >
> > Thanks,
> > -Syed
> >
> > On Wed 30 Oct 2013 03:25:12 PM EDT, Syed Ahmed wrote:
> >> Hi All,
> >>
> >> I have the patch for adding SSL termination support at
> >> https://reviews.apache.org/r/14976/ . It would be great if this can
> >> be reviewed.
> >>
> >> Thanks,
> >> -Syed
> >>
> >> On 13-10-15 03:01 AM, Murali Reddy wrote:
> >>> On 11/10/13 9:31 PM, "Syed Ahmed" <sa...@cloudops.com> wrote:
> >>>
> >>>> Thanks for your valuable feedback Murali. Here are my comments.
> >>>>
> >>>>> IMO,
> >>>>> its better we introduce new api's say
> >>>>> registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalance
> >>>>> r
> >>>>> than
> >>>>> force fit existing API's for associate/dis-associate certificates.
> >>>> Personally, I was going to do it this way. But I am not sure how
> >>>> good of an idea it is to add a new api just for this feature as I
> >>>> can see assignToLoadbalancer is semantically similar. But if
> >>>> everyone agrees I have no problem with it.
> >>> CloudStack already has distinct API's for each of the LB
> >>> sub-functionality (health check, stickiness etc) [1]. We are not
> >>> adding any redundant API, so resulting API are much cleaner just
> >>> managing SSL termination for a LB rule.
> >>>
> >>>>> On second thought may be an CloudStack usage event on assigning
> >>>>> certificate seems good enough to me.
> >>>> So what I got from your earlier post was that when adding a
> >>>> network offering the provider can choose to enable SSL Termination
> >>>> or not as it is a value added service. I was thinking of adding
> >>>> "SSL termination"
> >>>> under supportedservices for the  createNetworkOffering API call.
> >>>> And when someone calls the API to assign a cert to LB we can check
> >>>> if this network offering has SSL termination enabled. Does this
> make sense?
> >>> So there is notion of network service and network service capability
> >>> [2].
> >>> I would attribute 'SSL termination' as capability of LB service.
> >>> createNetworkOffering API take a capability list. It does make sense
> >>> to check if the network offering has SSL termination enabled when
> >>> API to assign a cert to LB is called. Also note that, 'Network
> Elements'
> >>> declare
> >>> their capabilities for the supported services. So it can verified
> >>> that service provider for LB actually supports 'SSL termination'
> >>> capability while creating network offering.
> >>>
> >>>
> >>>> Also when you say usage event, what does this imply? I am sorry I
> >>>> am not familiar with that term. Can you please elaborate.
> >>> Its an event generated and persisted in the DB for every resource
> >>> consumption and release. These events are used for billing etc.
> >>> Please check publishUsageEvent calls in the code.
> >>>
> >>> [1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html
> >>> [2] api/src/com/cloud/network/Network.java
> >>>
> >>
> >
> >
> 

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Syed Ahmed <sy...@gmail.com>]

Yes, the certificates are managed separately from the Netscaler on 
cloudstack and get passed to the resource. Any other LB can implement 
the termination feature and use the certificates.



On Wed 06 Nov 2013 12:36:26 PM EST, Marcus Sorensen wrote:
> Just want to mention that if certificates are managed, this would be
> fairly simple to add to VPC routers as well. The haproxy loadbalancer
> config would just need to be passed the cert and a slightly different
> config. So hopefully it has been implemented in such a way that it's
> easy to reuse for VPC, the certs aren't tied to netscaler objects or
> something like that.
>
> On Wed, Nov 6, 2013 at 9:25 AM, Syed Ahmed <sa...@cloudops.com> wrote:
>> Hi All,
>>
>> Many thanks to Darren and Murali for reviewing my code. I feel that the code
>> is in a good condition to be merged into the master. I see that the code
>> freeze is at the end of this week. Is it possible for my patch to be merged
>> by then? Is it a hard deadline?
>>
>> Thanks,
>> -Syed
>>
>>
>> On Mon 04 Nov 2013 11:45:15 AM EST, Syed Ahmed wrote:
>>>
>>> Hi All,
>>>
>>> I would like to get this code into 4.3. Is it possible for this to be
>>> reviewed? Is there anything needed from my side? I would be glad to
>>> provide more information.
>>>
>>> Thanks,
>>> -Syed
>>>
>>> On Wed 30 Oct 2013 03:25:12 PM EDT, Syed Ahmed wrote:
>>>>
>>>> Hi All,
>>>>
>>>> I have the patch for adding SSL termination support at
>>>> https://reviews.apache.org/r/14976/ . It would be great if this can be
>>>> reviewed.
>>>>
>>>> Thanks,
>>>> -Syed
>>>>
>>>> On 13-10-15 03:01 AM, Murali Reddy wrote:
>>>>>
>>>>> On 11/10/13 9:31 PM, "Syed Ahmed" <sa...@cloudops.com> wrote:
>>>>>
>>>>>> Thanks for your valuable feedback Murali. Here are my comments.
>>>>>>
>>>>>>> IMO,
>>>>>>> its better we introduce new api's say
>>>>>>> registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer
>>>>>>> than
>>>>>>> force fit existing API's for associate/dis-associate certificates.
>>>>>>
>>>>>> Personally, I was going to do it this way. But I am not sure how good
>>>>>> of an idea it is to add a new api just for this feature as I can see
>>>>>> assignToLoadbalancer is semantically similar. But if everyone agrees I
>>>>>> have no problem with it.
>>>>>
>>>>> CloudStack already has distinct API's for each of the LB
>>>>> sub-functionality
>>>>> (health check, stickiness etc) [1]. We are not adding any redundant
>>>>> API,
>>>>> so resulting API are much cleaner just managing SSL termination for
>>>>> a LB
>>>>> rule.
>>>>>
>>>>>>> On second thought may be an CloudStack usage event on assigning
>>>>>>> certificate seems good enough to me.
>>>>>>
>>>>>> So what I got from your earlier post was that when adding a  network
>>>>>> offering the provider can choose to enable SSL Termination or not
>>>>>> as it
>>>>>> is a value added service. I was thinking of adding "SSL termination"
>>>>>> under supportedservices for the  createNetworkOffering API call. And
>>>>>> when someone calls the API to assign a cert to LB we can check if this
>>>>>> network offering has SSL termination enabled. Does this make sense?
>>>>>
>>>>> So there is notion of network service and network service capability
>>>>> [2].
>>>>> I would attribute 'SSL termination' as capability of LB service.
>>>>> createNetworkOffering API take a capability list. It does make sense to
>>>>> check if the network offering has SSL termination enabled when API to
>>>>> assign a cert to LB is called. Also note that, 'Network Elements'
>>>>> declare
>>>>> their capabilities for the supported services. So it can verified that
>>>>> service provider for LB actually supports 'SSL termination' capability
>>>>> while creating network offering.
>>>>>
>>>>>
>>>>>> Also when you say usage event, what does this imply? I am sorry I am
>>>>>> not familiar with that term. Can you please elaborate.
>>>>>
>>>>> Its an event generated and persisted in the DB for every resource
>>>>> consumption and release. These events are used for billing etc. Please
>>>>> check publishUsageEvent calls in the code.
>>>>>
>>>>> [1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html
>>>>> [2] api/src/com/cloud/network/Network.java
>>>>>
>>>>
>>>
>>>
>>
>>

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Marcus Sorensen <sh...@gmail.com>]

Just want to mention that if certificates are managed, this would be
fairly simple to add to VPC routers as well. The haproxy loadbalancer
config would just need to be passed the cert and a slightly different
config. So hopefully it has been implemented in such a way that it's
easy to reuse for VPC, the certs aren't tied to netscaler objects or
something like that.

On Wed, Nov 6, 2013 at 9:25 AM, Syed Ahmed <sa...@cloudops.com> wrote:
> Hi All,
>
> Many thanks to Darren and Murali for reviewing my code. I feel that the code
> is in a good condition to be merged into the master. I see that the code
> freeze is at the end of this week. Is it possible for my patch to be merged
> by then? Is it a hard deadline?
>
> Thanks,
> -Syed
>
>
> On Mon 04 Nov 2013 11:45:15 AM EST, Syed Ahmed wrote:
>>
>> Hi All,
>>
>> I would like to get this code into 4.3. Is it possible for this to be
>> reviewed? Is there anything needed from my side? I would be glad to
>> provide more information.
>>
>> Thanks,
>> -Syed
>>
>> On Wed 30 Oct 2013 03:25:12 PM EDT, Syed Ahmed wrote:
>>>
>>> Hi All,
>>>
>>> I have the patch for adding SSL termination support at
>>> https://reviews.apache.org/r/14976/ . It would be great if this can be
>>> reviewed.
>>>
>>> Thanks,
>>> -Syed
>>>
>>> On 13-10-15 03:01 AM, Murali Reddy wrote:
>>>>
>>>> On 11/10/13 9:31 PM, "Syed Ahmed" <sa...@cloudops.com> wrote:
>>>>
>>>>> Thanks for your valuable feedback Murali. Here are my comments.
>>>>>
>>>>>> IMO,
>>>>>> its better we introduce new api's say
>>>>>> registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer
>>>>>> than
>>>>>> force fit existing API's for associate/dis-associate certificates.
>>>>>
>>>>> Personally, I was going to do it this way. But I am not sure how good
>>>>> of an idea it is to add a new api just for this feature as I can see
>>>>> assignToLoadbalancer is semantically similar. But if everyone agrees I
>>>>> have no problem with it.
>>>>
>>>> CloudStack already has distinct API's for each of the LB
>>>> sub-functionality
>>>> (health check, stickiness etc) [1]. We are not adding any redundant
>>>> API,
>>>> so resulting API are much cleaner just managing SSL termination for
>>>> a LB
>>>> rule.
>>>>
>>>>>> On second thought may be an CloudStack usage event on assigning
>>>>>> certificate seems good enough to me.
>>>>>
>>>>> So what I got from your earlier post was that when adding a  network
>>>>> offering the provider can choose to enable SSL Termination or not
>>>>> as it
>>>>> is a value added service. I was thinking of adding "SSL termination"
>>>>> under supportedservices for the  createNetworkOffering API call. And
>>>>> when someone calls the API to assign a cert to LB we can check if this
>>>>> network offering has SSL termination enabled. Does this make sense?
>>>>
>>>> So there is notion of network service and network service capability
>>>> [2].
>>>> I would attribute 'SSL termination' as capability of LB service.
>>>> createNetworkOffering API take a capability list. It does make sense to
>>>> check if the network offering has SSL termination enabled when API to
>>>> assign a cert to LB is called. Also note that, 'Network Elements'
>>>> declare
>>>> their capabilities for the supported services. So it can verified that
>>>> service provider for LB actually supports 'SSL termination' capability
>>>> while creating network offering.
>>>>
>>>>
>>>>> Also when you say usage event, what does this imply? I am sorry I am
>>>>> not familiar with that term. Can you please elaborate.
>>>>
>>>> Its an event generated and persisted in the DB for every resource
>>>> consumption and release. These events are used for billing etc. Please
>>>> check publishUsageEvent calls in the code.
>>>>
>>>> [1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html
>>>> [2] api/src/com/cloud/network/Network.java
>>>>
>>>
>>
>>
>
>

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Syed Ahmed <sa...@cloudops.com>]

Hi All,

Many thanks to Darren and Murali for reviewing my code. I feel that the 
code is in a good condition to be merged into the master. I see that 
the code freeze is at the end of this week. Is it possible for my patch 
to be merged by then? Is it a hard deadline?

Thanks,
-Syed

On Mon 04 Nov 2013 11:45:15 AM EST, Syed Ahmed wrote:
> Hi All,
>
> I would like to get this code into 4.3. Is it possible for this to be
> reviewed? Is there anything needed from my side? I would be glad to
> provide more information.
>
> Thanks,
> -Syed
>
> On Wed 30 Oct 2013 03:25:12 PM EDT, Syed Ahmed wrote:
>> Hi All,
>>
>> I have the patch for adding SSL termination support at
>> https://reviews.apache.org/r/14976/ . It would be great if this can be
>> reviewed.
>>
>> Thanks,
>> -Syed
>>
>> On 13-10-15 03:01 AM, Murali Reddy wrote:
>>> On 11/10/13 9:31 PM, "Syed Ahmed" <sa...@cloudops.com> wrote:
>>>
>>>> Thanks for your valuable feedback Murali. Here are my comments.
>>>>
>>>>> IMO,
>>>>> its better we introduce new api's say
>>>>> registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer
>>>>> than
>>>>> force fit existing API's for associate/dis-associate certificates.
>>>> Personally, I was going to do it this way. But I am not sure how good
>>>> of an idea it is to add a new api just for this feature as I can see
>>>> assignToLoadbalancer is semantically similar. But if everyone agrees I
>>>> have no problem with it.
>>> CloudStack already has distinct API's for each of the LB
>>> sub-functionality
>>> (health check, stickiness etc) [1]. We are not adding any redundant
>>> API,
>>> so resulting API are much cleaner just managing SSL termination for
>>> a LB
>>> rule.
>>>
>>>>> On second thought may be an CloudStack usage event on assigning
>>>>> certificate seems good enough to me.
>>>> So what I got from your earlier post was that when adding a  network
>>>> offering the provider can choose to enable SSL Termination or not
>>>> as it
>>>> is a value added service. I was thinking of adding "SSL termination"
>>>> under supportedservices for the  createNetworkOffering API call. And
>>>> when someone calls the API to assign a cert to LB we can check if this
>>>> network offering has SSL termination enabled. Does this make sense?
>>> So there is notion of network service and network service capability
>>> [2].
>>> I would attribute 'SSL termination' as capability of LB service.
>>> createNetworkOffering API take a capability list. It does make sense to
>>> check if the network offering has SSL termination enabled when API to
>>> assign a cert to LB is called. Also note that, 'Network Elements'
>>> declare
>>> their capabilities for the supported services. So it can verified that
>>> service provider for LB actually supports 'SSL termination' capability
>>> while creating network offering.
>>>
>>>
>>>> Also when you say usage event, what does this imply? I am sorry I am
>>>> not familiar with that term. Can you please elaborate.
>>> Its an event generated and persisted in the DB for every resource
>>> consumption and release. These events are used for billing etc. Please
>>> check publishUsageEvent calls in the code.
>>>
>>> [1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html
>>> [2] api/src/com/cloud/network/Network.java
>>>
>>
>
>

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Syed Ahmed <sy...@gmail.com>]

Hi All,

I would like to get this code into 4.3. Is it possible for this to be 
reviewed? Is there anything needed from my side? I would be glad to 
provide more information.

Thanks,
-Syed

On Wed 30 Oct 2013 03:25:12 PM EDT, Syed Ahmed wrote:
> Hi All,
>
> I have the patch for adding SSL termination support at
> https://reviews.apache.org/r/14976/ . It would be great if this can be
> reviewed.
>
> Thanks,
> -Syed
>
> On 13-10-15 03:01 AM, Murali Reddy wrote:
>> On 11/10/13 9:31 PM, "Syed Ahmed" <sa...@cloudops.com> wrote:
>>
>>> Thanks for your valuable feedback Murali. Here are my comments.
>>>
>>>> IMO,
>>>> its better we introduce new api's say
>>>> registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer
>>>> than
>>>> force fit existing API's for associate/dis-associate certificates.
>>> Personally, I was going to do it this way. But I am not sure how good
>>> of an idea it is to add a new api just for this feature as I can see
>>> assignToLoadbalancer is semantically similar. But if everyone agrees I
>>> have no problem with it.
>> CloudStack already has distinct API's for each of the LB
>> sub-functionality
>> (health check, stickiness etc) [1]. We are not adding any redundant API,
>> so resulting API are much cleaner just managing SSL termination for a LB
>> rule.
>>
>>>> On second thought may be an CloudStack usage event on assigning
>>>> certificate seems good enough to me.
>>> So what I got from your earlier post was that when adding a  network
>>> offering the provider can choose to enable SSL Termination or not as it
>>> is a value added service. I was thinking of adding "SSL termination"
>>> under supportedservices for the  createNetworkOffering API call. And
>>> when someone calls the API to assign a cert to LB we can check if this
>>> network offering has SSL termination enabled. Does this make sense?
>> So there is notion of network service and network service capability
>> [2].
>> I would attribute 'SSL termination' as capability of LB service.
>> createNetworkOffering API take a capability list. It does make sense to
>> check if the network offering has SSL termination enabled when API to
>> assign a cert to LB is called. Also note that, 'Network Elements'
>> declare
>> their capabilities for the supported services. So it can verified that
>> service provider for LB actually supports 'SSL termination' capability
>> while creating network offering.
>>
>>
>>> Also when you say usage event, what does this imply? I am sorry I am
>>> not familiar with that term. Can you please elaborate.
>> Its an event generated and persisted in the DB for every resource
>> consumption and release. These events are used for billing etc. Please
>> check publishUsageEvent calls in the code.
>>
>> [1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html
>> [2] api/src/com/cloud/network/Network.java
>>
>

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Syed Ahmed <sa...@cloudops.com>]

Hi All,

I have the patch for adding SSL termination support at 
https://reviews.apache.org/r/14976/ . It would be great if this can be 
reviewed.

Thanks,
-Syed

On 13-10-15 03:01 AM, Murali Reddy wrote:
> On 11/10/13 9:31 PM, "Syed Ahmed" <sa...@cloudops.com> wrote:
>
>> Thanks for your valuable feedback Murali. Here are my comments.
>>
>>> IMO,
>>> its better we introduce new api's say
>>> registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer than
>>> force fit existing API's for associate/dis-associate certificates.
>> Personally, I was going to do it this way. But I am not sure how good
>> of an idea it is to add a new api just for this feature as I can see
>> assignToLoadbalancer is semantically similar. But if everyone agrees I
>> have no problem with it.
> CloudStack already has distinct API's for each of the LB sub-functionality
> (health check, stickiness etc) [1]. We are not adding any redundant API,
> so resulting API are much cleaner just managing SSL termination for a LB
> rule.
>
>>> On second thought may be an CloudStack usage event on assigning
>>> certificate seems good enough to me.
>> So what I got from your earlier post was that when adding a  network
>> offering the provider can choose to enable SSL Termination or not as it
>> is a value added service. I was thinking of adding "SSL termination"
>> under supportedservices for the  createNetworkOffering API call. And
>> when someone calls the API to assign a cert to LB we can check if this
>> network offering has SSL termination enabled. Does this make sense?
> So there is notion of network service and network service capability [2].
> I would attribute 'SSL termination' as capability of LB service.
> createNetworkOffering API take a capability list. It does make sense to
> check if the network offering has SSL termination enabled when API to
> assign a cert to LB is called. Also note that, 'Network Elements' declare
> their capabilities for the supported services. So it can verified that
> service provider for LB actually supports 'SSL termination' capability
> while creating network offering.
>
>
>> Also when you say usage event, what does this imply? I am sorry I am
>> not familiar with that term. Can you please elaborate.
> Its an event generated and persisted in the DB for every resource
> consumption and release. These events are used for billing etc. Please
> check publishUsageEvent calls in the code.
>
> [1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html
> [2] api/src/com/cloud/network/Network.java
>

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Murali Reddy <Mu...@citrix.com>]

On 11/10/13 9:31 PM, "Syed Ahmed" <sa...@cloudops.com> wrote:

>Thanks for your valuable feedback Murali. Here are my comments.
>
>> IMO,
>> its better we introduce new api's say
>> registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer than
>> force fit existing API's for associate/dis-associate certificates.
>
>Personally, I was going to do it this way. But I am not sure how good
>of an idea it is to add a new api just for this feature as I can see
>assignToLoadbalancer is semantically similar. But if everyone agrees I
>have no problem with it.

CloudStack already has distinct API's for each of the LB sub-functionality
(health check, stickiness etc) [1]. We are not adding any redundant API,
so resulting API are much cleaner just managing SSL termination for a LB
rule. 

>
>> On second thought may be an CloudStack usage event on assigning
>> certificate seems good enough to me.
>
>So what I got from your earlier post was that when adding a  network
>offering the provider can choose to enable SSL Termination or not as it
>is a value added service. I was thinking of adding "SSL termination"
>under supportedservices for the  createNetworkOffering API call. And
>when someone calls the API to assign a cert to LB we can check if this
>network offering has SSL termination enabled. Does this make sense?

So there is notion of network service and network service capability [2].
I would attribute 'SSL termination' as capability of LB service.
createNetworkOffering API take a capability list. It does make sense to
check if the network offering has SSL termination enabled when API to
assign a cert to LB is called. Also note that, 'Network Elements' declare
their capabilities for the supported services. So it can verified that
service provider for LB actually supports 'SSL termination' capability
while creating network offering.


>
>Also when you say usage event, what does this imply? I am sorry I am
>not familiar with that term. Can you please elaborate.

Its an event generated and persisted in the DB for every resource
consumption and release. These events are used for billing etc. Please
check publishUsageEvent calls in the code.

[1] http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_User.html
[2] api/src/com/cloud/network/Network.java

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Syed Ahmed <sa...@cloudops.com>]

Thanks for your valuable feedback Murali. Here are my comments.

> IMO,
> its better we introduce new api's say
> registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer than
> force fit existing API's for associate/dis-associate certificates.

Personally, I was going to do it this way. But I am not sure how good 
of an idea it is to add a new api just for this feature as I can see 
assignToLoadbalancer is semantically similar. But if everyone agrees I 
have no problem with it.

> On second thought may be an CloudStack usage event on assigning
> certificate seems good enough to me.

So what I got from your earlier post was that when adding a  network 
offering the provider can choose to enable SSL Termination or not as it 
is a value added service. I was thinking of adding "SSL termination" 
under supportedservices for the  createNetworkOffering API call. And 
when someone calls the API to assign a cert to LB we can check if this 
network offering has SSL termination enabled. Does this make sense?

Also when you say usage event, what does this imply? I am sorry I am 
not familiar with that term. Can you please elaborate.

Thanks
-Syed

On Fri 11 Oct 2013 09:03:45 AM EDT, Murali Reddy wrote:
> On 09/10/13 8:08 PM, "Syed Ahmed" <sa...@cloudops.com> wrote:
>
>> Thanks Murali for your response.
>>
>>> - any reason why you choose assignTo/RemoveFrom load balancer rule API's
>>
>> I thought this made more sense than create/updateLoadbalancerRule as
>> we would have to call update to delete a cert which I find somewhat
>> confusing. Also this is semantically similar to attaching instances as
>> in you have a separate entity which is being bound to different LBs.
>
> We will be just overloading the assignTo/RemoveFrom load balancer rule
> API's for associate/dis-associte certificate with load balancer rule.
>
>>
>>> - to me SSL termination is value added service from providers
>>> perspective,
>>> So only if network offering permits, SSL termination can be used.
>>
>> Got it. This seems the logical way. Good point.
>
> On second thought may be an CloudStack usage event on assigning
> certificate seems good enough to me.
>
>>
>> Would it be a good Idea to add protocol to the createLoadBalancer API.
>> I think this makes sense in the long run as currently I cannot create
>> a HTTP loadbalncer for port 8080 from cloudstack.
>
> Yes, its good we introduce protocol in the API, and make it optional
> parameter. Currently CloudStack marks protocol as TCP by default and load
> balancer implementation layer corresponding to HAProxy, F5, NetScaler we
> are inferring protocol from the ports. So on upgrade just ensure we don't
> break backward compatibility of the existing load balancer rules.
>
>

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Murali Reddy <Mu...@citrix.com>]

On 09/10/13 8:08 PM, "Syed Ahmed" <sa...@cloudops.com> wrote:

>Thanks Murali for your response.
>
>> - any reason why you choose assignTo/RemoveFrom load balancer rule API's
>
>I thought this made more sense than create/updateLoadbalancerRule as
>we would have to call update to delete a cert which I find somewhat
>confusing. Also this is semantically similar to attaching instances as
>in you have a separate entity which is being bound to different LBs.

We will be just overloading the assignTo/RemoveFrom load balancer rule
API's for associate/dis-associte certificate with load balancer rule. IMO,
its better we introduce new api's say
registerCertifcateToLoadbalancer/deregisterCertifcateToLoadbalancer than
force fit existing API's for associate/dis-associate certificates.

>
>> - to me SSL termination is value added service from providers
>>perspective,
>> So only if network offering permits, SSL termination can be used.
>
>Got it. This seems the logical way. Good point.

On second thought may be an CloudStack usage event on assigning
certificate seems good enough to me.

>
>Would it be a good Idea to add protocol to the createLoadBalancer API.
>I think this makes sense in the long run as currently I cannot create
>a HTTP loadbalncer for port 8080 from cloudstack.

Yes, its good we introduce protocol in the API, and make it optional
parameter. Currently CloudStack marks protocol as TCP by default and load
balancer implementation layer corresponding to HAProxy, F5, NetScaler we
are inferring protocol from the ports. So on upgrade just ensure we don't
break backward compatibility of the existing load balancer rules.

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Syed Ahmed <sa...@cloudops.com>]

Thanks Murali for your response.

> - any reason why you choose assignTo/RemoveFrom load balancer rule API's

I thought this made more sense than create/updateLoadbalancerRule as
we would have to call update to delete a cert which I find somewhat
confusing. Also this is semantically similar to attaching instances as
in you have a separate entity which is being bound to different LBs.

> - to me SSL termination is value added service from providers perspective,
> So only if network offering permits, SSL termination can be used.

Got it. This seems the logical way. Good point.

> I see session persistence based on SSL session id's please see if
> this can supported.

I was looking at persistence based on SSL session id's [1]  and found
that this is supported for SSL bridge type of configuration where
netscaler just bridges the data without any encryption/decryption. I
am not sure about health checks and autoscale. I will look that up.


> - on the requirement #4, don't infer protocol based on the public/private
> ports and impose restrictions. Current createLoadBalancer API does not
> take protocol parameter so its inferred at device layer. NetScaler seems
> to support SSL with other TCP ports as well.


Would it be a good Idea to add protocol to the createLoadBalancer API.
I think this makes sense in the long run as currently I cannot create
a HTTP loadbalncer for port 8080 from cloudstack.

> One general implementation note, network rules can be reprogrammed. So
> operations to configure SSL cert, binding cert to virtual server etc need
> to be idempotent at NetScaler resource.

Thanks. I'll keep that in  mind when implementing the resource layer.

Thank a lot again for the replies. This is really helpful.

-- REFERENCES --

[1]  http://support.citrix.com/proddocs/topic/netscaler-load-balancing-93/ns-lb-persistence-configuring-ssl-session-id-tsk.html




-Syed

On Wed, Oct 9, 2013 at 5:57 AM, Murali Reddy <Mu...@citrix.com> wrote:
> Thanks Syed for the FS.
>
> Couple of comments:
>
> - any reason why you choose assignTo/RemoveFrom load balancer rule API's
> to assign/remove certificate to LB rules? These api's are basically for
> controlling VM membership with a load balancer rule. Can
> create/updateLoadBalancerRule api's b used for registering and
> de-registering certificate with load balancer rule?
>
> - to me SSL termination is value added service from providers perspective,
> its better we expose service differentiation in the network offering (e.g
> dedicated load balancer capability of LB service in the network offering).
> So only if network offering permits, SSL termination can be used.
>
> - does adding SSL termination support to load balancer affect/complement
> current session persistence, health monitoring, auto scale functionality
> anyway? I see session persistence based on SSL session id's please see if
> this can supported.
>
> - as commented by other, fail fast at service layer on invalid certificate.
>
> - on the requirement #4, don't infer protocol based on the public/private
> ports and impose restrictions. Current createLoadBalancer API does not
> take protocol parameter so its inferred at device layer. NetScaler seems
> to support SSL with other TCP ports as well.
>
> One general implementation note, network rules can be reprogrammed. So
> operations to configure SSL cert, binding cert to virtual server etc need
> to be idempotent at NetScaler resource.
>
> [1]
> http://support.citrix.com/proddocs/topic/netscaler-ssl-93/ns-ssl-offloading
> -other-tcp-protocols-tsk.html
>
> On 08/10/13 11:44 PM, "Syed Ahmed" <sa...@cloudops.com> wrote:
>
>>Hi,
>>
>>I have been working on adding SSL offload functionality to cloudstack
>>and make it work for Netscaler. I have an initial design documented at
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Supp
>>ort
>>and I would really love your feedback. The bug for this is
>>https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .
>>
>>Thanks,
>>-Syed
>>
>>
>>
>
>

Re: [New Feature FS] SSL Offload Support for Cloudstack

[Murali Reddy <Mu...@citrix.com>]

Thanks Syed for the FS.

Couple of comments:

- any reason why you choose assignTo/RemoveFrom load balancer rule API's
to assign/remove certificate to LB rules? These api's are basically for
controlling VM membership with a load balancer rule. Can
create/updateLoadBalancerRule api's b used for registering and
de-registering certificate with load balancer rule?

- to me SSL termination is value added service from providers perspective,
its better we expose service differentiation in the network offering (e.g
dedicated load balancer capability of LB service in the network offering).
So only if network offering permits, SSL termination can be used.

- does adding SSL termination support to load balancer affect/complement
current session persistence, health monitoring, auto scale functionality
anyway? I see session persistence based on SSL session id's please see if
this can supported.

- as commented by other, fail fast at service layer on invalid certificate.

- on the requirement #4, don't infer protocol based on the public/private
ports and impose restrictions. Current createLoadBalancer API does not
take protocol parameter so its inferred at device layer. NetScaler seems
to support SSL with other TCP ports as well.

One general implementation note, network rules can be reprogrammed. So
operations to configure SSL cert, binding cert to virtual server etc need
to be idempotent at NetScaler resource.

[1] 
http://support.citrix.com/proddocs/topic/netscaler-ssl-93/ns-ssl-offloading
-other-tcp-protocols-tsk.html

On 08/10/13 11:44 PM, "Syed Ahmed" <sa...@cloudops.com> wrote:

>Hi,
>
>I have been working on adding SSL offload functionality to cloudstack
>and make it work for Netscaler. I have an initial design documented at
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/SSL+Offloading+Supp
>ort 
>and I would really love your feedback. The bug for this is
>https://issues.apache.org/jira/browse/CLOUDSTACK-4821 .
>
>Thanks,
>-Syed
>
>
>