I have a .NET application that uses the Background Intelligent Transfer service to upload files from a client Windows 7 X64 machine to a Windows 2012 R2 server. The server is locked down for TLS 1.2 for compliance with PCI 3.1, i.e. protocols SSL 2.0/3.0, TLS 1.0/1.1 have been explicitly disabled in the reigstry using IISCrypto and TLS 1.2 enabled. The client has a trusted Root CA certificate for the server installed on it.
The application uses the IBackgroundCopyManager and IBackgroundCopyJob COM interfaces to create the job and add it to the queue. In the Bits-Client event log, I see the following warning after it has started the the transfer (note that addresses and filenames are for illustrative purposes only):
BITS stopped transferring the test.tmp transfer job that is associated with the https://server/folder/temp.tmp URL. The status code is 0x80072EFE
The error code translates to:
ERROR_WINHTTP_CONNECTION_ERROR
12030
The connection with the server has been reset or terminated, or an incompatible SSL protocol was encountered. For example, WinHTTP version 5.1 does not support SSL2 unless the client specifically enables it.
This makes sense, as I can see in Wireshark that the BITS request is only ever trying to use TLS 1.0 in the handshake protocol with the server and this has been disabled.
My question is therefore: is it possible to enable the use of TLS 1.2 by the Bits-Client and if so, how is it done?
The COM interface does not provide any methods to set the protocol used and I cannot see anything in the registry settings for the BITS service either. It is definitely not a certificate issue as the transfers work as soon as TLS 1.0 is enabled on the server.
BITS goes over WinHTTP and uses the default WINHTTP_OPTION_SECURE_PROTOCOLS. The problem is that your client is running Windows 7. From MSDN:
By default only SSL3 and TLS1 are enabled in Windows 7 and Windows 8. By default only SSL3, TLS1.0, TLS1.1, and TLS1.2 are enabled in Windows 8.1 and Windows 10
See this support article for instructions on how to enable TLS 1.1 and TLS 1.2 on Windows 7 machines: https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in
Related
I'm trying to access an SSL URL from a Windows browser to another machine running Tomcat and I am seeing error 36887 from Schannel in the System event log on the Windows machine with this description:
The TLS protocol defined fatal alert code is 70
According to MS documentation:
I've turned up Schannel logging (max=7) on the Windows machine and I can see that an SSL handshake was negotiated correctly, this from the event log:
An SSL server handshake completed successfully. The negotiated cryptographic parameters are as follows.
Protocol: TLS 1.2
CipherSuite: 0xC028
Exchange strength: 256
This seems to contradict the code 70 error.
Cipher suite 0xC028 is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384. I've checked on the Tomcat machine and can see that this is available, and TLS1.2 is also enabled on both machines so the successful handshake makes sense.
The process ID associated with the code 70 error belonged to lsass.exe - my Windows knowledge is quite limited so I have no idea what that does.
I can find nothing in the catalina.out log on the Tomcat machine, the code 70 seems to be happening before the request is actuall sent. I am certain that the certs are all configured correctly as I can access the URL successfully from other machines.
How can I progress from here?
The issue turned out to be that one of our client apps was using .NET 4.5.2 and defaulting to TLS1.1, which had been disabled at the server end by some patching. Ultimately a .NET update to 4.7.2 fixed the issue.
It means communication with the server was attempted using a recognized but unsupported TLS version. If your server is set to accept only communications using TLS 1.2 or newer, for example, then anything that tries to communicate via TLS 1.1 or lower will throw this error.
Two computers have to agree on a method of communication before they can actually do the communication. That is why this error message can occur and then the computers appear to communicate just fine... the first method was tried and rejected, and then a newer one was tried and succeeded, that's all.
Recently, we have encountered a problem while installing one of our applications for a customer. During installation the application needs to perform some requests to our cloud service and we realised it could not establish HTTPS connection: the very TLS handshake failed. After researching a bit we found the server was a Windows Server 2008 which does not support TLS v1.2, which is the minimum required to connect to our servers. There are some workarounds (this one, for instance) but none of them worked. In addition, we cannot install any update to that windows due to customer policies.
While looking for a solution, using wireshark, we noticed that our program tried to connect using TLS v1.2 and failed, but Chrome browser was able to connect to the same cloud server using TLS v1.3, which is not even supported in Windows Server 2008. From that we deduced that Chrome is likely using its own TLS stack to establish the connection.
I am wondering that if Chrome is doing that, we should also be able to do the same. The application is developed in .Net Core and I have googled a lot looking for information on how to do this, and I've found lots of information on how to configure TLS certificates in .Net Core, but none on replacing the TLS stack with, say, OpenSSL or others. I do know this is possible in Java, so is it possible to replace the TLS stack in .Net core?
.NET Core itself doesn't let you plug in your own crypto stack.
You pointed to Bouncy Castle as an example of Java letting you use an alternate crypto stack; there's a port of Bouncy Castle to C#/.NET as well.
Their source code has a test case that demonstrates how to write a TLS client using Bouncy Castle:
https://github.com/bcgit/bc-csharp/blob/master/crypto/test/src/crypto/tls/test/TlsClientTest.cs
We are currently using TFS 2015.3 on Windows server 2012 R2. After using NARTAC to specify using TLS1.1/1.2 and disable TLS1.0, our build tier server cannot connect to application tier server.
Does any have the same issue and got it fixed? Thank you
Regards,
Seems it's not supported for TLS 1.1 and TLS 1.2.
Ensure that your installation of TFS, the underlying .NET version(s), and Windows Server all support TLS 1.2 endpoints.
.NET Framework version(s) used by TFS must support TLS 1.2. Some .NET Framework versions may require additional registry settings for "SchUseStrongCrypto" as described here.
Whatever, you can have a try with the solution mentioned below:
By default .Net has a setting called “useStrongCrypto” that allows the
client PC to use TLS 1.1 and higher.
To enable secure your local client PC to use TLS 1.1 and higher (or as
Microsoft terms is “strong crypto”) you need to edit the following
registry entries:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SchUseStrongCrypto = 00000001 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319\SchUseStrongCrypto= 00000001
Or you could simply cut and paste the following into a .reg file and run it (only do this if you know what you’re doing).
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
Source here : Getting WebDeploy working after disabling insecure Ciphers like SSL 3.0 and TLS 1.0
Also this article for your reference: Misbehaving HTTPS Servers impair TLS 1.1 and TLS 1.2
Not \Microsoft.NETFramework\ You forgot the \ after Microsoft on the 2nd registry set
Use:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
Payment is requesting all traffic we sent to them be TLS 1.2, they are complaining now that we’re using TSL 1.0. For this
The first thing i did was, I have created a Windows 2012 R2 EC2 instance. In the regitry I have added the following under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL:
In protocols,
I have created the keys along with Dword,
SSL 2.0 (Client (disabled) server(Enabled),
SSL 3.0 (Client (disabled) server(Enabled),
TLS 1.1 (client (disabled)-server(Enabled)),
TLS 1.2 (client (Enabled)- server(Enabled))
After doing this, I restarted the server. Once i restarted, the RDP could able to connect to the server after making the changes. ( I stucked up here)
enter image description here
Assuming you are using .NET, you'll need to tell it to use the settings in SCHANNEL. Depending on your .NET version, it'll be something like:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v2.0.50727] "SystemDefaultTlsVersions"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v2.0.50727] "SystemDefaultTlsVersions"=dword:00000001
Alternatively, you could also use the "SchUseStrongCrypto" key or hard-code the values in ServicePointManager.SecurityProtocol.
Additional info:
https://support.microsoft.com/en-us/kb/3135244
https://blogs.msdn.microsoft.com/dataaccesstechnologies/2016/07/12/enable-tls-1-2-protocol-for-reporting-services-with-custom-net-application/#comment-3335
Our production server is running on Windows Server 2008 and currently has SSL 2.0 enabled. We are looking to migrate to TLS 1.0 protocol, we did find some help online as how to disable SSL and enable TLS 1.0 in the registry. We have various LIVE applications configured in our IIS and we would like to test this migration per application basis. I assume enabling TLS in the registry would affect all the applications in the Application Pool. My question is, is there a way to disable SSL and enable TLS for a single application, test it and then propagate it to all the applications?