Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
diagonjope
Partner - Creator II
Partner - Creator II

Port 9200 (Qlik License Service) does not come up after changing ciphers in service.conf...

Greetings!

We are following the instructions provided by Qlik's documentation to change the ciphers used in port 9200 (Qlik License Service).  We changed to section on [license.parameters]  in service.conf as shown below, but now the port does not come up

[licenses.parameters]
-qsefw-mode
-cipher-suites=TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
-app-settings="..\Licenses\appsettings.json"

We are running a single node instance of QSE June 2020 Patch 3 (13.82.11) on Windows Server 2012 R2 Standard.

Has anyone had a similar problem?  If so, how did you solve it?

Please advise.

Cheers,

++José

Labels (4)
1 Solution

Accepted Solutions
Levi_Turner
Employee
Employee

You have:
-cipher-suites=TLS_RSA_WITH_AES_128_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256
I have:
-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256

It looks like the component wants a ECDHE-RSA cipher. Plausibly because the ECDHE-RSA cipher is used server side to determine the key exchange whereas RSA alone is used client side to verify the key. But that's speculation from first principles. For more guidance, Qlik Support would be the right avenue but at minimum it looks like misleading documentation.

View solution in original post

17 Replies
Levi_Turner
Employee
Employee

I have not been able to get this working on the June 2020 release but it is working on my end on the September 2020 release. Is an upgrade possible to solve for this compliance issue?

HendrikJ
Contributor III
Contributor III

Do you by any chance know if the TLS_RSA ciphers can be disabled in the September 2020 release and Qlik is still working?

We are having the problem that we have a security finding because TLS_RSA ciphers are vulnerable to the TLS ROBOT attack.

Qlik says to disable TLS_RSA ciphers to mitigate this:

https://support.qlik.com/articles/000115202

However, if we disable those ciphers, and also disable all CBC ciphers (because those make the Qlik Proxy vulnerable to the GOLDENDOODLE vulnerability), Qlik does not work anymore. Not even the Qlik proxy is starting. We tested this on June 2020 and it also seems to be the case in the November 2020 release.
Do you have a working system wide cipher configuration that is not vulnerable to either GOLDENDOODLE or ROBOT and all Qlik services are still working?

Attached is our current cipher configuration where all components are working, but we are vulnerable to TLS ROBOT.

diagonjope
Partner - Creator II
Partner - Creator II
Author

Hi Levi,

 

Thanks for the suggestion.  We would have to confirm with the customer, but I think that we can try that.  Can you please check if the November 2020 version also works, so that we can take them to the latest version?  Please tag me with @diagonjope, so that I can I be notified when you respond (for some reason I did not get a notification to your response above).

Cheers,

++José

diagonjope
Partner - Creator II
Partner - Creator II
Author

Hi @HendrikJ ,

I think that @Levi_Turner is your best bet to get a proper answer to your question above.

Cheers,

++José

diagonjope
Partner - Creator II
Partner - Creator II
Author

Hi @Levi_Turner ,

I just checked with our demo server that is running QSE 13.102.5 (November 2020) on Windows Server 2016 Datacenter Edition and it also closes port 9200 when using the -cipher-suites=TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256 option.  It works fine when this line is not present in the services.conf file for Service Dispatcher.

jdiaz_0-1611849466338.png

Cheers,

++José

 

Levi_Turner
Employee
Employee

Sure. I am not seeing issues on November 2020:

Levi_Turner_0-1611884936271.png

 

HendrikJ
Contributor III
Contributor III

@diagonjope 

Just in case you did not know: the license server seems to support more ciphers than the rest of the Qlik services. So if you get the license server up and running with a new cipher configuration, make sure to also restart all other Qlik services and check if everything still works. Had this happen to me and it cost me quite some time to figure out what was wrong.

I can confirm that TLS_RSA_WITH_AES_128_GCM_SHA256 works, however, we can not use this anymore since it leads to a security finding due to the TLS ROBOT vulnerability. Qlik article 000115202 says to disable all TLS_RSA ciphers, but then we do not have any ciphers left that work with all Qlik services (and not have vulnerabilities). But that may differ for you depending on your organizations strictness in security.

 

We also need to supply more than those two ciphers for the service to start up, but it's an old testing version of Qlik (June 2020).
A working string for us is:

-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

diagonjope
Partner - Creator II
Partner - Creator II
Author

Thank you @Levi_Turner for the image.  We will ask the customer to use IIS Cryto to validate that the ciphers are properly configured.  We tried using both September 2020 and November 2020 with the ciphers they want and couldn't make it work - even when trying other ciphers.  However, when we used nmap to check the status of the RDP port, which is configured to use the same cipher, it would come up OK (as shown in the image below).

Cheers,

++José

diagonjope
Partner - Creator II
Partner - Creator II
Author

Hi @HendrikJ !

Thanks for the heads up.  It's interesting that the line you provide includes both he RCA ciphers they want as well as others TLS_ECDHE_ECDSA* that we tried and couldn't make it work. 

Thanks as well for the heads-up on on restarting the other services.  We will do that.

Cheers,

++José