Getting a Cloud Director TLS “A” Grade – Part 1

The Let’s Encrypt certificate I use for the Cloud Director portal running in my lab environment expired lately, therefore a renewal was needed. While renewing the certificate and checking my TLS config, it was not up to par with modern standards and that needed for be fixed.

While writing down everything I researched, I found out there was more beneath the eye and eventually the post was too large a single one. Therefore I decided to split up this post in two parts.

The first part dives more into the interesting parts of the TLS protocol. The second part shows how you can configure the Cloud Director portal (any website in fact) and your NSX Load Balancer to enhance security, integrity and page speed.

In this multi-part series I hope you benefit from not only knowing the best setting, but more important, why some settings should be used in favor of others.

Part 2: Configure Cloud Director and Load Balancer can be found by clicking this link.

The issue

After renewing the certificate, I usually check the TLS configuration with the SSL Labs Server Test website. The advantage of using the SSL Server Test is that it provides an excellent insight to every aspect of your TLS configuration. Secondly there is a wealth of information and best practices on their site. Definitely take a look at it.

The result of the check was a “B” grade. That needed to be fixed of course 🙂

The low grade was due to a couple of reasons.

1. My VCD cell did not provide the entire certificate chain.
2. Some of the configured key exchange protocols are considered weak.
3. The negotiated key exchange protocol did not support PFS.

The information further on in this post is usable for every TLS secured website. After this primer about the basics of TLS, I will go into the VCD configuration and explain how to achieve an excellent grade.

TLS Primer

Before diving further into this matter some basic knowledge of key TLS concepts is useful. Especially which protocols, cipher suites and features are considered safe, but also to know a bit of the “why”.

SSL and TLS Protocols

SSL and TLS are a set of protocols for in-transit encyption to provide data integrity and privacy initially released in 1995 by Netscape.

History

Back in the days, SSL v2 was first version widely used. After several iterations of both protocols, only TLS versions v1.2 and v1.3 should be use these days. The rest is considered deprecated. See the Wikipedia TLS – History and development section for more information about the history.

Protocol	Secure	Reason
TLS v1.2 (2008)	Yes	Supports modern authenticated encryption (AEAD) ciphers. Supports Perfect Forward Secrecy (PFS) cipher suites.
TLS v1.3 (2018)	Yes	Improved performance (latency) Improved security (removed obsolete features and insecure ciphers)

Cipher suites

The TLS protocol uses a couple of techniques to securely encrypt the data and exchange keys. This is what the used Cipher suite takes care of.

Wikipedia says about it:

A Cipher suite is a set of algorithms that help secure a network connection that uses Transport Layer Security (TLS) or its now-deprecated predecessor Secure Socket Layer (SSL). The set of algorithms that cipher suites usually contain include: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC) algorithm.

Usually a Cipher suite has the following naming scheme. An example:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

• <TLS> is the used protocol
• <ECDHE_RSA> is key exchange algorithm
  • Used to determine if and how the client and server will authenticate during the handshake
• <AES_128_GCM> is the block / stream cipher used
  • Used to encrypt the message stream, together with the block cipher mode of operation
• <SHA256> is the message authentication algorithm
  • Used to authenticate a message (data integrity)

Key exchange algorithms

Choose a key exchange algorithm that supports Perfect Forward Secrecy (PFS) when possible. The PFS feature encrypts the conversation and is not dependent on the servers private key. ECDHE and DHE based suits should be chosen, in which the former should be preferred.

• ECDHE_ECDSA
• ECDHE_RSA
• DHE_RSA
• DHE_DSS

Do not use the RSA (TLS_RSA) and ECDH (TLS_ECDH) algorithms unless absolutely needed for compatibility since both do not support PFS.

Block and Stream Ciphers

Prefer authenticated encryption with associated data (AEAD) compatible block and stream ciphers. You should use and prefer AEAD ciphers because the recipient is able to check the integrity of both the encrypted and unencrypted part of the message.

AEAD compatible ciphers are:

• AES_128_GCM
• AES_256_GCM
• AES_128_CCM
• AES_256_CCM
• CHACHA20_POLY1305

