We have a requirements to use TLS1.2 on all servers. This means forcing TLS1.2 system wide using the registry settings below. When I set these settings and reboot the server, I get the below error message when expanding the BizTalk Group menu in BizTalk Administrator. In this particular environment, everything is running all on one operating system/server. Keep in mind, that if I enable TLS1.0 in the registry, everything works fine.
I've read several articles stating that ever since .NET 4.5, TLS1.1/1.2 are supported so...whats the issue here?
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"AspNetEnforceViewStateMac"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"AspNetEnforceViewStateMac"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
OS:Windows Server 2016
SQL Version:SQL Server 2016
BizTalk Version:BizTalk Enterprise 2016 CU3
.NET Version 4.7
Update: With Feature Pack 2 for BizTalk 2016 or CU5 it is supported.
Original answer
Unfortunately you cannot do that, as per the answer by Rajshekher-BT from Microsoft in Does BizTalk Server 2013 support TLS1.2? see below.
I raised it on User Voice (but that site is gone now)
BizTalk core engine needs TLS 1.0 to operate the host so you cannot disable TLS in registry. However you can have both TLS 1.0 and TLS 1.2 enabled and let .NET/WCF-based adapters prefer to use TLS 1.2 with SchUseStrongCrypto=1 registry key.
Some web servers may try to negotiate, while others fail on first attempt. In case you have different TLS settings in different WCF http end points, you can use WCF custom behaviour to set. You should then keep all TLS 1.0 in one host and all TLS 1.2 integration end points in another host using.
1. Make sure to keep both TLS 1.0 and TLS 1.2 enabled
2. Don’t set SchUseStrongCrypto registry key.
3. The default behavior at this point will TLS 1.0 (with fallback to SSL3) so for any WCF send port that needs TLS 1.2, set the System.Net.ServicePointManager.SecurityProtocol property using a custom endpoint behavior within a WCF-Custom send port.
If you want to allow fallback logic, you can OR it as follows:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12 | System.Net.SecurityProtocolType.Tls11 | System.Net.SecurityProtocolType.Tls | System.Net.SecurityProtocolType.Ssl3;
It is probably best to have one custom behavior for TLS 1.0 and one for TLS 1.2 so you are explicit and know what you use and it fails when something changes. Make sure to not mix the different WCF behaviors in the same host as ServicePointManager is a global process setting.
Personally I've used a configurable End Point behaviour as detailed in Salesforce disabling TLS 1.0 – How to get it working for API calls via BizTalk
Related
I inherited a web app that acts as a corporate dashboard. It's an ASP.NET app. .NET version = 4.7.2
It's running on two Windows 2016 Standard servers running IIS 10. Been in operation for many years.
One of the things the app does is make an HTTP request to a particular https:// URL, grab the data, parse out the JSON, and cache the list of objects. This has been working for many, many months. (Note: the "remote" server we're calling is still "in-house". Another person within my team basically "owns" that.)
Well, on Thanksgiving Weekend, it looks like the Prod App Pool cycled. And immediately that query started erroring with "System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel."
Myself and a few other folks were paged. At the time, we didn't notice (in Event Viewer) that the App Pool had cycled. After a few hours of investigating (and rebooting the app servers), the fellow who "owns" the server we are querying quickly set up a new end point for that same resource...setting it to allow HTTP connections / not require the use of HTTPS. The intention was that this would be a work-around until we could investigate the problem later.
Well, it's now "later".
The remote server that we are calling appears to require the use of TLS 1.3. I confirmed this by using both Firefox and Chrome on my own laptop to pull up a couple of https: urls on that server.
So, Ah-ha, I thought to myself, I had found information earlier this afternoon suggesting that Windows Server 2016 Standard didn't support the use of TLS 1.3! (https://learn.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-#tls-protocol-version-support)
But then I remembered: Earlier, I had been able to pull up those https: URLs in Chrome while logged onto my app's webservers! Sure enough, I went over there and retested with Firefox and Chrome. Both said the connections they'd made were using TLS version 1.3 !!
So, what the ???? That makes it seem like Windows Server 2016 Standard DOES support TLS 1.3 !??
And, from everything I've read, since my app is using .NET version 4.7.2, it should default to using whatever the default protocol for the OS is. So, shouldn't it too be using TLS 1.3 ? Why the heck can't it make a connection?
I'm certainly needing some direction on what to do next.
Thanks!
Background
Many statements from your question body above are true, but you need to put the contents into contexts so as to get the whole picture.
First, Chrome/Firefox supports TLS 1.3, but that support comes from the crypto libraries (many options out there, Mozilla NSS, OpenSSL and so on) they ship with themselves, not from Windows native crypto API.
Second, like you found out, Windows Server 2016 does not support TLS 1.3 natively because its underlying crypto API lacks of TLS 1.3 support. TLS 1.3 support is only included in Windows Server 2022 at this moment (and whether it will be back ported to previous Windows versions is unknown).
Third, when you try to analyze Windows components (like .NET Framework) or products, you need to identify what they rely on to perform TLS, Windows native crypto API or their own dependencies (like Chrome/Firefox does).
Answer to your specific ASP.NET question
Sadly it is well known that BCL classes in .NET Framework rely on Windows native crypto API, so on Windows Server 2016 you can go with TLS 1.2 at most.
If your application needs TLS 1.3 badly, you need to upgrade to Windows Server 2022, or switch to a third party crypto API.
Reference
https://www.quora.com/How-does-one-decide-between-OpenSSL-GnuTLS-and-Mozillas-NSS
TLS 1.2 on Windows Server 2003 and XP
We have a WinServer 2019 machine that needs to make REST requests to a third party using TLS1.2 and Cipher Suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. From what I've read, this suite should be enabled by default for this OS version, however, when we make the REST call with Schannel logging enabled I see that it's using CipherSuite: 0xC028 which corresponds to TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (CBC vs GCM). In PowerShell I've tried running Enable-TlsCiphterSuite -Name "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" -Position 0 and this does add it to the value at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002\Functions. Though, when I run Get-TlsCipherSuite in PowerShell the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 suite that was supposedly enabled does not show up.
Is there another place that needs to be changed in order for this cipher suite to be truly enabled?
The simplest way to achieve this would be downloading a copy of IIS Crypto.
From there you can select the cipher suites tab, enable your chosen cipher and move it to the top as the preferred cipher.
Be aware that some clients may fallback to a weaker cipher if it is available.
I am running my JDK8 application in JDK11 enviroment.
I am using TLSv1.2 and TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 cipher suite algorithm which i am suspecting that it is not supported or disabled in JDK11.
There are list of ciphers which are supported by jvm
please refer https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html
Also if you see here someone has listed cipher which is supported by jdk upto jdk1.8
https://developer.ibm.com/answers/questions/301898/where-i-can-find-list-of-cipher-suites-that-suppor/
but I want to know which cipher suite algorithm is supported/enabled/disabled in jdk11.
I am using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 cipher algorithm but when i am trying to run my application in jdk 11 run time environment I am getting SSLHandshakeException(Getting javax.net.ssl.SSLHandshakeException in JDK11). That's why I am trying to change my cipher suite algorithm and for the same i want to know which algorithm I can use in JDK11 enviroment.
It will be helpful if i also get to know the ciphers which are supported by both jdk11 and jdk8.
Please help me with it.
Thanks.
For revised Q:
Your first link is to (Oracle, and thus OpenJDK) java 7 not 8; there are differences in TLS ciphersuite support between 7 and 8, although not affecting the ciphersuite you name. Your link for 'upto 1.8' is for IBM Java which uses different cryptoproviders and is not good documentation for Oracle/OpenJDK crypto. Note the question at that link is specifically "... Cipher suites that supported by IBM Java" -- NOT Oracle/OpenJDK Java. For Oracle/OpenJDK 8 see https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#ciphersuites and for 11 see https://docs.oracle.com/en/java/javase/11/docs/specs/security/standard-names.html#jsse-cipher-suite-names . Both include TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 and as expected it works for me in Oracle 11.0.2, and numerous versions of 8. All TLSv1.2 ciphersuites supported in 8 are still supported in 11, although 11 additionally supports TLSv1.3 (which you apparently aren't using).
Aside from the fact that, as commented, the Java defaults usually do better at providing security than overrides by people who don't know what they're doing, the exception you report in your other Q (but didn't provide here)
javax.net.ssl.SSLHandshakeException: Invalid ECDH ServerKeyExchange signature
does not in any way indicate that the ciphersuite you name is unsupported. First, please be clear whether your application is the TLS client or server -- even if there is not a client/server relationship in the application protocol, there always is in the TLS protocol; that's how TLS (and SSL before it) is defined.
Second, follow the standard instructions for SSL/TLS=JSSE debugging by running with system property javax.net.debug=ssl and show the resulting output (probably just the last 100 lines or so, because it's quite voluminous).
Original Q was much vaguer and appeared to be about RC4, but actually wasn't.
Your question text gives no clue what 'cipher suite algorithm' you mean, but you tagged RC4-cipher. If your issue is using (any of the) ciphersuites that include RC4 in TLS 1.2 or earlier, then you shouldn't. RC4 was prohibited for TLS by RFC7465 in Feb. 2015 because of rapid advances in cryptanalytic attacks on it. This applies to all versions of TLS protocol existing in 2015 (1.0, 1.1 and 1.2), and was implemented by all supported versions of Java: 8 from 8u60 up, and all releases of 9 and higher.
If you really want to use RC4 and risk attackers stealing your data -- perhaps it is actually false, meaningless, or otherwise valueless -- either change the setting in the java.security file or call Security.setProperty early in your program (before loading JSSE); see the JSSE Reference Guide e.g. for Java11. Note in j8 the file location is different, <JREhome>/lib/security/java.security. See also RC4 related issue after Java 8 update .
If and when you (want or need to) use TLS 1.3, which Java 11 and up supports, this is no longer an option. TLS 1.3 only supports AEAD ciphers (or modes), which RC4 as originally defined is not, and no proposal for an AEAD construct based on RC4 will be accepted today.
On the other hand if you just want to use good, secure ciphersuites, don't change anything and just use the defaults. The defaults are the defaults precisely because they are secure, at least as far as is currently known. If analytic advances change that, then the defauts will be changed accordingly, and your programs using them will also be secure without you having to make, test, distribute, and verify new releases.
We got vulnerabilities on windows server 2008R2, we are using BizTalk server 2010, they are going to disable RC4 ciphers, However how do we check what are all the ciphers our BizTalk server supporting and where do we find those list.
Basically they are going to be disabling TLS 1.0.
What you need to do is install the .NET Framework v4.5.2, as the actually ciphers you are talking about are at the .Net layer rather than in BizTalk.
Then you need to set the registry keys to disable TLS 1.0 and enable it defaulting to a stronger cryptography.
There is a good article about "BizTalk Server 2010 and support for TLS 1.2"
Well, hold on. They are only 'vulnerabilities' if you're actually using them.
If you have no TLS(SSL) 1.0 endpoints (Receive Locations), you don't have a problem.
If you are calling TLS(SSL) 1.0 endpoints (Send Ports), then your trading partner needs to update first, then you can move to TLS >1.0.
While mvapich from version 2.3 deprecated the Nemesis interface, is there any way now to configure it at once for Infiniband support with fallback to TCP when failed? Or do I have to have two compilations for different network setups in my grid?
I'll answer my question with the information from MVAPICH developers:
At this point, the default MVAPICH channel cannot use TCP as a fallback if IB fails. We will see if such a support can be enabled in the future.