At present, the VMware Unified Access Gateway is at release version 3.8. For those that do not know, the UAG is the component that delivers your users secure access to on-premises resources in multiple scenario's. This can be a number of resources, granted through either VMware Horizon, Workspace ONE, or a combination of both. This can be a Horizon VDI desktop or hosted app, an internal website, file or sharepoint servers or even act as a Secure Email Gateway. If you want to know more, please visit this excellent post by Graeme Gordon on VMware's Techzone: https://techzone.vmware.com/blog/secure-remote-access-vmware-unified-access-gateway
To be able to build a secure connection to such a gateway, there are a couple of things needed to create this secure connection. One is a certificate, that proves to the world that the identity presented is actually the one that can be validated. This validation is done through a number of public Certificate Authorities. These CA's grant the certificate, after verifying that all information that the company supplied to them is correct. Validation is also performed by email verification, to make sure the company actually owns the Domain name presented in the certificate. As an example, my own VDI test environment, when accessed through a browser shows the certificate to be valid. This means that the certificate can be checked for validity all the way back to its originating Authority.
(Be aware of the fact that servers or appliances that you install a certificate on, need to be able to connect back to this originating CA, to be able to check the validity. If there is a firewall blocking this communication, the certificate will still show up to be invalid.)
Other parts of setting up the secure connection are the encryption protocols. You might have heard of terms such as SSL and TLS, these protocols are used to establish a trustworthy channel by which data can be transferred over a non-trustworthy network situation. The SSL (Secure Sockets Layer) protocol is quite old, with the first iteration V1.0 already established in 1994. This was never publicly used, but version 2.0 was. Version 3.0 is still available in some products we see today, but this entire protocol suite was deemed insecure and has been proven to be vulnerable enough to dismiss. Just google for POODLE vulnerability for more information.
Its succesor is called TLS, or Transport Layer Security, and has also been in development constantly. Version 1.0 has also been deemed vulnerable and is being disabled more and more. Versions 1.1 and 1.2 are the current standards, with 1.3 already established, but not implemented very much yet. The differences in all these versions (same goes for SSL) is the used cipher suites. The suites are basically a set of algorithms which are used to establish key exchange, bulk encryption and a message authentication code (MAC) algorithm. The names you will be able to see in cipher suite lists are usually quite long, but they can be understood. Taken from Wikipedia:
Each cipher suite has a unique name that is used to identify it and to describe the algorithmic contents of it. Each segment in a cipher suite name stands for a different algorithm or protocol. An example of a cipher suite name: TLS_RSA_WITH_3DES_EDE_CBC_SHA
The meaning of this name is:
TLS defines the protocol that this cipher suite is for; it will usually be TLS.
RSA indicates the key exchange algorithm being used. The key exchange algorithm is used to determine if and how the client and server will authenticate during the handshake.
3DES_EDE_CBC indicates the block cipher being used to encrypt the message stream, together with the block cipher mode of operation.
SHA indicates the message authentication algorithm which is used to authenticate a message.
Based on all this information, you can test whether the solution you are connecting to is secure enough to fit your security guidelines or protocols within the company. To check this and the numerous possible vulnerabilities by hand would take some serious work, luckily there are many sites that can automate this for you. It also shows you whether your certificate is installed correctly.
One that is frequently used is the SSLtest on the Qualys website: https://www.ssllabs.com/ssltest/
Also, a nice addition, emailed to me by Elena Reyes, is this one, that is really fast, if you simply want to check if your certificate is installed correctly:
Thanks Elena! :D
When entering the name of the service you are connecting to, for instance a VDI environments fully qualified domain name, will actively go and check all the things that were previously mentioned in this post, and more. It will show you a score at the end, and if there are any issues, it will also show you exactly what is wrong and what can potentially be done about it.
If we apply this information to the VMware Unified Access Gateway, in its current release version 3.8, there are a number of protocols that are disabled by default, these are SSLv3 and TLSv1.0. The only reason to re-enable such old and vulnerable protocols would be if you have very old operating systems and clients, that do not support the newer protocols, but do need to be able to connect. Best thing to do would be to update those, but it's possible you have run into a situation in which this cannot (yet) be done. Be very careful in doing so, you might give hackers an easy way into your corporate network.
A check with the SSL Server Test on a default configuration of the UAG, with a correct certificate implemented, will give you a score of B. This is in no way a bad score, but the question could be asked is how to raise this. The disabling of TLSv1.1 on the Unified Access Gateway will give you a current score of A+ on this test at this moment.
The setting to Honor Cipher Order is disabled by default. In previous testing, enabling this cipher order was enough for most test sites. This controls which protocol is offered first, the highest possible would be offered first. By only allowing TLS 1.2 as a cipher suite, this has no added function.
This situation is as it is currently. This does not mean it is still accurate in the future. With the ever increasing security requirements, make sure to keep testing, to keep up with current affairs. Something that is deemed secure enough at this point in time, might not be secure enough anymore in the near future. Also remember, security and functionality are a delicate balance. Disabling a protocol could lead to a decrease in functionality, for instance older clients not being able to connect anymore.
Stay tuned for more Unified Access Gateway stuff!