You can unselect "Always use a secure connection when logged in" in Special:Preferences.

I don't know whether WMF likes to set up an unsecure server...

@Aklapper https://meta.wikimedia.org/wiki/HTTPS#Disabling covers disabling it

there is not working
site is not accessible to readers for reading
to enter the settings you need to log in to your account, and the entrance to https and the https completely banned in some places, only http

even changing the checkbox, it works in enwiki, but does not work in ruwiki

I think this is a very good suggestion. Setting up an insecure domain allows us to enforce HTTPS on regular domains for all wiki projects without anyone complaining.

Still, I want to say that HTTPS everywhere is the future of the Internet. There is nothing wrong for wikimedia to enforce HTTPS. I am sorry, but it is the fault of your company to block HTTPS entirely. There are many HTTPS only websites, such as Google, Twitter, Facebook, Outlook, OneDrive, etc. If your company wants to monitor its employees, there are many alternatives. One of them is to upload browser's history, and Windows group policy allows administrators to disallow users to delete browsing history.

It was already suggested in T49832#494103

In T91044#1073432, @Sunpriat wrote:

even changing the checkbox, it works in enwiki, but does not work in ruwiki

This is probably because ruwiki has HTTP strict transport security enabled. The HTTP to HTTPS redirect happens on your browser automatically. You can disable HSTS by clearing your browser's cache.

@Chmarkine Can you do it after you are logged in ruwiki (not coming from another wiki) in firefox? If yes, how did you do it?

In T91044#1073432, @Sunpriat wrote:

there is not working
site is not accessible to readers for reading
to enter the settings you need to log in to your account, and the entrance to https and the https completely banned in some places, only http

even changing the checkbox, it works in enwiki, but does not work in ruwiki

In discussing this in depth, it's important to separate performance concerns (due to lack of proxycaching due to HTTPS, or a very slow browser/computer?), and complete inaccessibility due to the HTTPS protocol being blocked completely (or incompatible with older browsers).

The checkbox solution, as documented previously, does *not* work around the second case (complete lack of HTTPS) even today. If you do not have HTTPS access at all, you cannot log in. Therefore it was already the case that HTTPS was required for logged-in users, and the checkbox was a performance hack to drop HTTPS *after* the successful login process.

The only known browser we're protocol-incompatible with for HTTPS is IE6 on WindowsXP (as are most other major sites on the internet now, due to the SSLv3 POODLE issue - it's basically an invalid platform at this point).

The HSTS header now being sent is indeed the reason that the checkbox is now largely ineffective on ruwiki. Even with the checkbox, you hit the site over HTTPS during the login authentication itself, at which point you receive the HSTS header which instructs your browser to never connect to ruwiki insecurely again. As hinted at above, there are probably workarounds for this at the browser level (to disable/clear HSTS) and at the authentication level (by checking the box and using a different language domain for single-sign-on before switching back to ruwiki - but this will eventually not work once all languages are enforcing HTTPS).

This is an important security feature, and I don't think we're going to disable it over performance concerns. Generally speaking, my thoughts echo Chmarkine's re: "HTTPS everywhere is the future of the Internet", etc.

ok, "HTTPS everywhere is the future of the Internet". Mainstream - Wikipedia will only https. Safety reading free knowledge more important than their availability. Sorry to bother you.

Protest/rant closures are about as useful as protest reopenings. Should this be reopened?

Personally I'd be interested in knowing whether Sunpriat knows more examples of

some users do not have access to free knowledge due to technical problems with https from their side

beyond the known problem of IE6 on Win XP. What schools prohibit HTTPS? How to support caching proxies?

In T91044#1075999, @Nemo_bis wrote:

How to support caching proxies?

I don't think there's any easy way to support caching proxies. W3C acknowledged this in the document "Securing the Web":

Adopting "https://" has the side effect of disallowing shared HTTP caching [RFC7234]. Shared caching has a limited role on the Web today; [...] However, shared caching is still considered desirable by some (e.g., in limited networks); in some cases, it might be so desirable that networks require users to accept TLS Man-in-the-Middle -- which is a bad outcome for Web security overall.

Re: caching proxies: in limited, controlled environments like schools and corporations, where the entity also controls the browsers/devices, they can technically proxycache HTTPS. There are commercial solutions to do so which rely on, basically, installing a fake root certificate into the browsers/OSs, which their proxycache uses to generate fake SSL certs for the sites being proxied, etc.

Thanks! I added this information to https://meta.wikimedia.org/w/index.php?title=HTTPS&diff=11737316&oldid=11506187