You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Kelven Yang <ke...@citrix.com> on 2012/04/21 02:58:19 UTC
Security aspects of CloudStack console access
>From time to time, we received a number of emails from security experts who want to raise concerns about accessing the guest console. We've listened and started to address these security concerns in upcoming releases. I'd like to throw a brief introduction in this area and would like to gather feedbacks from CloudStack development community.
1. Design principal of CloudStack console access service
a) Separate control path and data path
CloudStack Management server manages control traffic, console service VMs manage data (access) traffic. Which means that as soon as CloudStack management server has helped setup the access session, it will go out of the picture. A access session will be solely conducted within a console service VM from then on.
b) Console service VM is stateless
Console service VM works in stateless mode, this is to allow an easy scale-out solution. CloudStack management server will automatically launch necessary service VMs based on current system load. A stateless service VM leads to the design of having management server to help negotiate, authenticate and setup the access session.
2. How it works
To start a console access session, management server first generates an access token, assigns a service VM instance, and then redirects client browser (in a new window) to initiate the session to the target service VM with the access token.
When service VM receives the access request, it relays the authentication request to management server presenting the token passed from client browser. At this phase, if management service is running as a CloudStack management server cluster, the request may be relayed to a different management server instance other than where the original token was generated on.
If the request can be authenticated successfully, an access session will be open in the service VM. After this point, user will be able to access the guest VM via a AJAX viewer sent from the service VM to client browser.
3. Security aspects
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.
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.
b) Securely access to hypervisor VNC sessions
We recently added support to use XenServer secure access API to secure the traffic between console service VM and XenServer host. For KVM/VMware, a random generated hypervisor password will be included inside the access token, console service VM uses the information to setup the security within the VNC protocol framework.
I hope I have done a good explanation work, if you do have further security concerns, please feel free to drop your feedback on this to the list.
Kelven
Re: Security aspects of CloudStack console access
Posted by Alex Karasulu <ak...@apache.org>.
On Sat, Apr 21, 2012 at 9:40 PM, Kelven Yang <ke...@citrix.com> wrote:
> Token issuing process here does look similar with Kerberos ticket issuing
> process, however, the access token we issue in CloudStack management server
> not only contains authentication information alone, but also other
> information that is essential to contact to the hypervisor VNC server. For
> all the involved parties, management server, console service VMs and
> hypervisor hosts, not all of them can freely participate Kerberos session.
> Balance it with the goal of just securing access-info in URL and the
> complexity of Kerberos deployment brought into the picture, we haven't
> looked into it.
>
>
>
Understood. Thanks for the background Kelven.
> -----Original Message-----
> From: akarasulu@gmail.com [mailto:akarasulu@gmail.com] On Behalf Of Alex
> Karasulu
> Sent: Saturday, April 21, 2012 2:02 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: Security aspects of CloudStack console access
>
> On Sat, Apr 21, 2012 at 6:45 AM, Kelven Yang <ke...@citrix.com>
> wrote:
>
> > Access token is exactly another added layer, the first security layer is
> > provided through HTTPS web session. Second layer is the dynamic access
> > token, third-layer is the timely expiration of access token.
> >
> >
> The flow and use cases I'm seeing here seems ideal for a Kerberos solution.
> Were there any thoughts along these lines for some of these security
> issues?
>
>
> > -----Original Message-----
> > From: John Kinsella [mailto:jlk@stratosec.co]
> > Sent: Friday, April 20, 2012 6:48 PM
> > To: cloudstack-dev@incubator.apache.org
> > Cc: Development discussions for CloudStack
> > Subject: Re: Security aspects of CloudStack console access
> >
> > I understand you're limited by VNC's setup, but DES is considered a
> > "broken" crypto algorithm, and it'd be in our best interests to get
> > something stronger in place in the future...I'll probably offer customers
> > VNC over VPN.
> >
> > And regarding SSL, that too is more or less crippled. Security needs to
> > take a layered approach, so that if one layer is compromised (see:
> > malicious organizations being issued CA certs and therefore the ability
> to
> > create any SSL cert they want) other layers will still prevent malicious
> > use.
> >
> > John
> >
> > On Apr 20, 2012, at 5:58 PM, Kelven Yang wrote:
> >
> > > From time to time, we received a number of emails from security experts
> > who want to raise concerns about accessing the guest console. We've
> > listened and started to address these security concerns in upcoming
> > releases. I'd like to throw a brief introduction in this area and would
> > like to gather feedbacks from CloudStack development community.
> > >
> > > 1. Design principal of CloudStack console access service
> > >
> > > a) Separate control path and data path
> > > CloudStack Management server manages control traffic, console
> > service VMs manage data (access) traffic. Which means that as soon as
> > CloudStack management server has helped setup the access session, it will
> > go out of the picture. A access session will be solely conducted within a
> > console service VM from then on.
> > >
> > > b) Console service VM is stateless
> > > Console service VM works in stateless mode, this is to allow an
> > easy scale-out solution. CloudStack management server will automatically
> > launch necessary service VMs based on current system load. A stateless
> > service VM leads to the design of having management server to help
> > negotiate, authenticate and setup the access session.
> > >
> > > 2. How it works
> > > To start a console access session, management server first generates an
> > access token, assigns a service VM instance, and then redirects client
> > browser (in a new window) to initiate the session to the target service
> VM
> > with the access token.
> > >
> > > When service VM receives the access request, it relays the
> > authentication request to management server presenting the token passed
> > from client browser. At this phase, if management service is running as a
> > CloudStack management server cluster, the request may be relayed to a
> > different management server instance other than where the original token
> > was generated on.
> > >
> > > If the request can be authenticated successfully, an access session
> will
> > be open in the service VM. After this point, user will be able to access
> > the guest VM via a AJAX viewer sent from the service VM to client
> browser.
> > >
> > > 3. Security aspects
> > > 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.
> > >
> > > 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.
> > >
> > > b) Securely access to hypervisor VNC sessions
> > > We recently added support to use XenServer secure access API to
> > secure the traffic between console service VM and XenServer host. For
> > KVM/VMware, a random generated hypervisor password will be included
> inside
> > the access token, console service VM uses the information to setup the
> > security within the VNC protocol framework.
> > >
> > > I hope I have done a good explanation work, if you do have further
> > security concerns, please feel free to drop your feedback on this to the
> > list.
> > >
> > > Kelven
> > >
> >
> > Stratosec - Secure Infrastructure as a Service
> > o: 415.315.9385
> > @johnlkinsella
> >
> >
>
>
> --
> Best Regards,
> -- Alex
>
--
Best Regards,
-- Alex
RE: Security aspects of CloudStack console access
Posted by Kelven Yang <ke...@citrix.com>.
Token issuing process here does look similar with Kerberos ticket issuing process, however, the access token we issue in CloudStack management server not only contains authentication information alone, but also other information that is essential to contact to the hypervisor VNC server. For all the involved parties, management server, console service VMs and hypervisor hosts, not all of them can freely participate Kerberos session. Balance it with the goal of just securing access-info in URL and the complexity of Kerberos deployment brought into the picture, we haven't looked into it.
Kelven
-----Original Message-----
From: akarasulu@gmail.com [mailto:akarasulu@gmail.com] On Behalf Of Alex Karasulu
Sent: Saturday, April 21, 2012 2:02 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Security aspects of CloudStack console access
On Sat, Apr 21, 2012 at 6:45 AM, Kelven Yang <ke...@citrix.com> wrote:
> Access token is exactly another added layer, the first security layer is
> provided through HTTPS web session. Second layer is the dynamic access
> token, third-layer is the timely expiration of access token.
>
>
The flow and use cases I'm seeing here seems ideal for a Kerberos solution.
Were there any thoughts along these lines for some of these security issues?
> -----Original Message-----
> From: John Kinsella [mailto:jlk@stratosec.co]
> Sent: Friday, April 20, 2012 6:48 PM
> To: cloudstack-dev@incubator.apache.org
> Cc: Development discussions for CloudStack
> Subject: Re: Security aspects of CloudStack console access
>
> I understand you're limited by VNC's setup, but DES is considered a
> "broken" crypto algorithm, and it'd be in our best interests to get
> something stronger in place in the future...I'll probably offer customers
> VNC over VPN.
>
> And regarding SSL, that too is more or less crippled. Security needs to
> take a layered approach, so that if one layer is compromised (see:
> malicious organizations being issued CA certs and therefore the ability to
> create any SSL cert they want) other layers will still prevent malicious
> use.
>
> John
>
> On Apr 20, 2012, at 5:58 PM, Kelven Yang wrote:
>
> > From time to time, we received a number of emails from security experts
> who want to raise concerns about accessing the guest console. We've
> listened and started to address these security concerns in upcoming
> releases. I'd like to throw a brief introduction in this area and would
> like to gather feedbacks from CloudStack development community.
> >
> > 1. Design principal of CloudStack console access service
> >
> > a) Separate control path and data path
> > CloudStack Management server manages control traffic, console
> service VMs manage data (access) traffic. Which means that as soon as
> CloudStack management server has helped setup the access session, it will
> go out of the picture. A access session will be solely conducted within a
> console service VM from then on.
> >
> > b) Console service VM is stateless
> > Console service VM works in stateless mode, this is to allow an
> easy scale-out solution. CloudStack management server will automatically
> launch necessary service VMs based on current system load. A stateless
> service VM leads to the design of having management server to help
> negotiate, authenticate and setup the access session.
> >
> > 2. How it works
> > To start a console access session, management server first generates an
> access token, assigns a service VM instance, and then redirects client
> browser (in a new window) to initiate the session to the target service VM
> with the access token.
> >
> > When service VM receives the access request, it relays the
> authentication request to management server presenting the token passed
> from client browser. At this phase, if management service is running as a
> CloudStack management server cluster, the request may be relayed to a
> different management server instance other than where the original token
> was generated on.
> >
> > If the request can be authenticated successfully, an access session will
> be open in the service VM. After this point, user will be able to access
> the guest VM via a AJAX viewer sent from the service VM to client browser.
> >
> > 3. Security aspects
> > 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.
> >
> > 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.
> >
> > b) Securely access to hypervisor VNC sessions
> > We recently added support to use XenServer secure access API to
> secure the traffic between console service VM and XenServer host. For
> KVM/VMware, a random generated hypervisor password will be included inside
> the access token, console service VM uses the information to setup the
> security within the VNC protocol framework.
> >
> > I hope I have done a good explanation work, if you do have further
> security concerns, please feel free to drop your feedback on this to the
> list.
> >
> > Kelven
> >
>
> Stratosec - Secure Infrastructure as a Service
> o: 415.315.9385
> @johnlkinsella
>
>
--
Best Regards,
-- Alex
Re: Security aspects of CloudStack console access
Posted by Alex Karasulu <ak...@apache.org>.
On Sat, Apr 21, 2012 at 6:45 AM, Kelven Yang <ke...@citrix.com> wrote:
> Access token is exactly another added layer, the first security layer is
> provided through HTTPS web session. Second layer is the dynamic access
> token, third-layer is the timely expiration of access token.
>
>
The flow and use cases I'm seeing here seems ideal for a Kerberos solution.
Were there any thoughts along these lines for some of these security issues?
> -----Original Message-----
> From: John Kinsella [mailto:jlk@stratosec.co]
> Sent: Friday, April 20, 2012 6:48 PM
> To: cloudstack-dev@incubator.apache.org
> Cc: Development discussions for CloudStack
> Subject: Re: Security aspects of CloudStack console access
>
> I understand you're limited by VNC's setup, but DES is considered a
> "broken" crypto algorithm, and it'd be in our best interests to get
> something stronger in place in the future...I'll probably offer customers
> VNC over VPN.
>
> And regarding SSL, that too is more or less crippled. Security needs to
> take a layered approach, so that if one layer is compromised (see:
> malicious organizations being issued CA certs and therefore the ability to
> create any SSL cert they want) other layers will still prevent malicious
> use.
>
> John
>
> On Apr 20, 2012, at 5:58 PM, Kelven Yang wrote:
>
> > From time to time, we received a number of emails from security experts
> who want to raise concerns about accessing the guest console. We've
> listened and started to address these security concerns in upcoming
> releases. I'd like to throw a brief introduction in this area and would
> like to gather feedbacks from CloudStack development community.
> >
> > 1. Design principal of CloudStack console access service
> >
> > a) Separate control path and data path
> > CloudStack Management server manages control traffic, console
> service VMs manage data (access) traffic. Which means that as soon as
> CloudStack management server has helped setup the access session, it will
> go out of the picture. A access session will be solely conducted within a
> console service VM from then on.
> >
> > b) Console service VM is stateless
> > Console service VM works in stateless mode, this is to allow an
> easy scale-out solution. CloudStack management server will automatically
> launch necessary service VMs based on current system load. A stateless
> service VM leads to the design of having management server to help
> negotiate, authenticate and setup the access session.
> >
> > 2. How it works
> > To start a console access session, management server first generates an
> access token, assigns a service VM instance, and then redirects client
> browser (in a new window) to initiate the session to the target service VM
> with the access token.
> >
> > When service VM receives the access request, it relays the
> authentication request to management server presenting the token passed
> from client browser. At this phase, if management service is running as a
> CloudStack management server cluster, the request may be relayed to a
> different management server instance other than where the original token
> was generated on.
> >
> > If the request can be authenticated successfully, an access session will
> be open in the service VM. After this point, user will be able to access
> the guest VM via a AJAX viewer sent from the service VM to client browser.
> >
> > 3. Security aspects
> > 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.
> >
> > 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.
> >
> > b) Securely access to hypervisor VNC sessions
> > We recently added support to use XenServer secure access API to
> secure the traffic between console service VM and XenServer host. For
> KVM/VMware, a random generated hypervisor password will be included inside
> the access token, console service VM uses the information to setup the
> security within the VNC protocol framework.
> >
> > I hope I have done a good explanation work, if you do have further
> security concerns, please feel free to drop your feedback on this to the
> list.
> >
> > Kelven
> >
>
> Stratosec - Secure Infrastructure as a Service
> o: 415.315.9385
> @johnlkinsella
>
>
--
Best Regards,
-- Alex
RE: Security aspects of CloudStack console access
Posted by Kelven Yang <ke...@citrix.com>.
Access token is exactly another added layer, the first security layer is provided through HTTPS web session. Second layer is the dynamic access token, third-layer is the timely expiration of access token.
As we already have the first layer of security, using DES to protect the access token is mainly for performance consideration, AJAX + web pulling has already slowed down the responding time a lot, we don't want to go to the extreme on security to sacrifice performance too much.
Kelven
-----Original Message-----
From: John Kinsella [mailto:jlk@stratosec.co]
Sent: Friday, April 20, 2012 6:48 PM
To: cloudstack-dev@incubator.apache.org
Cc: Development discussions for CloudStack
Subject: Re: Security aspects of CloudStack console access
I understand you're limited by VNC's setup, but DES is considered a "broken" crypto algorithm, and it'd be in our best interests to get something stronger in place in the future...I'll probably offer customers VNC over VPN.
And regarding SSL, that too is more or less crippled. Security needs to take a layered approach, so that if one layer is compromised (see: malicious organizations being issued CA certs and therefore the ability to create any SSL cert they want) other layers will still prevent malicious use.
John
On Apr 20, 2012, at 5:58 PM, Kelven Yang wrote:
> From time to time, we received a number of emails from security experts who want to raise concerns about accessing the guest console. We've listened and started to address these security concerns in upcoming releases. I'd like to throw a brief introduction in this area and would like to gather feedbacks from CloudStack development community.
>
> 1. Design principal of CloudStack console access service
>
> a) Separate control path and data path
> CloudStack Management server manages control traffic, console service VMs manage data (access) traffic. Which means that as soon as CloudStack management server has helped setup the access session, it will go out of the picture. A access session will be solely conducted within a console service VM from then on.
>
> b) Console service VM is stateless
> Console service VM works in stateless mode, this is to allow an easy scale-out solution. CloudStack management server will automatically launch necessary service VMs based on current system load. A stateless service VM leads to the design of having management server to help negotiate, authenticate and setup the access session.
>
> 2. How it works
> To start a console access session, management server first generates an access token, assigns a service VM instance, and then redirects client browser (in a new window) to initiate the session to the target service VM with the access token.
>
> When service VM receives the access request, it relays the authentication request to management server presenting the token passed from client browser. At this phase, if management service is running as a CloudStack management server cluster, the request may be relayed to a different management server instance other than where the original token was generated on.
>
> If the request can be authenticated successfully, an access session will be open in the service VM. After this point, user will be able to access the guest VM via a AJAX viewer sent from the service VM to client browser.
>
> 3. Security aspects
> 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.
>
> 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.
>
> b) Securely access to hypervisor VNC sessions
> We recently added support to use XenServer secure access API to secure the traffic between console service VM and XenServer host. For KVM/VMware, a random generated hypervisor password will be included inside the access token, console service VM uses the information to setup the security within the VNC protocol framework.
>
> I hope I have done a good explanation work, if you do have further security concerns, please feel free to drop your feedback on this to the list.
>
> Kelven
>
Stratosec - Secure Infrastructure as a Service
o: 415.315.9385
@johnlkinsella
Re: Security aspects of CloudStack console access
Posted by John Kinsella <jl...@stratosec.co>.
I understand you're limited by VNC's setup, but DES is considered a "broken" crypto algorithm, and it'd be in our best interests to get something stronger in place in the future...I'll probably offer customers VNC over VPN.
And regarding SSL, that too is more or less crippled. Security needs to take a layered approach, so that if one layer is compromised (see: malicious organizations being issued CA certs and therefore the ability to create any SSL cert they want) other layers will still prevent malicious use.
John
On Apr 20, 2012, at 5:58 PM, Kelven Yang wrote:
> From time to time, we received a number of emails from security experts who want to raise concerns about accessing the guest console. We've listened and started to address these security concerns in upcoming releases. I'd like to throw a brief introduction in this area and would like to gather feedbacks from CloudStack development community.
>
> 1. Design principal of CloudStack console access service
>
> a) Separate control path and data path
> CloudStack Management server manages control traffic, console service VMs manage data (access) traffic. Which means that as soon as CloudStack management server has helped setup the access session, it will go out of the picture. A access session will be solely conducted within a console service VM from then on.
>
> b) Console service VM is stateless
> Console service VM works in stateless mode, this is to allow an easy scale-out solution. CloudStack management server will automatically launch necessary service VMs based on current system load. A stateless service VM leads to the design of having management server to help negotiate, authenticate and setup the access session.
>
> 2. How it works
> To start a console access session, management server first generates an access token, assigns a service VM instance, and then redirects client browser (in a new window) to initiate the session to the target service VM with the access token.
>
> When service VM receives the access request, it relays the authentication request to management server presenting the token passed from client browser. At this phase, if management service is running as a CloudStack management server cluster, the request may be relayed to a different management server instance other than where the original token was generated on.
>
> If the request can be authenticated successfully, an access session will be open in the service VM. After this point, user will be able to access the guest VM via a AJAX viewer sent from the service VM to client browser.
>
> 3. Security aspects
> 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.
>
> 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.
>
> b) Securely access to hypervisor VNC sessions
> We recently added support to use XenServer secure access API to secure the traffic between console service VM and XenServer host. For KVM/VMware, a random generated hypervisor password will be included inside the access token, console service VM uses the information to setup the security within the VNC protocol framework.
>
> I hope I have done a good explanation work, if you do have further security concerns, please feel free to drop your feedback on this to the list.
>
> Kelven
>
Stratosec - Secure Infrastructure as a Service
o: 415.315.9385
@johnlkinsella
RE: Security aspects of CloudStack console access
Posted by Will Chan <wi...@citrix.com>.
You should also add this to the wiki.
________________________________________
From: Kelven Yang [kelven.yang@citrix.com]
Sent: Friday, April 20, 2012 5:58 PM
To: cloudstack-dev@incubator.apache.org
Cc: Development discussions for CloudStack
Subject: Security aspects of CloudStack console access
>From time to time, we received a number of emails from security experts who want to raise concerns about accessing the guest console. We've listened and started to address these security concerns in upcoming releases. I'd like to throw a brief introduction in this area and would like to gather feedbacks from CloudStack development community.
1. Design principal of CloudStack console access service
a) Separate control path and data path
CloudStack Management server manages control traffic, console service VMs manage data (access) traffic. Which means that as soon as CloudStack management server has helped setup the access session, it will go out of the picture. A access session will be solely conducted within a console service VM from then on.
b) Console service VM is stateless
Console service VM works in stateless mode, this is to allow an easy scale-out solution. CloudStack management server will automatically launch necessary service VMs based on current system load. A stateless service VM leads to the design of having management server to help negotiate, authenticate and setup the access session.
2. How it works
To start a console access session, management server first generates an access token, assigns a service VM instance, and then redirects client browser (in a new window) to initiate the session to the target service VM with the access token.
When service VM receives the access request, it relays the authentication request to management server presenting the token passed from client browser. At this phase, if management service is running as a CloudStack management server cluster, the request may be relayed to a different management server instance other than where the original token was generated on.
If the request can be authenticated successfully, an access session will be open in the service VM. After this point, user will be able to access the guest VM via a AJAX viewer sent from the service VM to client browser.
3. Security aspects
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.
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.
b) Securely access to hypervisor VNC sessions
We recently added support to use XenServer secure access API to secure the traffic between console service VM and XenServer host. For KVM/VMware, a random generated hypervisor password will be included inside the access token, console service VM uses the information to setup the security within the VNC protocol framework.
I hope I have done a good explanation work, if you do have further security concerns, please feel free to drop your feedback on this to the list.
Kelven
RE: Security aspects of CloudStack console access
Posted by Kelven Yang <ke...@citrix.com>.
It is hard-coded to 2 minutes. We assume from the time that management has generated the token, browser should be able to start a session within this time period. It also means that if someone has already broken our first layer (HTTPS web session) of security, he/she has up to 2 minutes to break 64-bit keyed DES access token. Not sure if it is strong enough though, I'm looking forward to hearing from security experts in the community to comment on that.
Kelven
-----Original Message-----
From: David Nalley [mailto:david@gnsa.us]
Sent: Friday, April 20, 2012 6:48 PM
To: cloudstack-dev@incubator.apache.org
Cc: Development discussions for CloudStack
Subject: Re: Security aspects of CloudStack console access
On Fri, Apr 20, 2012 at 9:36 PM, Kelven Yang <ke...@citrix.com> wrote:
>>> 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.
>
So it's hardcoded? What length of time is it set to?
--David
Re: Security aspects of CloudStack console access
Posted by David Nalley <da...@gnsa.us>.
On Fri, Apr 20, 2012 at 9:36 PM, Kelven Yang <ke...@citrix.com> wrote:
>>> 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.
>
So it's hardcoded? What length of time is it set to?
--David
RE: Security aspects of CloudStack console access
Posted by Kelven Yang <ke...@citrix.com>.
>> 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:david@gnsa.us]
Sent: Friday, April 20, 2012 6:24 PM
To: cloudstack-dev@incubator.apache.org
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 <ke...@citrix.com> 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.
Re: Security aspects of CloudStack console access
Posted by David Nalley <da...@gnsa.us>.
To make sure that I understand this.....
On Fri, Apr 20, 2012 at 8:58 PM, Kelven Yang <ke...@citrix.com> 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.