Enabling the rc4 cipher in internet explorer 11. Solving the problem yourself

15.05.2022

For some reason, some HTTPS sites (not all!) stopped opening for me. When you try to open such a site in your browser, a window with the error “This site cannot provide a secure connection” appears. Sites are not displayed as in Google Chrome, both in Opera and Yandex Browser. Without HTTPS, some sites open, but not all, only those whose pages are accessible via both the HTTPS and HTTP protocols. In Google Chrome, the error when opening an HTTPS site looks like this:

This site may not provide a secure connection.
The site sitename.ru uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH.
Client and server support different versions SSL protocol and cipher suite. Most likely, the server uses the RC4 cipher, which is considered insecure."

In Opera and Yandex Browser the error looks approximately the same. How can I open such sites?

Answer

As you probably already understood, the problem is related to problems with SSL communication between your computer and the HTTPS site. The reasons for such an error can be quite different. In this article, I tried to collect all the methods for fixing the “This site can’t provide a secure connection, ERR_SSL_PROTOCOL_ERROR” error in various browsers.

I would like to immediately note that despite the fact that Google browsers Chrome, Opera and Yandex Browser are produced by different companies, in fact, all these browsers are based on the same engine - Chrome and the problem with errors in opening HTTPS sites is solved in the same way.

First of all, you need to make sure that the problem is not on the side of the HTTPS site itself. Try opening it from other devices (phone, tablet, home/work computer, etc.). Also check if it opens in other browsers, for example IE/Edge or Mozilla Firefox. In Firefox, a similar error was discussed in the article.

Clear browser cache and cookies, SSL cache

Browser cache and cookies can be a common cause of errors with SSL certificates. We recommend clearing your browser's cache and cookies first. In Chrome you need to press a keyboard shortcut Ctrl + Shift + Delete, select a time period ( All the time) and click the clear data button ( Delete data/ Clear Data).

To clear the SSL cache on Windows:

Go to section Control Panel -> Browser properties;
Click on the tab Content;
Click on the button Clear SSL (Clear SSL State);
The message “SSL cache cleared successfully” should appear;
All that remains is to restart the browser and check if the ERR_SSL_PROTOCOL_ERROR error remains.

Disable third-party browser extensions

We recommend disabling (uninstalling) third-party browser extensions, especially any anonymizers, proxies, VPNs, antivirus extensions and other similar Addons that can interfere with the passage of traffic to the target site. You can view the list of enabled extensions in Chrome by going to Settings -> Additional tools -> Extensions, or by going to the page chrome://extensions/. Disable all suspicious extensions.

Check your antivirus and firewall settings

If you have installed on your computer antivirus program or firewall(often it is built into the antivirus), perhaps access to the site is blocked by them. To understand whether antiviruses or firewalls are restricting access to a site, try pausing their operation for a while.
Many modern antiviruses have a module for checking SST/TLS website certificates by default. If the antivirus detects that the site is using an insufficiently protected (or) certificate or outdated version SSL protocol (the same), user access to such a site may be limited. Try disabling scanning of HTTP/HTTPS traffic and SSL certificates. As you understand, it all depends on what antivirus you have installed. For example:

Check date and time settings

Incorrect date and time(s) on your computer can also cause errors when establishing a secure connection to HTTPS sites. After all, when performing authentication, the system checks the creation period and expiration date of the site certificate and the higher certification authority.

Update Windows Root Certificates

If your computer is in an isolated segment, has not been updated for a long time, or the service is completely disabled on it automatic update, your computer may not have new trusted root certificates (TrustedRootCA). We recommend updating the system: install Latest updates security, in the case of Windows 7, be sure to install SP1 () and time zone updates ().

You can manually update root certificates according to the article: (we also recommend this, this will prevent the interception of your HTTPs traffic and a number of other problems).

Disable QUIC protocol support

Check to see if protocol support is enabled in Chrome QUIC(Quick UDP Internet Connections). The QUIC protocol allows you to open a connection much faster and negotiate all TLS (HTTPs) parameters when connecting to a site. However, in some cases it can cause problems with SSL connections. Try disabling QUIC:

Go to page: chrome://flags/#enable-quic;
Find the option Experimental QUIC protocol;
Change the Default option to Disabled;
Restart Chrome.

Enable support for TLS and SSL protocols

And the very last point - most likely to solve the problem you will only need to enable support for older versions of the TLS and SSL protocols. In most cases, it will be the most effective, but I intentionally moved it to the end of the article. I'll explain why.

