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?
Related
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
I have a client who wants TSL1.0 and 1.1 disabled for their website.
I did that using powershell on the windows 2012R2 server. Perfect. But my MS SQL 2012 server on the machine became inaccessible, so I had to enable the protocols again.
I have been struggling to find ways to only deactivate these for IIS or possibly specific site.
Hope someone can help
Both IIS and SQL server run Schannel. And its far ahead IIS pipeline. So I'm afraid it's impossible to disable TLS 1.0 AND 1.1 for IIS site separately. Besides, disable TLS1.0 and 1.1 is not kind of best performance operation.
If you still require to disable TLS 1.0 and 1.1, then please focus on troubleshooting sql server inaccessible issue via network monitor. But I think you should disable SSL 2.0, 3.0 more than TLS 1.0 1.1.
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
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