3 Replies Latest reply on Aug 24, 2016 10:09 AM by Texiwill

    TLS/SSL Guidance

    KellyAtWipro Lurker

      I've been handed a security audit on our hosts and it is rife with reference to TLS/SSL vulnerabilities. We run vSphere 6.0 but all of our hosts are at ESXi 5.5.0

       

      Here is what we have been flagged for in the audit: 

      TLS Server Supports TLS version 1.0
      TLS Server Supports TLS version 1.1
      TLS/SSL Server Does Not Support Any Strong Cipher Algorithms
      TLS/SSL Server is enabling the BEAST attack
      TLS/SSL Server Supports 3DES Cipher Suite
      TLS/SSL Server Supports The Use of Static Key Ciphers
      Untrusted TLS/SSL server X.509 certificate

       

      As far as I can tell, forcing use of TLS 1.2 remedies some of this, but after some major issues with SRM this past month we are *very* weary to make any changes that mean 3-4 16 hour days (any sysadmin has been there and learned the hard way).

       

      I've placed a call in with support but the answer was cryptic. Can anyone who knows anything about this please chime in? We are desperate to get compliant with the audit.

        • 1. Re: TLS/SSL Guidance
          MKguy Virtuoso

          The state of SSL/TLS on vSphere is quite a mess, I guess your audit only tested port 443, but there are a lot of other ports in a vSphere ecosystem that run SSL/TLS. As a primer before what I I'm going to explain check this earlier post:

          Re: Does esxi 5.5 U3 and vCenter 5.5 supports TLS 1.2?

           

          I have my doubts about the nature of your audit, they are suggesting changes that will not only likely impact your environment, but many of them are completely out of place, outdated or even counter-from a security standpoint:

          TLS Server Supports TLS version 1.0

          TLS Server Supports TLS version 1.1

          Yes, TLS 1.2 (and soon 1.3) is the best choice, but forcing 1.2 is just asking for trouble and I haven't heard of any serious security claim that 1.0 or 1.1 are insecure, unlike SSL 3.0.

           

          Guessworking from this KB it seems like you might be able to disable TLS 1.0 and 1.1 on ESXi port 443 with:

          esxcli system settings advanced set -o /UserVars/ESXiHostdDisabledProtocols -s "SSLv3 -TLSv1 -TLSv1.1"

          https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2139396#hostd5.0

          Even if it works it will most likely be not supported.

           

          TLS/SSL Server Does Not Support Any Strong Cipher Algorithms

          TLS/SSL Server Supports 3DES Cipher Suite

          TLS/SSL Server Supports The Use of Static Key Ciphers

          I would need a detailed definition of what your audit considers "Strong", but as a matter of fact ESXi 5.5 U3 on port 443 supports TLS_RSA_WITH_AES_256_CBC_SHA.

          AES256 is far from insecure, but this suite lacks forward secrecy which might be the reason its not considered strong. The lack of a forward secrecy cipher suite is also causing the "Static Key Ciphers" warning.

          3DES is considered deprecated but there are no known (practical) attacks yet. I'm not sure where this is coming from because ESXi 5.5 U3 and vCenter 5.5 U3 do not support 3DES, at least on port 443.

          I'm not aware of any supported or unsupported method to change the cipher suite selection on ESXi.

           

          TLS/SSL Server is enabling the BEAST attack

          BEAST is an outdated thing no security guy who takes himself seriously cares about anymore. On TLS 1.0 the only way to defend against BEAST is to force RC4 only - which is commonly considered more insecure than BEAST, which is a really impractical attack and mitigated client-side since years. Essentially you would need to disable TLS 1.0 and and force GCM-only cipher suite available since TLS 1.2 to defend against BEAST.

           

          Untrusted TLS/SSL server X.509 certificate

          This is probably the only point you can amend on more or less clean, supported ways by implementing your own CA-signed certificates instead of relying on the VMware default ones. You could even be doing that already and it's just that the auditor did not have your own root CA certificate if you have your own CA.

           

          What your auditor missed though is that ESXi is still vulnerable against client-initiated TLS renegotiation DoS.

           

          I suggest you take a look at the VMware security hardening guides here, though they aren't really going into detail in terms of TLS/SSL:

          VMware Security Hardening Guides

          • 2. Re: TLS/SSL Guidance
            KellyAtWipro Lurker

            I will sift through the links; thank you very much for the information and addition posts, especially the hardening guide! I have to say, much more helpful than anything I've encountered by Googling or calling into VMware support itself.

            • 3. Re: TLS/SSL Guidance
              Texiwill Guru
              User ModeratorsvExpert

              Hello Kelly,

               

              Also see how you can mitigate everything by putting all the vSphere Mgmt bits behind a firewall using Jump Machines to access. If the TLS/SSL bits are not publically available you may be able to mitigate items quite easily within an audit. This is really the best practice for all management bits for vSphere. The hardening guide is GREAT and should be used properly but look at other means of mitigating the larger issues. No one should be able to hop from their desktop direct to the vCenter client IMHO.

               

              Best regards,
              Edward L. Haletky
              VMware Communities User Moderator, VMware vExpert 2009-2016

              Author of the books 'VMWare ESX and ESXi in the Enterprise: Planning Deployment Virtualization Servers', Copyright 2011 Pearson Education. 'VMware vSphere and Virtual Infrastructure Security: Securing the Virtual Environment', Copyright 2009 Pearson Education.

              Virtualization and Cloud Security Analyst: The Virtualization Practice, LLC -- vSphere Upgrade Saga -- Virtualization Security Round Table Podcast