Old versions of the TLS and SSL protocols are disabled not due to the simple whim of the developers, but due to the presence large quantity vulnerabilities that allow attackers to intercept your data in HTTPS traffic and even modify it. Thoughtlessly enabling old protocols significantly reduces your security on the Internet, so you should resort to this method as a last resort if all else fails.

Modern browsers and operating systems have long abandoned support for outdated and vulnerable SSL/TLS protocols (SSL 2.0, SSL 3.0 and TLS 1.1). TLS 1.2 and TLS 1.3 are now considered standard

If the site side uses a lower version of the SSL/TLS protocol than is supported by the client/browser, the user sees an error establishing a secure connection.

To enable older versions of the SSL/TLS protocols (again, this is not secure):

If all the methods discussed above did not help get rid of the “This site cannot provide a secure connection” error, also try:

General theory: The extension of the HTTP data transfer protocol that supports encryption of this data - HTTPS - is not itself an encryption protocol. Cryptographic protocols – SSL or TLS – are responsible for encryption.

However, not all yoghurts are equally useful: SSL is completely outdated, TLS version 1.0 is also outdated, so today it is recommended to use only TLS versions 1.1 or 1.2. By the way, the latest version of the HTTPS specification, adopted back in 2000, is called HTTP over TLS; there is almost no mention of SSL there.

But this is just a theory, in practice, TLS 1.2 is still supported only on a limited number of sites, with TLS 1.1 it is already noticeably better, but also not everywhere. The problem of supporting modern versions of TLS is also present on the client side, more on that later.

So, in order to use on your computer only the latest versions of the current cryptographic protocol (Come on, kids, remind me what it’s called? That’s right, TLS! And what version? That’s right, no lower than 1.1), you need to do a number of ridiculous gestures . Why? That's right, because no one will enable TLS 1.1/1.2 on our computer for us. For us, they will only enable the Windows “authenticity” check and stuff a bunch of “garbage” into startup. However, I digress.

Lyrical digression: I am sincerely convinced (and this conviction is confirmed by practice) that 90% of computer users could still use Windows 3.11 (there was such an OS in the early 90s), or, in extreme cases, Windows 98 SE - “writing machine" and the browser do not require anything else, so that they do not lie to us about new, even more improved interfaces and other little things of "revolutionary" new versions of the OS.

It is also true that modern technologies There is no way to attach security-related issues to outdated operating systems. Not because this is impossible in principle, but because their manufacturer did not do this, just as he did not do anything to enable them to be screwed on third party manufacturers BY. Therefore, all operating systems of the family Windows versions below XP (and even that in the foreseeable future), alas, are hopelessly outdated in terms of network security.

Let's finish with the lyrics here: all the following arguments will be based on the fact that Windows XP or later (Vista, 7 or 8) is used. And on the fact that we ourselves are not at all evil Pinocchios, and therefore we promptly install all the required updates and “patches” on the operating system we use.

So, first we should enable support for TLS 1.1 and TLS 1.2 and disable SSL and TLS 1.0 at the OS level, for which the Microsoft TLS/SSL Security Provider (schannel.dll) is responsible. What will this give us? Here's what: all programs that do not have their own TLS support module, but use the system one, will use the latest versions of TLS.

This is the theory that support is configured this way current versions TLS, including Internet browser Explorer. In fact, even him latest version for Windows XP - eighth - does not support TLS versions higher than 1.0. Under Windows Vista it supports, but under Windows XP it does not and, moreover, ignores the ban on using TLS 1.0. How so? The question is for Microsoft, not for me, we will still do what is required of us according to the manufacturer’s instructions.

And we do the following: we go to the registry at the address
HKLM\SYSTEM\CurrentControlSet\Control\Se curityProviders\SCHANNEL\Protocols, find the PCT 1.0, SSL 2.0, SSL 3.0 and TLS 1.0 sections there, in each of them - the Client and Server subsections, and create the DisabledByDefault keys in them (type - DWORD ), to which we assign the value 1 (one).

