>> The issue was that we were shipping the default configuration sans SSL enabled, but expecting that folks who cared about security would enable SSL?
Even if SSL is enabled for management server, some people are still allergic to see clear text in the URL that carries console access information in clear text. >> This token is different from the auth token that is generated from the login call right? Right, this token is different from auth token from Apache Tomcat or API keys in CloudStack API >> Unique to each console session (e.g. if I opened a session on the same VM twice, I'd get two tokens?) Yes, unique to each console session >> This is done by the expiration argument to the API call to setup the session? No, the expiration time is not set through API parameter, but generated directly within management server. We don't want this to be configurable. This is also not the same as you mentioned about "I know we talked about adding that expiration value as part of the 3.0.0 release". Kelven -----Original Message----- From: David Nalley [mailto:[email protected]] Sent: Friday, April 20, 2012 6:24 PM To: [email protected] Cc: Development discussions for CloudStack Subject: Re: Security aspects of CloudStack console access To make sure that I understand this..... On Fri, Apr 20, 2012 at 8:58 PM, Kelven Yang <[email protected]> wrote: > a) Passing access token. > We originally rely on management server secured web session to protect > the access info, the access info appears in clear text in browser url. A lot > of people have raised concerns of this. To address the concern, we now wrap > the access information into an DES encrypted access token, DES encryption key > is randomly generated at per CloudStack installation basis. The DES > encryption key will also be passed to console service VM via our SSL-enabled > agent/management server channel so that service VM would be able to continue > performing security validation after management server has gone out of the > picture. The issue was that we were shipping the default configuration sans SSL enabled, but expecting that folks who cared about security would enable SSL? This token is different from the auth token that is generated from the login call right? Unique to each console session (e.g. if I opened a session on the same VM twice, I'd get two tokens?) > > Access token is also time-stamped by management server. Session > authentication should happen within the time period, otherwise, access will > be declined. If management service is running as a management server cluster, > all management server instances have to be time-synced. This is done by the expiration argument to the API call to setup the session? Speaking of, I know we talked about adding that expiration value as part of the 3.0.0 release, but I can't find any reference to it in the API docs, Release Notes, or the API developers guide.
