Synopsis :
The remote service has a configuration that may make it vulnerable to
the CRIME attack.
Description :
The remote service has one of two configurations that are known to be
required for the CRIME attack:
- SSL / TLS compression is enabled.
- TLS advertises the SPDY protocol earlier than version 4.
Note that Nessus did not attempt to launch the CRIME attack against the
remote service.
Solution :
Disable compression and / or the SPDY service.
Plugin Output :
The following configuration indicates that the remote service
may be vulnerable to the CRIME attack :
- SSL / TLS compression is enabled.
How do I disable SSL / TLS compression on ESXi 4.1?
VMware's point of view on the subject is explained in following KB doc: http://kb.vmware.com/kb/2039356
Hi,
Can someone expand on the fix please? I get error that I am unauthorized or the KB article has been moved. I use the free version, but I need to close this exploit.
Thanks!
We you able to get this addressed?...I also have the same issue, but can't seem to find a way to address it from the host perspective.
I did not find any solution, only the already mentioned KB document.
I too got the same warning message after run our security scanner.
how do i disable SSL / TLS compression on ESXi 5.0? is there any solution to fix this issue?
Hello,
VMware's official stance is that SSL Hygiene is a client issue and you need to use the proper client. My suggestion is that you open a SR to have them look deeper as there are documented ways to disable SSL Compression for various web servers, openssl, etc. Which is the better place to do this.
Another item to consider is that your management constructs should be tightly controlled behind their own firewall and within their own trust zones. This includes vCenter, ESXi consoles, etc. Access to this highly sensitive area should be limited and controlled explicitly by use of jump machines that are heavily monitored, locked down, but allows the job to be done.
This is the best practice and one set of controls you can use.
Best regards,
Edward L. Haletky
Please find the VMware Kb article below which explains how to disable / enable web page access to ESX/ESXi : http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=101603... http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=100761...
Team, I read the article and yes, VMware official position is to keep the user browsers up to date and disable compression from there, but that does not sound like a good solution to me. So, has anybody tried disabling ssl compression from the server.xml file ? For example using the following sintax=
compression=off
Thanks
deadFX wrote:
Hi,
Can someone expand on the fix please? I get error that I am unauthorized or the KB article has been moved. I use the free version, but I need to close this exploit.
Thanks!
I'm unsure what issue you've had there - the link works fine for me. Maybe it was temporarily broken?
Regardless, calling this an "exploit" is stretching it. Your hosts should not be accessible via the public Internet. This means you should only be accessing them via trusted networks. This means the chance of intercept and therefore hijack is already mitigated.
If, for some reason, your hosts are accessible via the public Internet, the chance of exploiting this is still precisely 0 unless you logon from a public access point or something equally untrusted, and someone happens to be waiting to steal your credentials. Access your hosts over a VPN and again, the chance of compromise is 0.
Then you've got the Wikipedia, which largely refers to it as a client side issue:
http://en.wikipedia.org/wiki/CRIME_(security_exploit)
Trusting Nessus blindly is not a security solution.