Then we find the TLS 1.1 and TLS 1.2 sections there and similarly create the above-mentioned key in them, but assign a different value to it - 0 (zero). There we also disable weak encryption and hashing algorithms RC2, RC4, DES, MD4 and MD5 and also prohibit installing secure connections without encryption (yes, this also happens... in someone's unhealthy fantasies), leaving only relatively strong Triple DES and SHA.

Since I am frankly lazy to describe how, what and where to change, below will be the contents of the .reg file that makes the corresponding changes to the registry. You need to carefully copy all this content to the clipboard, create a new text file, paste the content there, save this file with the .reg extension and run it, and then reboot.

If it happened that after a reboot problems appeared with network connection, the same operation will need to be done with the next file - it deletes all the changes we made from the registry, after which (that's right, children) it will reboot again. If the registry does not find any values at all in the registry section we have damaged, the OS will re-create them at boot time with default values.

Advanced users can, instead of completely rolling back changes, play around with enabling and disabling individual protocols and algorithms by editing the first of the files. Note to the hostess: if you use a corporate network to connect to the Internet the local network, and especially with the domain, then problems are likely, and it is recommended to look for ways to solve them while drinking a bottle of beer with the network administrator;)

Also note: Chrome browsers, Firefox, Opera and Safari, i.e. all that are not based on the Internet Explorer engine use their own SSL and TLS support modules, and therefore do not depend on the settings we discussed. But this does not mean that they can be neglected (in the sense of settings). But we’ll talk about the settings of the browsers themselves next time.

Enable TLS 1.1 and 1.2, disable SSL and TLS 1.0:

"Enabled"=dword:00000000

"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

"DisabledByDefault"=dword:00000001

"DisabledByDefault"=dword:00000000

"AllowInsecureRenegoClients"=dword:00000 000
"AllowInsecureRenegoServers"=dword:00000 000

"Enabled"=dword:00000000

Is everything broken? We delete the changes made:

Windows Registry Editor Version 5.00

[-HKEY_LOCAL_MACHINE\SYSTEM\CurrentContr olSet\Control\SecurityProviders\SCHANNEL]

Google, Microsoft and Mozilla have announced the timing of the complete end of support for the RC4 encryption algorithm.

With the growing threat of cyber attacks on RC4, this algorithm began to rapidly lose its reliability, and leading browser vendors decided to abandon it completely - at the end of January or beginning of February.

According to Richard Barnes of Mozilla, support for RC4 in Firefox will be removed with the release of version 44, scheduled for January 26th. "Disabling RC4 will mean that Firefox will no longer be able to connect to servers that require RC4," a company spokesperson explained on its developer forum. “The data we have shows that such servers are few and far between, but they still exist, although Firefox users rarely access them.”

Google's Adam Langley said the corresponding release of Chrome will be available to the general public in January or February. He did not specify the date, only said that HTTPS servers using exclusively RC4 would be disabled. “When Chrome establishes an HTTPS connection, it must do everything possible to ensure its security,” Langley noted in a dedicated newsletter on [email protected]. “Currently, using RC4 in HTTPS connections does not meet these requirements, so we plan to disable RC4 support in a future release of Chrome.”

Currently, both stable and beta versions of Firefox can use RC4 without restrictions, but in fact they only use it for 0.08 and 0.05% of connections, respectively. For Chrome, this figure is slightly higher - 0.13%. "To continue operating, the operators of the respective servers will likely only have to change the configuration slightly to switch to a more secure cipher suite," Langley said.

Microsoft announced the end of support for the outdated algorithm in products Microsoft Edge and IE 11; support will be disabled by default early next year. "Microsoft Edge and Internet Explorer 11 use RC4 only when downgrading from TLS protocol 1.2 or 1.1 before TLS 1.0,” explained David Walp, senior project manager for Microsoft Edge. - Rollback to TLS 1.0 using RC4 most often occurs by mistake, but such a situation, while innocent, is indistinguishable from a man-in-the-middle attack. For this reason, at the beginning of 2016, RC4 will be disabled by default for all users of Microsoft Edge and Internet Explorer under Windows 7, Windows 8.1 and Windows 10.

For more than a decade, researchers have lamented the imperfections of RC4, pointing to the possibility of selecting random values used to create ciphertexts using this algorithm. Given a certain amount of time, computing power, and access to a certain number of TLS requests, decryption will not be difficult for an attacker.

In 2013, research conducted by Daniel J. Bernstein at the University of Illinois allowed him to create a practical attack against a known vulnerability in RC4 to compromise a TLS session. This was one of the first such experiments to be made public.

Last July, Belgian researchers attacked RC4, allowing it to intercept a victim's cookie and decrypt it in much less time than previously thought possible.