Oh, OK, Will, no problem. I wasn't sure if it would make it into 4.2, so I figured I'd check in with you on that.
Thanks! On Tue, Jun 11, 2013 at 10:40 AM, Kelven Yang <kelven.y...@citrix.com>wrote: > Will, > > Security is one of the important aspects in any system(if not of topmost), > it is a good move to consolidate it. Thanks for your effort! > > Kelven > > On 6/11/13 9:27 AM, "Will Stevens" <wstev...@cloudops.com> wrote: > > >Kelven, I like the idea of having a global setting that can be overridden > >by the developers at the device level if they want to offer finer control. > > I think this gives us the best of both worlds. > > > >Mike, I am not sure I will be able to get it into 4.2 unless I release it > >as its own patch prior to my code for the Palo Alto integration getting > >in. > > If we iron out how we expect the functionality to behave, I can push to > >get it in earlier than the rest of my code. > > > >Will > > > > > >On Tue, Jun 11, 2013 at 12:22 PM, Mike Tutkowski < > >mike.tutkow...@solidfire.com> wrote: > > > >> I would be quite interesting in seeing where we go with this. Are we > >> talking about doing this in 4.2? > >> > >> I have a customer playing around with the storage plug-in I've been > >> developing and we are having a little trouble in their environment with > >> certificates. If we had just one way of handling them, it would be great > >> (could just hand over the documentation for how this kind of thing > >>works in > >> general in CloudStack). > >> > >> > >> On Mon, Jun 10, 2013 at 11:07 AM, Kelven Yang <kelven.y...@citrix.com > >> >wrote: > >> > >> > Will, > >> > > >> > Thanks for the effort in getting a common wrapper into utils package. > >> > > >> > As for the policy decision(whether or not to make a global flag or a > >> > per-device option), both have pros and cons, we can wait and see the > >> > feedbacks from others in the community. > >> > > >> > Considering the legacy installations and the fact that we allow > >> > self-signed certificates by default in existing releases, I personally > >> > think that having a global flag is a much economic way to get this > >> feature > >> > in without too much disruptions. Of course, to have fine-control of > >>it, > >> we > >> > can always allow per-device overridden policy as well. > >> > > >> > Kelven > >> > > >> > > >> > On 6/10/13 9:04 AM, "Will Stevens" <wstev...@cloudops.com> wrote: > >> > > >> > >When I went looking in CS for the HTTP clients that were already > >> > >available, > >> > >I found the one that Soheil is using as well as the new apache one. > >>I > >> am > >> > >using the new apache one because I was assuming it was going to be > >>the > >> > >preferred one going forward. > >> > > > >> > >I will clean up my wrapper and make it available in the cloud-utils > >> > >package. > >> > > > >> > >The only question now is if the 'allow unverified certs' should be a > >> > >global > >> > >setting or a per device setting. I tend to think that it should be > >>per > >> > >device because that isolates the functionality a little better. > >> However, > >> > >by creating a global setting it makes the concept more accessible to > >> other > >> > >developers and centralizes the setting for the user so they only > >>have to > >> > >specify the setting in one place and all devices which have been > >>written > >> > >to > >> > >conform to that setting will allow unverified certs. > >> > > > >> > >I think there are pros and cons to both approaches. I am fine to > >> > >implement > >> > >my code either way, so more feedback on this choice would be > >> appreciated. > >> > > > >> > >ws > >> > > > >> > > > >> > >On Thu, Jun 6, 2013 at 6:40 PM, Kelven Yang <kelven.y...@citrix.com> > >> > >wrote: > >> > > > >> > >> Will, > >> > >> > >> > >> We don't have a common HTTPS client yet, as far as I know, > >>different > >> > >> module developers probably are using slight different way to deal > >>with > >> > >> self-signed certificate, it is a good time to consolidate it now > >>if it > >> > >>is > >> > >> not too late. You may make the facility available in cloud-utils > >> package > >> > >> and encourage adoption from these modules. > >> > >> > >> > >> Some modules, i.e., download manager, API module to hypervisor > >>hosts > >> > >>have > >> > >> the similar situation. > >> > >> > >> > >> > >> > >> Kelven > >> > >> > >> > >> On 6/6/13 2:33 PM, "Soheil Eizadi" <seiz...@infoblox.com> wrote: > >> > >> > >> > >> >What is missing is a facility to import a certificate into the > >>store. > >> > >>If > >> > >> >it was available you could use it for self signed CERTS. Ideally > >>it > >> > >> >should be part of GUI to add devices. > >> > >> > > >> > >> >I am implementing a similar HTTP Client. You are using > >> > >>DefaultHttpClient > >> > >> >so it is based on the newer Apache libraries. The ones I found in > >> > >> >CloudStack were older Commons HttpClient which was EOL. > >> > >> > > >> > >> >In my case I planned to wrap the Client as you have for > >>development > >> and > >> > >> >for production have an API to import a certificate for SSL into > >>the > >> > >> >Certificate Store. > >> > >> > > >> > >> >I would call to AuthScope(host, 443) to limit access to only the > >> > >>specific > >> > >> >host and port. > >> > >> > > >> > >> >-Soheil > >> > >> >________________________________________ > >> > >> >From: williamstev...@gmail.com [williamstev...@gmail.com] on > >>behalf > >> of > >> > >> >Will Stevens [wstev...@cloudops.com] > >> > >> >Sent: Thursday, June 06, 2013 1:08 PM > >> > >> >To: dev@cloudstack.apache.org > >> > >> >Subject: Re: Handling Self Signed Certs > >> > >> > > >> > >> >Hey Kelven, > >> > >> >I am using the same https client libraries as elsewhere in > >>Cloudstack > >> > >> >(well > >> > >> >one of them because there is more than one version of http client > >> libs > >> > >> >currently available in CS). > >> > >> > > >> > >> >I am using this client: > >> > >> >import org.apache.http.impl.client.DefaultHttpClient; > >> > >> > > >> > >> >I initialize it like this: > >> > >> >_httpclient = new DefaultHttpClient(); > >> > >> > > >> > >> >Then if self signed certs are allowed, I currently have a utility > >> > >>library > >> > >> >in my plugin which allows me to do this: > >> > >> >// Allows you to connect via SSL using unverified certs > >> > >> >_httpclient = HttpClientWrapper.wrapClient(_httpclient); > >> > >> > > >> > >> >Is there a class that already exists in CloudStack which I can > >>use to > >> > >>wrap > >> > >> >my client to enable unverified certs, or will I need to add one? > >> > >>Should I > >> > >> >create a global setting such as 'Allow unverified SSL certs' which > >> > >>would > >> > >> >be > >> > >> >checked by the code to determine if the http client should be > >> wrapped? > >> > >> > > >> > >> >Thx, Will > >> > >> > > >> > >> > > >> > >> >On Thu, Jun 6, 2013 at 2:43 PM, Kelven Yang > >><kelven.y...@citrix.com> > >> > >> >wrote: > >> > >> > > >> > >> >> Will, > >> > >> >> > >> > >> >> We have several other integrated components that have the > >>similar > >> > >> >> situation, it makes sense to consolidate the HTTPS client we > >>used > >> > >>across > >> > >> >> CloudStack and have a global configuration to deal with > >>self-signed > >> > >> >> certificate for all in testing or POC. > >> > >> >> > >> > >> >> To help testing/POC process to be smooth, we may allow > >>self-signed > >> > >> >> certificate by default(which is the current behave), security > >> > >>sensitive > >> > >> >> customers should disallow self-signed certificates in their > >> > >>production > >> > >> >> environment. > >> > >> >> > >> > >> >> Kelven > >> > >> >> > >> > >> >> On 6/6/13 9:08 AM, "Will Stevens" <wstev...@cloudops.com> > wrote: > >> > >> >> > >> > >> >> >Hey All, > >> > >> >> >I am building integration between CS and an external Palo Alto > >> > >>Firewall > >> > >> >> >device. The API calls to the PA device are done over HTTPS. > >>In > >> > >>some > >> > >> >> >cases > >> > >> >> >(like testing or a POC), it makes sense to use a self signed > >>cert > >> > >>for > >> > >> >>this > >> > >> >> >connection. > >> > >> >> > > >> > >> >> >Currently I have a little http client wrapper which allows the > >>use > >> > >>of a > >> > >> >> >self signed cert. Obviously, I do not want to use the wrapper > >> when > >> > >>a > >> > >> >>real > >> > >> >> >cert is used. > >> > >> >> > > >> > >> >> >What I am thinking of doing is adding a checkbox on the 'Add > >>Palo > >> > >>Alto > >> > >> >> >Device' configuration overlay with an option for 'Using a self > >> > >>signed > >> > >> >> >cert'. If this checkbox is checked, then the http client > >>wrapper > >> is > >> > >> >>used > >> > >> >> >so the self signed cert will not throw errors, if it is not > >> checked, > >> > >> >>the > >> > >> >> >the http client wrapper will not be used and errors will be > >>thrown > >> > >>if > >> > >> >>the > >> > >> >> >cert is not valid. > >> > >> >> > > >> > >> >> >Is this a realistic approach to this problem? Is this problem > >> > >>handled > >> > >> >>in > >> > >> >> >other parts of the system in a different way? > >> > >> >> > > >> > >> >> >Thanks, > >> > >> >> > > >> > >> >> >Will > >> > >> >> > >> > >> >> > >> > >> > >> > >> > >> > > >> > > >> > >> > >> -- > >> *Mike Tutkowski* > >> *Senior CloudStack Developer, SolidFire Inc.* > >> e: mike.tutkow...@solidfire.com > >> o: 303.746.7302 > >> Advancing the way the world uses the > >> cloud<http://solidfire.com/solution/overview/?video=play> > >> * * > >> > > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
