Hi!
I've found some SSL/TLS weaknesses after doing a security review on a test implementation of vCloud Director. It's the finds on scans against the https front that concerns me:
- Only TLS 1.0/SSL 3.0 is supported and this in conjuncture with the support/priority of weak CBC block ciphers suites makes it vulnerable to "recent" attacks such as the BEAST attack: https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls
- The SSL/TLS implementation supports Client-Initiated Renegotiation. This is very bad since you easily can perform Denial of Service-attacks against it. I'm not even talking about distributed ones (DDoS). Since the SSL/TLS handshake is way more demanding for the server than the client, you can easily exhaust it by spamming handshake renegotiating requests from a single client. There are even script kiddie tools out there to make this very easy and convenient for people to try. See more at: http://www.ietf.org/mail-archive/web/tls/current/msg07553.html and https://community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-a...
Now, these are not particularly new weaknesses, so I find it odd that they are not mitigated here.
I've read the vCloud Director hardening guide and VMware recommends deploying a Web Application Firewall (WAF) in front of vCloud Director cells. While of course a good idea, it's not always feasible in small scale deployments.
I've done my share of BEAST mitigation and such in web deployments using Apache. However, vCloud Director seem to have an own bundled Java solution. No AJP proxying from Apache or such either.
So, has anyone figured out how to secure this? I've looked around in /opt/vmware/vcloud-director/etc but found nothing obvious to tweak so far.
