A lot of Infoblox customers have asked for the capability to have NIOS use TLS 1.2 for the HTTPS connection from an administrator's browser to the NIOS web interface presented by the grid master. They've also asked for the ability to disable the use of RC4 and other weak ciphers in HTTPS connections to the NIOS web interface. I'm happy to report that both capabilities are now available in NIOS 8.0, which was just released to the Infoblox support site. (These capabilities also apply to API connections, which also use HTTPS.)
I was playing around with this on my demo grid, and I thought I'd pass on the results of my testing so that you can save yourself some time searching through the documentation and avoid some of the confusion I created for myself. There are three cases I address, depending on how sophisticated you want or need to be in configuring TLS.
For most uses the default TLS configuration in NIOS 8.0 is fine and need not be changed:
- By default HTTPS connections support TLS 1.0, 1.1, and 1.2.
- By default HTTPS connections do not support the use of RC4 or DES.
If your browser supports TLS 1.2 and prefers it to TLS 1.1 or 1.0 then you will automatically get a TLS 1.2 connection with a relatively strong ciphersuite.
In some cases you may wish to disable the use of TLS 1.0 and 1.1 entirely, and force browsers to use (only) TLS 1.2. This can be done using two new CLI commands, "set ssl_tls_settings" and "set ssl_tls_protocols". (There is no comparable way in the web interface to set this; you need to use the CLI.) These commands need to be executed on the grid master (only).
The CLI command "set ssl_tls_settings" determines whether you are using the default TLS configuration (see above) or if you want to override the default. Once you override the default configuration you can then use the command "set ssl_tls_protocols" to disable or enable particular TLS versions. Here's the default configuration in NIOS 8.0 as shipped:
Infoblox > show ssl_tls_settings SSL/TLS settings: default Use 'ssl_tls_protocols' and 'ssl_tls_ciphers' to see current settings Infoblox > show ssl_tls_protocols TLSv1.0 TLSv1.1 TLSv1.2
If you want to disable TLS 1.0 and 1.1 then execute the following commands:
Infoblox > set ssl_tls_settings override The following services need to be restarted manually: GUI Infoblox > set ssl_tls_protocols disable TLSv1.0 TLSv1.0 was disabled. Current configuration: TLSv1.1 TLSv1.2 The following services need to be restarted manually: GUI Infoblox > set ssl_tls_protocols disable TLSv1.1 TLSv1.1 was disabled. Current configuration: TLSv1.2 The following services need to be restarted manually: GUI Infoblox >
The message about restarting the GUI is somewhat confusing. As far as I can tell there's nothing you need to do on the Infoblox end. You simply need to start a new HTTPS session to the grid master in your browser.
If your site has especially stringent requirements for TLS, or if you're the sort of person who likes to test your web sites against the Qualys SSL Labs server test, then you may want to exercise more fine-grained control over the TLS ciphersuites used by the web interface. You can do this using the CLI command "set ssl_tls_ciphers".
WARNING: If you use this command it is possible to put your web interface into a state where no browser can connect to it, because the browser and the web server cannot negotiate a common ciphersuite. If this happens to you, you can either continue to tweak the settings using "set ssl_tls_ciphers", or you can use the command "set ssl_tls_settings default" to return the system to the default TLS configuration while you figure out what you did wrong.
Here is the default set of ciphersuites as shipped; these are ordered from top to bottom, with earlier ciphersuites being preferred to later ones:
Infoblox > show ssl_tls_ciphers 1. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 enabled 2. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 enabled 3. TLS_DHE_RSA_WITH_AES_128_CBC_SHA enabled 4. TLS_DHE_RSA_WITH_AES_256_CBC_SHA enabled 5. TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 enabled 6. TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 enabled 7. TLS_RSA_WITH_AES_128_GCM_SHA256 enabled 8. TLS_RSA_WITH_AES_128_CBC_SHA enabled 9. TLS_RSA_WITH_AES_128_CBC_SHA256 enabled 10. TLS_RSA_WITH_3DES_EDE_CBC_SHA enabled 11. TLS_RSA_WITH_AES_256_GCM_SHA384 enabled 12. TLS_RSA_WITH_AES_256_CBC_SHA enabled 13. TLS_RSA_WITH_AES_256_CBC_SHA256 enabled TLS_DHE_DSS_WITH_AES_256_CBC_SHA disabled TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA disabled TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA disabled TLS_DHE_DSS_WITH_AES_128_CBC_SHA disabled TLS_RSA_WITH_RC4_128_SHA disabled TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 disabled TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 disabled TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 disabled TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 disabled Infoblox>
The ciphersuite names are those used in the RFC documents for TLS. A number of documents on the web instead reference the ciphersuite names used by OpenSSL. Here's a list of how the RFC names map to the OpenSSL names:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 DHE-RSA-AES128-GCM-SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 DHE-RSA-AES256-GCM-SHA384 TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE-RSA-AES128-SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE-RSA-AES256-SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE-RSA-AES128-SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE-RSA-AES256-SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 AES128-GCM-SHA256 TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA TLS_RSA_WITH_AES_128_CBC_SHA256 AES128-SHA256 TLS_RSA_WITH_3DES_EDE_CBC_SHA DES-CBC3-SHA TLS_RSA_WITH_AES_256_GCM_SHA384 AES256-GCM-SHA384 TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA TLS_RSA_WITH_AES_256_CBC_SHA256 AES256-SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE-DSS-AES256-SHA TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH-RSA-DES-CBC3-SHA TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH-DSS-DES-CBC3-SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE-DSS-AES128-SHA TLS_RSA_WITH_RC4_128_SHA RC4-SHA TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 DHE-DSS-AES256-GCM-SHA384 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 DHE-DSS-AES256-SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 DHE-DSS-AES128-GCM-SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 DHE-DSS-AES128-SHA256
As an example of how to change the ciphersuites, suppose that for some reason you needed to re-enable the use of RC4. You could do this as follows:
Infoblox > set ssl_tls_settings override The following services need to be restarted manually: GUI Infoblox > set ssl_tls_ciphers enable TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_SHA was enabled The following services need to be restarted manually: GUI Infoblox > show ssl_tls_ciphers 1. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 enabled 2. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 enabled 3. TLS_DHE_RSA_WITH_AES_128_CBC_SHA enabled 4. TLS_DHE_RSA_WITH_AES_256_CBC_SHA enabled 5. TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 enabled 6. TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 enabled 7. TLS_RSA_WITH_AES_128_GCM_SHA256 enabled 8. TLS_RSA_WITH_AES_128_CBC_SHA enabled 9. TLS_RSA_WITH_AES_128_CBC_SHA256 enabled 10. TLS_RSA_WITH_3DES_EDE_CBC_SHA enabled 11. TLS_RSA_WITH_AES_256_GCM_SHA384 enabled 12. TLS_RSA_WITH_AES_256_CBC_SHA enabled 13. TLS_RSA_WITH_AES_256_CBC_SHA256 enabled 14. TLS_RSA_WITH_RC4_128_SHA enabled TLS_DHE_DSS_WITH_AES_256_CBC_SHA disabled TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA disabled TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA disabled TLS_DHE_DSS_WITH_AES_128_CBC_SHA disabled TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 disabled TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 disabled TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 disabled TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 disabled Infoblox >
By default any ciphersuites you enable get appended to the list of already-enabled ciphersuites, so that the RC4 ciphersuite goes into position 14 in the list. It will be used only if none of the other cipher suites are usable by the connecting browser. (You can also force the new ciphersuite to go into a particular position in the list by adding a position number at the end of the command, after the ciphersuite name.)
Suppose you then want to disable the use of RC4 again. You can do this as follows:
Infoblox > set ssl_tls_ciphers disable 14 TLS_RSA_WITH_RC4_128_SHA was disabled The following services need to be restarted manually: GUI Infoblox >
Note that (unlike enabling) you disable cipher suites by referencing their current position in the list, not by referencing their names.
A final thought: There are some useful references on the web regarding recommended ciphersuites, including the SSL Labs document "SSL and TLS Deployment Best Practices" and the Mozilla document "Security/Server Side TLS". However be aware that NIOS does not currently support some of the newer ciphersuites referenced in these documents, including in particular the "ECDHE" ciphersuites. Also, if you disable all the non-DHE RSA ciphersuites (as implied by the SSL Labs document) then you will cause problems for Safari, Chrome, and possibly other browsers. So proceed with caution, and test all the browsers you are likely to use.
Solved! Go to Solution.
11-16-2018 03:24 PM
Do we know if there's any way to disable or tweak the HTTP Strict Transport Security (HSTS) settings that got added in NIOS 8.3?
I've been doing some testing with custom certs lately and I keep getting myself locked out because modern browsers are trying to respect the HSTS settings.
09-21-2020 02:15 PM
I was just looking at this post and realized I never answered this question about what to do if browser HSTS settings are preventing you from logging in to the web GUI. (For example, this can occur if you put a CA-issued TLS certificate on the grid master, and the certificate expires.)
09-21-2020 02:18 PM
Sure, there are ways to workaround the problem in the browser that I ended up figuring out. But I'm still hoping there is or will eventually be a way to change the configuration on the Infoblox side so I no longer need the browser workaround.
10-27-2020 01:53 PM
My apologies for the belated reply. To my knowledge the only way to work around HSTS issues on the Infoblox (web server) side is to install a valid TLS server certificate that the browser can validate. (In other words, the certificate must chain up to a root CA certificate that comes pre-loaded with the browser or that can be imported into it.
You can use the Let's Encrypt service to issue TLS server certificates for Infoblox grid masters, if you don't have an enterprise Certificate Authority. You create a Certificate Signing Request from the Infoblox GUI, with a common name referencing the FQDN of the grid master. Then you use the Let's Encrypt certbot command to issue a certificate for the CSR, using the DNS challenge mechanism. To validate your ownership of the enterprise domain you'll need to add special TXT records to the (external) zone for the enterprise; the certbot utility will tell you the values of the TXT records. Then once the certificate is issued you can import it into the grid master.
10-27-2020 02:09 PM - edited 10-27-2020 02:09 PM
Thanks Frank. No worries on the delay. I'm actually quite familiar with Let's Encrypt having written my own PowerShell client for it called Posh-ACME. Ironically, it was during the development of that client and my subsequent attempts to import the resulting certs to the grid that I ran into the HSTS issues to begin with.
Still hoping eventually for a CLI command or API method to tell the grid not to send the HSTS header at all. Having it on is obviously the best default, but having the ability to selectively turn it off would be great too. I just need to find a large enough customer to push an RFE.
11-26-2020 07:09 AM
After removing all non-ECDHE ciphers on our Windows system, the connection to the Infoblox API fails. When will Infoblox support ECDHE ciphers to access the GUI/(W)API?
11-26-2020 08:35 AM
Yeah, it's rather surprising that the cipher suites available even on the latest NIOS 8.5.1 are so old. It's definitely starting to break things as people and toolchains enhance their security defaults.
Case in point, the latest .NET 5 and PowerShell 7.1 breaks connecting to Infoblox when running on a default Linux install due to cipher mismatches.