Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of williamstevens@gmail.com
 designates 209.85.160.49 as permitted sender)
MIME-Version: 1.0
Sender: williamstevens@gmail.com
In-Reply-To: 
 <CACOnxCjsHUFMsSxkdqUcu4MMZB5FXd4nX-3vgwS63YD5S3Zbyw@mail.gmail.com>
References: 
 <CAC2panr0jYp=LZEiXUxArbO95zLv9s1PLjG6DZUkndfXTbN6rg@mail.gmail.com>
	<CDDB543C.48A4B%kelven.yang@citrix.com>
	<CACOnxCjsHUFMsSxkdqUcu4MMZB5FXd4nX-3vgwS63YD5S3Zbyw@mail.gmail.com>
Date: Tue, 11 Jun 2013 12:27:33 -0400
Message-ID: 
 <CAC2panrgMheL3s1STNzbSRt0dQsWcpw4-5VzNy8Qv6e+wDsL5g@mail.gmail.com>
Subject: Re: Handling Self Signed Certs
From: Will Stevens <wstevens@cloudops.com>
To: dev@cloudstack.apache.org
Content-Type: multipart/alternative; boundary=047d7b0721ced425a304dee35f9e

--047d7b0721ced425a304dee35f9e
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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.tutkowski@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.yang@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" <wstevens@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 pe=
r
> > >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 writt=
en
> > >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.yang@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 wi=
th
> > >> 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" <seizadi@infoblox.com> wrote:
> > >>
> > >> >What is missing is a facility to import a certificate into the stor=
e.
> > >>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: williamstevens@gmail.com [williamstevens@gmail.com] on behalf
> of
> > >> >Will Stevens [wstevens@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 Cloudsta=
ck
> > >> >(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 =3D 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 =3D 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.yang@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-sign=
ed
> > >> >> certificate for all in testing or POC.
> > >> >>
> > >> >> To help testing/POC process to be smooth, we may allow self-signe=
d
> > >> >> 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" <wstevens@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 cer=
t
> > >>for
> > >> >>this
> > >> >> >connection.
> > >> >> >
> > >> >> >Currently I have a little http client wrapper which allows the u=
se
> > >>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 Pal=
o
> > >>Alto
> > >> >> >Device' configuration overlay with an option for 'Using a self
> > >>signed
> > >> >> >cert'.  If this checkbox is checked, then the http client wrappe=
r
> 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 thro=
wn
> > >>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.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=3Dplay>
> *=99*
>

--047d7b0721ced425a304dee35f9e--