All above ciphers provide strong authentication and key exchange, forward secrecy, and encryption of at least 128 bits. When the server supports it, you could also use the strong CHACHA20_POLY1305 stream cipher.

You may wonder why the widely used AES_128_CBC and AES_256_CBC are not preferred. That is because the CBC block ciphers are potentially vulnerable to “Lucky Thirteen” timing side-channel attack in the MAC check stage.

Only GCM / CCM block and POLY1305 stream ciphers are TLS 1.2 and 1.3 compatible. If possible prefer the GCM and CCM ciphers over CBC. Also, the CBC cipher is not TLS 1.3 compatible due to it’s potential vulnerability.

Message authentication algorithm (MAC)

The MAC part of the TLS protocol takes care of data integrity. If the preferred GCM / CCM cipher suites are used, a strong AEAD based integrated MAC is automatically used. Both are TLS 1.2 and 1.3 compatible.

The CBC cipher suite uses the potentially flawed hash based MAC (HMAC). If using it, prefer the more secure SHA256 and SHA384 hash functions. SHA1 can still be used for compatibility reasons, but is not recommended because of it’s weak hash.

DNS Certificate Authority Authorization (CAA)

For some years now the DNS Certificate Authority Authorization (CAA) is available. With CAA you can specify which certificate authority is authorized to issue certificates for your (sub)domain. CAA basically works the same as the Sender Policy Framework (SPF) protocol. SPF defines which SMTP servers are authorized to send email for a domain.

Where SPF uses standard DNS TXT records to store the config, CAA uses specific DNS CAA records. Not all DNS providers are compatible with this type of records. In my case the Microsoft 365 DNS servers did not support it, so I moved everything to Azure DNS instead which does support CAA records.

To show the CAA record for a domain use nslookup check the commands below. Beware that the Windows nslookup command does not support the CAA record type.

user@host:~$ nslookup
set type=caa
zuthof.nl
Server: 192.168.1.254
Address: 192.168.1.254#53
Non-authoritative answer:
zuthof.nl rdata_257 = 0 issue "letsencrypt.org"

The CAA record has support for (sub)domains certificates (use “issue” tag) and wildcardscertificates (use “issuewild” tag). The third tag type is “iodef”. With “iodef” you can configure an email address that should be notified when certificates are requested by unauthorized CA’s (no guaratee btw.) since the check is not mandatory.

HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) is a web security policy mechanism that helps to protect websites against man-in-the-middle attacks such as protocol downgrade attacks and cookie hijacking (Source: Wikipedia).

HTST is a configuration parameter on the webserver. Which basically tells the client (browser) that all web traffic requires HTTPS by putting “Strict-Transport-Security” in the response header. The additional “max-age” (defined in seconds) parameter tells the client the amount of time (often 1 year) that the client is required to communicate over HTTPS only to the webserver. Both parameters should be configured.

Reliable Certificate Authority (CA)

Choosing a reliable Certificate Authority (CA) is an import setup in securing the data being in-transit over the public internet. Do not use default VCD self-signed certificate for internet connected purposes.

When selecting a CA make sure it has support for both a Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP). Both are methods to revoke misconfigured or compromised certificates. Other tips for generating certificates are:

• Validity: Use certs up to 1 year and preferable shorter. Try to automate the renew process or at least have confidence in the renew process by documenting it at the very least.
• Key length: Generated certificates request with at least 2048 to 3072 bit RSA private keys, or better with 256 bit ECDSA.
• Secure private keys: At least password secure the private keys. If security is important to your organization, putting it in a Hardware Security Modules (HSM) box could be the best solution.

Certificate chains

Make sure to have a properly configured certificated chain for the certificate used by the webserver. Clients (often browsers) use this information to verify that the certificate is generated by a trusted intermediate CA up to the root CA.

If the chain is incomplete (i.e. missing intermediate CA’s) the client can invalidate the certificate and generate warnings.

The second part shows you how to bring that knowledge into practice and dive into the matter how VCD (VMware Cloud Director) and often also the Load Balancer can be configured to enhance security, integrity and page speed.