(How-To) Disable NSX-T Manager TLS Protocol Versions
As time passes, cryptographic protocols can become vulnerable to compromise. This leads to the development and adoption of new versions of a protocol or entirely new protocols to keep our data secure.
Transport Layer Security (TLS) has gone through a number of iterations over the years to try and keep ahead of would be attackers who wish to compromise our data. The current latest version of TLS, as of this writing is TLSv1.3, published in 2018. TLSv1.1 was deprecated in early 2020.
To ensure our servers are only accepting connections using secure cryptographic protocols we often need to restrict which protocols are enabled on a server. NSX-T manager appliances include TLSv1.1 and TLSv1.2 enabled by default. This article will walk you through confirming what TLS protocols are enabled as well as how to disable TLS protocol versions to harden your deployment.
Determine What TLS Versions are Currently Enabled
Nmap
The easiest way to determine what TLS versions are enabled/supported by your appliance is to run the following Nmap scan against the appliance. Here is the output from an NSX-T manager’s default configuration.
nmap --script ssl-enum-ciphers -p 443 nsxt-mgr.cloudbytesecurity.com
Starting Nmap 7.80 ( https://nmap.org ) at 2020-05-19 10:17 MDT
Nmap scan report for nsxt-mgr.cloudbytesecurity.com (10.0.1.72)
Host is up (0.00026s latency).
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.1:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| compressors:
| NULL
| cipher preference: client
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| compressors:
| NULL
| cipher preference: client
|_ least strength: A
MAC Address: 00:50:56:B2:A7:E7 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.72 seconds
OpenSSL
If you do not have Nmap or wish to see what TLS protocols are supported locally on the NSX-T manager you can run the following OpenSSL commands from the NSX-T manager CLI.
To verify TLSv1.0 is NOT enabled we can run the following command. As you can see from the output, no certificate is retrieved and there is a “wrong version number” error
openssl s_client -connect nsxt-mgr.cloudbytesecurity.com:443 -tls1
CONNECTED(00000003)
115058477688472:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:365:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1589904395
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
To verify TLSv1.1 is eanbled we can run the following command:
openssl s_client -connect nsxt-mgr.cloudbytesecurity.com:443 -tls1_1
CONNECTED(00000003)
depth=0 C = US, ST = CA, L = Palo Alto, O = VMware Inc., OU = NSX, CN = nsxt-mgr
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = CA, L = Palo Alto, O = VMware Inc., OU = NSX, CN = nsxt-mgr
verify return:1
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 5EC404AD830BC75A132BB5E4C7ABAA5CF3A7847C765917D2AE061DFB0838E604
Session-ID-ctx:
Master-Key: 9510C45CE091D4F1E3202187B818ED29C97403FBAC98685477AA0DE6A2BF678BCC9FFC9DE39FAB9BECE7CBB961ED31A3
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1589904557
Timeout : 7200 (sec)
Verify return code: 18 (self signed certificate)
---
To verify TLSv1.2 is eanbled we can run the following command:
openssl s_client -connect nsxt-mgr.cloudbytesecurity.com:443 -tls1_2
CONNECTED(00000003)
depth=0 C = US, ST = CA, L = Palo Alto, O = VMware Inc., OU = NSX, CN = nsxt-mgr
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = CA, L = Palo Alto, O = VMware Inc., OU = NSX, CN = nsxt-mgr
verify return:1
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 5EC47082D8C32416FF9FE826F0B8EC6C149840A84635336BC692B7AC27B64040
Session-ID-ctx:
Master-Key: C431725A2E525D0DAF7CEB4F25DE56107CE043C5DFE46CA15A3376772E20901DFA6ABF9B15E6F3536AF4BC8977816958
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1589932162
Timeout : 7200 (sec)
Verify return code: 18 (self signed certificate)
---
Steps to Disable Unwanted TLS Versions
Now that we have confirmed our NSX-T manager appliances have TLSv1.1 and TLSv1.2 enabled by default we can now disable the weaker TLSv1.1 to further harden our NSX-T deployment.
1) Login to one of the NSX-T manager appliances CLI via root. This can be done by either logging directly into the manager via root, if enabled. Or you can login via ‘admin’ and then change the user from ‘admin’ to ‘root’ by typing st en, hitting enter and providing the root password.
Once you are logged into an NSX-T manager appliance via ‘root’ we can begin to run our API calls.
2) First we will need to run a GET command to pull down the current cryptographic configuration. This configuration output will be modified and run later in a PUT command to disable the unwanted TLS versions.
curl -v -H "Content-Type:application/json" -k -u admin -X GET "https://127.0.0.1/api/v1/cluster/api-service" -o api-output.jsonCommand Flags:
| -v | verbose – Makes the curl command run with verbosity. |
| -H | Header – Header to include in the request to pull json formatted output |
| -k | Insecure – Do not check the certificate being presented by the server |
| -u | User – Define the user. You can add a colon ‘:’ and the password in clear text if you wish |
| -X | Request – Specified the request type to be used. i.e. GET, PUT, POST, etc… |
| -o | Output – Output to a file the body returned by the command |
After running the API call we can view and edit the body output in the api-output.json file created in the current working directory where the command was run.
3) To edit and view the API call body run the following command:
vim api-output.jsonapi-output.json
{
"basic_authentication_enabled": true,
"cipher_suites": [
{
"enabled": true,
"name": "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
},
{
"enabled": true,
"name": "TLS_RSA_WITH_AES_256_GCM_SHA384"
},
{
"enabled": true,
"name": "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
},
{
"enabled": true,
"name": "TLS_RSA_WITH_AES_128_GCM_SHA256"
},
{
"enabled": true,
"name": "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
},
{
"enabled": true,
"name": "TLS_RSA_WITH_AES_256_CBC_SHA256"
},
{
"enabled": true,
"name": "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA"
},
{
"enabled": true,
"name": "TLS_RSA_WITH_AES_256_CBC_SHA"
},
{
"enabled": true,
"name": "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
},
{
"enabled": true,
"name": "TLS_RSA_WITH_AES_128_CBC_SHA256"
},
{
"enabled": true,
"name": "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"
},
{
"enabled": true,
"name": "TLS_RSA_WITH_AES_128_CBC_SHA"
}
],
"client_api_concurrency_limit": 40,
"client_api_rate_limit": 100,
"connection_timeout": 30,
"cookie_based_authentication_enabled": true,
"global_api_concurrency_limit": 199,
"lockout_immune_addresses": [],
"protocol_versions": [
{
"enabled": true,
"name": "TLSv1.1"
},
{
"enabled": true,
"name": "TLSv1.2"
}
],
"redirect_host": "",
"session_timeout": 1800
}
We can see from the bottom of the output file in the “portocol_versions” section (lines 61-62 and 65-66) that TLSv1.1 and TLSv1.2 are enabled. We are going to modify the TLSv1.1 “enabled” line (61) from true to false.
{
"enabled": false,
"name": "TLSv1.1"
},
{
"enabled": true,
"name": "TLSv1.2"
}
],
"redirect_host": "",
"session_timeout": 1800
}
After making the change, save and exit
:wqNow that we have successfully modified the file, we can run our next API call and send this file as the body of the API PUT call.
4) To push the configuration change made in the output file we will need to run the following API call.
curl -v -H "Content-Type:application/json" -k -u admin -X PUT "https://127.0.0.1/api/v1/cluster/api-service" -d@api-output.json| -v | verbose – Makes the curl command run with verbosity. |
| -H | Header – Header to include in the request to pull json formatted output |
| -k | Insecure – Do not check the certificate being presented by the server |
| -u | User – Define the user. You can add a colon ‘:’ and the password in clear text if you wish |
| -X | Request – Specified the request type to be used. i.e. GET, PUT, POST, etc… |
| -d@ | Data @ – The file name after the @ symbol will pull the contents of the file and send as the body of the call |
Verify The Change Was Successful
Now that we have modified the ‘active’ TLS settings on our NSX-T management cluster we can verify the change has been successful.
Nmap Validation
nmap --script ssl-enum-ciphers -p 443 nsxt-mgr.cloudbytesecurity.com
Starting Nmap 7.80 ( https://nmap.org ) at 2020-05-19 12:00 MDT
Nmap scan report for nsxt-mgr.cloudbytesecurity.com (10.0.1.72)
Host is up (0.00021s latency).
PORT STATE SERVICE
443/tcp open https
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| compressors:
| NULL
| cipher preference: client
|_ least strength: A
MAC Address: 00:50:56:B2:A7:E7 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.67 seconds
We can see from the above output only TLSv1.2 is now present. Our API call was successful.
OpenSSL
We can also validate the change was successful by running the same OpenSSL commands we ran at the beginning of this article to validate which TLS protocol versions are enabled by default.
To verify TLSv1.1 is no longer enabled we can run the following command:
openssl s_client -connect nsxt-mgr.cloudbytesecurity.com:443 -tls1_1
CONNECTED(00000003)
122910085715608:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:365:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1589985735
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
Finally, to verify TLSv1.2 is still enabled we can run the following command:
openssl s_client -connect nsxt-mgr.cloudbytesecurity.com:443 -tls1_12
CONNECTED(00000003)
depth=0 C = US, ST = CA, L = Palo Alto, O = VMware Inc., OU = NSX, CN = nsxt-mgr
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = CA, L = Palo Alto, O = VMware Inc., OU = NSX, CN = nsxt-mgr
verify return:1
---
SSL handshake has read 12215 bytes and written 493 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 5EC542AD7829BFAB42C23FF6181970F23788C3DEF113D445BAD86F31927846DE
Session-ID-ctx:
Master-Key: 40B24AE23E91FC04527FC18C421EBAFE2E6795C2CDAD299216BA4AA76E103314038721D3C42A1F98D0D1FF23987DD62D
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1589985965
Timeout : 7200 (sec)
Verify return code: 18 (self signed certificate)
---
Ensure you document under your change control this change has been made to ensure if there is a communication issue in the future when integrating VMware or third party products this can be notated since other products may require the TLSv1.1 protocol to be enabled for communication to occur between appliances.
Finally, after an NSX-T upgrade you will want to run the above validation commands again against the NSX-T manager to verify these TLS settings have not been altered during the upgrade.
CLOUDbyteSECURITY 