Kai Thorsrud1709157845 Posted July 6, 2017 Share Posted July 6, 2017 There is a Netscaler Bug or undocumented limitation in regard to RFC 5746 on Backend. I have been struggling with Back End TLS with latest Netscaler 12 when talking to Windows Servers that have applied TLS Hardening. If Windows Servers have this registry setting: (Tested on 2008 R2 and 2012 R2 ) [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "AllowInsecureRenegoClients"=dword:00000000 "AllowInsecureRenegoServers"=dword:00000000 Netscaler Services will fail to communicate with them no matter what settings you use on “Secure Renegotiation” in my SSL Profiles. If I however delete the registry settings so that Windows Servers Allows Insecure Renego it works fine. Reading RFC 5745 I am guessing Netscaler does not utilize RFC 5746 Extension properly in the “TLS Client Hello” resulting in a TCP Reset from the Windows Servers. Link to comment Share on other sites More sharing options...
Nathan Joseph1709156207 Posted July 7, 2017 Share Posted July 7, 2017 Can confirm this on NS 11.0 builds as well, though I only had the issue if the AllowInsecureRenegoClients option is configured. Immediate TCP Reset after the TLS Client Hello. Never got around to opening a case, unfortunately. Link to comment Share on other sites More sharing options...
Rune Zimmermann Posted September 1, 2017 Share Posted September 1, 2017 I think this is more a limitation, than a bug. If subkey is set to 0, Windows seems expect the client to signal support for secure renegotiation as per RFC 5756. It seems Netscaler does not support renegotiation on backend, and therefore does not signal anything. I do think this is correct behavior from Netscaler. I solved my issue by setting subkey to 1 (disable renegostiation) on Windows. Link to comment Share on other sites More sharing options...
Kai Thorsrud1709157845 Posted September 1, 2017 Author Share Posted September 1, 2017 Netscaler has options where you specify SSL Reneg on Backend, it just does not work https://docs.citrix.com/en-us/netscaler/10-5/ns-tmg-wrapper-10-con/ns-ssl-wrapper-con-10/ns-ssl-config-ssloffloading-con/ns-ssl-profiles-tsk.html Link to comment Share on other sites More sharing options...
Christoph Sinabell Posted February 7, 2018 Share Posted February 7, 2018 Hi, We checked and secure renegotiation isn't required on the IIS backend (keys are not present). We found the issue. Basically Netscaler VPX will always use the same 19 chiper suites for backend communication for SSL VPN and SSL Monitors regardless what you configure on the vServer, Service or default SSL profiles. Those are: TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 TLS_DH_anon_WITH_DES_CBC_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA TLS_DH_anon_WITH_AES_256_CBC_SHA TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA Unfortunately this list doesn't include any TLS 1.2 chipers which are regarded as SSLLabs A(+) grade chipers like those listed in Citrix's own blog: https://www.citrix.com/blogs/2016/06/09/scoring-an-a-at-ssllabs-com-with-citrix-netscaler-2016-update/. Since all ECHDE chipers are not available for SSL VPN and monitors and TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 are also not part of this list, it will become increasingly difficult for customers to use gateway or monitors to connect to hardened SSL backends which have been configured to score an SSLabs A+ rating in the first place. Since this list of recommended chipers in the blog is rather widespread I suggest that Citrix adds support for those to fix the issue as turning of TLS 1.1 and 1.2 on the backend can only be a workaround but not the sultion. Regards Link to comment Share on other sites More sharing options...
Kai Thorsrud1709157845 Posted February 7, 2018 Author Share Posted February 7, 2018 If you followed that citrix persons reccommendation in the other thread he gave you commands that disables TLS 1.1 & 1.2 on backend. did you re-enable it again ? I can do TLS 1.2 perfectly fine on VPX towards IIS. I know IIS by default does not utilize reneg but if you follow / implement their best practise guides or run any of the IIS "Best Practise" tools Reneg will be enabled on IIS. Hence it is not possible for Netscaler to talk to a Microsoft IIS implemented after Microsofts Best Practise Guides due to Renegotiate. Link to comment Share on other sites More sharing options...
Christoph Sinabell Posted February 7, 2018 Share Posted February 7, 2018 Yes it's re-enabled again. TLS 1.2 is working fine as soon as we add a TLS 1.2 chiper from the list I wrote. It's just too bad VPX doesn't support those chiper suites recommended for scoring an A+ by Citrix and elsewhere. Link to comment Share on other sites More sharing options...
Kai Thorsrud1709157845 Posted February 7, 2018 Author Share Posted February 7, 2018 You can score A+ with a VPX. Applications and users connect to Front End not Back End. Link to comment Share on other sites More sharing options...
Christoph Sinabell Posted February 7, 2018 Share Posted February 7, 2018 That 27 minutes ago, Kai Thorsrud1709157845 said: You can score A+ with a VPX. Applications and users connect to Front End not Back End. of course, but you got me wrong. If the backend is already configured for A+ Netscaler VPX cannot connect to it using SSL. If Netscaler is used for SSL VPN, for ex. SecureWeb Micro VPN and the Website is an intranet application proxied through Netscaler Getway. it won't work unless you add one of the chipers on the website backend or you are SSL bridging a Sharepoint farm and cannot setup a SSL monitor if the cipher is missing. Link to comment Share on other sites More sharing options...
Kai Thorsrud1709157845 Posted February 7, 2018 Author Share Posted February 7, 2018 Ahh. Yes. I Agree and it should have worked. Lets hope Citrix will remedy this soon. Link to comment Share on other sites More sharing options...
Mark Hodges Posted July 29, 2018 Share Posted July 29, 2018 Does anyone know if this has been resolved in later versions of netscaler 12... I just hit this the other night trying to figure out why netscaler wouldn't talk to exchange servers after updating to apply recommended security settings. Link to comment Share on other sites More sharing options...
Nivo Hoffmann Posted October 9, 2020 Share Posted October 9, 2020 After upgrading to latest 13.0 64.35 there's no connection to the 2019'er Exchange servers possible. Same issue: RESET from the Exchange Server with default TLS config. Some say 13.0 does the trick - seems not to be like that. Even changing the SecureRenogation did not work to get get the ServiceGroup up. Link https://www.exchangelog.info/2020/02/netscaler-vs-exchange-2019-time-out.html shows how to downgrade tls security of the exchange servers. But that's not what we want to do. And 13.0 ist still Feature Release. When will Citrix release a adc firmware build in maintenance release working with standard tls exchange 2019? Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now