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
