By Jim Sadlek
Backdrop
TLS 1.0 is nearly 20 year old and has been deprecated for some time by the Internet Engineering Task Force (IETF) RFC7568, and vRA 7.3 ships with TLS 1.0 enabled, by default.
Problem
Clients that are hardening their environments and that require all their Windows machines to be compliant with TLS 1.0 being disabled are running into trouble when deploying vRA 7.3 using their Windows virtual machine templates for the IaaS components.
In a simple install, this is one Windows machine hosting all the IaaS components. In an HA production build-out, this can quickly escalate to six or even eight or more Windows virtual machines: 2 Web machines, 2 Manager Services machines, 2 DEMs, 2 Proxy Agents, and so on. Troubleshooting an environment like this can be a nightmare.
The telltale signs that something is awry are 401 errors all over the place under the Infrastructure tab in vRA. More precisely, you will see SChannel errors in the Event Viewer on the Windows virtual machines when vRA attempts to communicate with it.
The Partial Solution
The steps for disabling TLS 1.0 for a vRA build-out have been available for some time and are well document by VMware here and here for the vRA appliances, and the Windows components, respectively.
Missing Link
However, in my most recent experience using Windows 2016 Servers for all the Windows components, that was not enough. Making a long story short, one has to enable strong encryption on the Windows virtual machines as well for this whole scenario to work. This is a simple Registry entry that needs added in two places, as depicted below.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
Brief History of Cryptography
Encrypting messages has been going on since people could write, and this is because nearly all ancient people were illiterate.
Fast forward to a civilized and somewhat educated society, and there is a well-known Roman method that is referred to as a Caesar Cipher. I first learned this back in college, where the alphabet was simply shifted N number of characters to encrypt, and back again the same number to decrypt.
It wasn’t until mathematics were applied in the late 19th century that cryptography became fairly difficult to “crack” and usually took the efforts of a government to accomplish. The Germans used a seemingly impossible-to-break encryption method using an electromechanical device appropriately named Enigma.
Modern encryption utilize algorithms with a key that is used to encrypt and decrypt. The longer the key length the more difficult it is to break via brute force methods, where a computer is used to try every possible combination of characters to recreate the original key. Weak encryption uses keys with fewer bits than longer keys used in strong encryption. (That was my problem above.) Also, having the same key on both ends is known as symmetrical encryption. Sending the key “down the line” before sending the encrypted message obviates the need for encryption, so an asymmetrical encryption method was devised using a public key and two private keys. The private keys are installed ahead of time, but the algorithm provides a deterministic way of decrypting the message using a combination of the public key and one of the private keys.
What is TLS, Anyway?
What is TLS, and why do we even need it?
TLS is a cryptographic protocol used for encrypting traffic between two computers through the use of digital certificates, affectionately known as “SSL Certs”, today.
Well, most people don’t realize that TLS is an evolution of SSL, Secure Sockets Layer, the cryptographic protocol used in conjunction with HTTPS, the communications protocol over a network -- like the Internet. In fact, most people use the term SSL as a broad umbrella to describe how HTTPS is implemented, when in fact, modern browsers and Web sites are using TLS, instead.
Brief History of SSL/TLS
The history of how we started using TLS starts with the golden age of the Internet when SSL was created by Netscape in the mid-nienties. SSL was prone to security flaws from the beginning. So much so, that SSL 1.0 was never even released to the public. Netscape released SSL 2.0 in early 1995, and SSL 3.0 in 1998.
Microsoft was such a powerhouse during this time that they forced the protocol name to be changed to TransportLayerSecurity (TLS), which created confusion that continues to this day, to differentiate it from the insecure SSL from Netscape.
So, as you can see, TLS 1.0 can be thought of as SSL 3.1.
TLS 1.0 has since been deprecated since 2015, and that’s why we are seeing this issue more and more, recently.
For an exhaustive timeline of these cryptographic protocols, see: https://www.feistyduck.com/ssl-tls-and-pki-history/
Attribution
I’d like to thank Chris McCann for combing through SocialCast to find this article with an unobtrusive comment that says something like “Also you could try enforcing strong encryption…”, and for Justin Dowe for posting his comment on David Evans’ post for this exact problem. David used a great word choice to describe this, which is enigmatic, to say the least.