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> >> ** >>
