I'm a novice in regards to Transport Layer Security stuff, to bear with me...
I have some https web apps that I test locally using self-signed certs created with selfssl.exe. The company recently pushed new rules to everyone's machines that prevent the browsers from loading https sites that use anything other than TLS 1.2. However, my browsers give me certificate errors when I load my locally-hosted test stuff if TLS 1.0 is not enabled. Is it possible to generate self-signed certs that will work with my browsers if only TLS 1.2 is enabled?
I'm using Windows 7 64 bit with IIS 7.5, and I test with a variety of browsers (IE 11, Firefox 46, and Chrome 50).
No, it is not possible
SSL/TLS in all versions works with x509 digital certificates. The difference between TLS versions is the protocol rules, not the certificate.
The browser warns usually when the used protocol is old(consideres less secure) or the certificate is not trusted
Eventually figured this out. The answer is kinda dumb...
On Windows 7 / Windows Server 2008 R2, the TLS 1.2 protocol is installed, but disabled by default. When Big Brother pushed everybody to TLS 1.2, they did it with SCHANNEL registry entries, but they did not create the "DisabledByDefault" entry set to "0" so it blew up the security of all the Windows 7 users on the domain.
So, if you're going to use registry hacks to push users over to TLS 1.2, be sure to follow the instructions from Microsoft and remember to create a "DisabledByDefault" entry in the TLS 1.2 SCHANNEL key. :-)
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn786418(v=ws.11)
Related
I am using OpenShift Online Pro account , I deployed a web application using apache httpd2.4 server and I created a route with domain I purchased from AWS.
Then I add SSL certificates using letsencrypt , now when I test this router I can see tls 1.0 & 1.1 are deprecated and some list of weak ciphers and I want to remove them from this router.
How can I disable this 2 versions and remove weak Ciphers ?
Any help could be appreaciated!
In OpenShift, TLS ciphers can only be enabled / disabled on a Router basis (see documentation). This means for OpenShift Online this is most likely not possible, although I would recommend to ask Support about it.
A workaround would be to use a "passthrough" Route and to terminate TLS in your container. That way you can control what TLS versions your application / webserver is serving.
I have a web service that is currently being used by a variety of old .Net and Java clients using TLS1.0/SSl3 protocols using a SHA1 certificate.
If I were to change the certificate to be SHA2 would these clients still work ?
I am changing no other configurations on the server (i.e. not disabling TLS1 /SS3).
I will overtime when I can get the clients to upgrade to use TLS1.2.
.NET supports SHA2 since 1.1 (see What's the state of support for SHA-2 in various platforms?)
Java supports SHA2 since 1.4.2. (see https://www.entrust.com/should-you-use-sha-2/)
If you have access to these clients, and if they can connect to a different URL that uses a SHA2 certificate, you should be good. Give the users/ maintainers of these clients a date when you will be migrating your service to use a SHA2 certificate so that they can test it themselves.
I've installed a .Net-based website on multiple virtual machines (Windows 2012 R2), using the same version of the same installer on both. Part of this installation includes generation of a self-signed ssl certificate. When accessing the two websites over https, one is indicating "secure connection failed" when using Firefox, however the other server/website works fine. Both load in IE fine.
When looking at the page properties (from IE), the failing site indicates a connection of "TLS 1.0, AES with 128 bit encryption (High); RSA with 2048 bit exchange", while the successful one indicates "TLS 1.2, AES with 256 bit encryption (High); ECDH_P256 with 256 bit exchange".
What server settings should I be looking at to determine the difference between the two?
I tracked this down to an incompatibility between the self-signed certificate, which was using SHA512, and TLS. Changing the certificate to use SHA256 resolved the issue. The reason for the failure on one VM vs another was a registry setting, which dictated whether or not to support SHA512. The succeeding machine supported 512, the failing one did not.
https://blogs.technet.microsoft.com/silvana/2014/03/14/schannel-errors-on-scom-agent/
We have clients who can be using anything, WindowsXP,Vista,Linux....
Currently our systems support SSLV2 and SSLV3.But, we are planning to disable both SSLV2 and SSLV3 in windows server 2008R2 in favour of TLS 1.2.
Will it have any breaking changes with the end user?I'm worried that If I disable SSLV3 ( and SSLV2) , some of the clients who use windowsXP(for example) might not be able to access my web service.
PS: Tried to find a similar question in stackoverflow, didn't find any. So, posting this as a question. :)
This is one of the scenarios where you will NOT be able to support old clients using insecure protocols and expect to have decent security.
If you have not enabled TLS 1.2 yet, do so.
Some clients do not support TLS 1.2 (e.g., older Android versions). You may need to support TLS 1.0 and 1.1 in addition to 1.2. While not ideal, it is definitely better than supporting SSL 2.0 and 3.0.
Post an announcement indicating that your web service is being upgraded to meet minimum security requirements and set a date for retiring insecure protocols.
Optionally, check your server metrics to see what protocols/ ciphers are used. Since you haven't mentioned your web server, I'm assuming it is IIS, in which case this is not easy[1][2].
Retire SSL 2.0 and SSL 3.0. There will be a few clients who will not be able to connect. Plan to have an answer ready for them. If you have clients running XP and using IE6, they have bigger issues than not being able to access your web service.
While you are at it, run your TLS configuration through an online
scanner like SSL Labs to ensure you fix any other issues.
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