Reply

Configuring TLS 1.2 and ciphersuites in NIOS 8.0

[ Edited ]
Adviser
Posts: 138
24729     11

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.

 

Basic Usage

 

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.

 

Intermediate Usage

 

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.

 

Advanced Usage

 

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.

Re: Configuring TLS 1.2 and ciphersuites in NIOS 8.0

Expert
Posts: 244
24730     11

Excellent article.  Thanks, Frank!

Re: Configuring TLS 1.2 and ciphersuites in NIOS 8.0

Adviser
Posts: 52
24730     11

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?

https://docs.infoblox.com/display/nios83/What%27s+New

 

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.

Re: Configuring TLS 1.2 and ciphersuites in NIOS 8.0

Adviser
Posts: 138
24730     11

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.)

 

In that situation I have been able to recover by connecting to the web GUI using the grid master's IP address instead of its FQDN, e.g., "https://192.168.0.11" vs. "https://gm.example.com".

Re: Configuring TLS 1.2 and ciphersuites in NIOS 8.0

Adviser
Posts: 52
24730     11

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.

Re: Configuring TLS 1.2 and ciphersuites in NIOS 8.0

Adviser
Posts: 138
24730     11

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.

 

Frank

 

Re: Configuring TLS 1.2 and ciphersuites in NIOS 8.0

[ Edited ]
Adviser
Posts: 52
24730     11

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.

Re: Configuring TLS 1.2 and ciphersuites in NIOS 8.0

Member
Posts: 1
24730     11

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?

Re: Configuring TLS 1.2 and ciphersuites in NIOS 8.0

Adviser
Posts: 52
24730     11

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.

https://github.com/PowerShell/PowerShell/issues/14253

 

Re: Configuring TLS 1.2 and ciphersuites in NIOS 8.0

Techie
Posts: 3
24730     11

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.

Re: Configuring TLS 1.2 and ciphersuites in NIOS 8.0

Authority
Posts: 15
24730     11

Hi Frank,

I am using a valid wildcard certificate which cost me a lot, but I can use this for several servers I have at home.

I also installed a wildcard certificate in my Grid, the reason I installed the wildcard also on my Grid was that I wanted to get rid of the message saying that the certificate is not valid everytime I logon, and that was working just fine with the wildcard certificate until my webbrowsers got updated, now I have this issue that I can't use the FQDN but need to use the ip address which I don't find a good sollution.

So in a way to me it seams that HSTS is killing the wildcard certificate which I just purchased.

Kind Regards,

 

Stefan

 

Re: Configuring TLS 1.2 and ciphersuites in NIOS 8.0

Adviser
Posts: 52
24730     11

Unlimited certs (including SAN and wildcard) can be obtained for free from Let's Encrypt, just fyi. There's no need to pay for certs in 2021 unless you have to abide by regulations that mandate using OV or EV certs.

 

That said, there's nothing about HSTS that would make your existing wildcard cert stop working. All HSTS does tell the browser to only ever use HTTPS with a given site. And if a valid HTTPS session can't be established, most browsers will prevent you from bypassing the error (without hidden workarounds). HSTS doesn't fundamentally change anything about how HTTPS works.

 

I'm guessing your problem is that the wildcard name in the cert doesn't match the hostname you're using on the grid master...or the grid has redirected you to a URL that has the IP address which is also not usually covered by a public cert.

Re: Configuring TLS 1.2 and ciphersuites in NIOS 8.0

Adviser
Posts: 138
24730     11

My apologies for the delay in responding. I'm not sure what you mean by "installed the wildcard certificate on the grid". Did you attempt to upload an HTTPS certificate and its associated private key? I didn't think that would work with current NIOS. Traditionally NIOS has required generating a certificate signing request or CSR (which contains only the public key, not the private key), and then have an external CA (whether an enterprise CA or Let's Encrypt) use the CSR to produce a signed certificate, which you can then upload back into the grid.

Re: Configuring TLS 1.2 and ciphersuites in NIOS 8.0

Adviser
Posts: 138
24730     11

You learn something new every day: An Infoblox colleague informs me that NIOS 8.3 and later supports uploading of a private key along with the certificate (which is of course what you'd need to do for a wildcard certificate).  My apologies for the confusion.

Re: Configuring TLS 1.2 and ciphersuites in NIOS 8.0

Adviser
Posts: 138
24730     11

Anyway, back to this issue. I agree with mbolger here, I can't think of anything that could be causing HSTS issues other than a problem with the certificate: a name mismatch, certificate expiration, etc. My first recommendation would be to try a different browser if you have one installed, and see if you get the same behavior. Or try the same browser on a different system.

 

You could also try clearing the HSTS settings in the browser. Just do an Internet search for "clear hsts setting in Firefox" (or Chrome, or Safari, or Edge, or whatever browser is causing you problems.

Showing results for 
Search instead for 
Did you mean: 

Recommended for You

Demo: Infoblox IPAM plug-in integration with OpenStack Newton