Discourse inaccessibility for Google Chrome

Discourse may become inaccessible for the latest versions of the Chrome and IE browsers. The symptom is the following error message on the page

This webpage is not available
ERR_SSL_VERSION_OR_CIPHER_MISMATCH

The problem is due to the site using SSL certificate, which the version 3.0 of Chrome stopped supporting, this is the word on the Web

In some cases the following workaround may fix the problem for Chrome

1. Open chrome://flags
2. Look for "Minimum SSL/TLS version supported."
3. Choose SSLv3 Click on “Relaunch now” button at the bottom
4. Open your https page again
5. You will be redirected to a “Your connection is not private” page.
6. If you do not worry about this security issue click on the “Advanced” link.
7. Finally click on “Proceed to (unsafe)”

If this fails, use earlier Chrome version or another brand of browser, Mozilla Firefox is one example.

Also take this into account before updating your Chrome browser.

1 Like

Thanks, @blake can you look into this?

I have noticed some minor javascript failures (Chromium Version 41.0.2272.76 Ubuntu 15.04 (64-bit)) recently here on Discourse.

Scratch that, it was the popup blocker, which for some reason re-enabled itself.

This is weird because for me in Chrome 42 Linux, under the padlock icon, it says the connection is using TLS 1.2 which is state of the art.
Our TLS is handled by Cloudflare, so it might be that under some circumstances Cloudflare decides to use an older security layer for what it (perhaps mistakenly) identifies as an outdated device which only supports older SSL.

For most people the error seems to have something to do with Bitdefender SSL Scan, apparently Bitdefender inserts itself into the connection (a ‘consensual man in the middle attack’) and uses a strong encryption between itself and the webserver, but a weak encryption between itself and the web browser, which modern browsers refuse to accept. If it is the case of Bitdefender SSL Scan I would strongly recommend disabling SSL Scan. It might make sense if you’re using IE6 or something, but I would trust the security of a modern browser like Chrome even more than I would Bitdefender, all you gain by using SSL scan is having two points of vulnerability (the browser and bitdefender) instead of just one (the browser) so it only makes sense if your browser is completely retarded and insecure.

Umm, I just noticed, SuttaCentral is not using SSL at all, I have no padlock icon.

Well at the moment we’re still using the wikipedia security model - both http and https are supported.

In truth I see precious little reason to enforce HTTPS in the case where no data is sent to the server.

It is my understanding that certain parties (such as countries, corporations and coffee shops) have such a strong desire to eavesdrop or censor that they take the draconian measure of outright blocking HTTPs.
Clearly in some cases it is better if people behind such a firewall simply can’t connect at all - for example when payments are involved (although even then with two factor authentication having credentials stolen isn’t that bad).
It’s not clear to me the benefit of completely preventing insecure connections to SuttaCentral, especially since even with TLS an eavesdropping or censoring party can still see that a user is browsing the domain SuttaCentral.net and how many requests they are making. TLS cannot encrypt routing information because packets still need to tell routers where they’re going.

There are softer ways to defaultify HTTPS without absolutely enforcing it. For example, using rel=“canonical” to point the http pages to https. This should make google search results point to the https pages. It is also possible to use HSTS, this means that once a browser has successfully negotiated a HTTPS connection to SuttaCentral.net, it will then only use HTTPS in the future, in other words, if a browser can then it must.

I thought we were past this, and that it was implemented already, maybe I was confused. I’ve been wanting to use https for 2 years now, can we just do it already? Every major internet player is recommending that all sites use https, it is a ranking signature for Google, Mozilla is going to stop supporting http. The emerging standard for the web is http/2, and while this technically can support unencrypted traffic, the clients under development require encryption.

As far as I’m concerned the debate is over, and a good thing, too. https was first available on Netscape in 1994, and the web should have been encrypted since the beginning.

Moreover the strong recommendation is that websites should not serve mixed http/https. Let us please use https only for everything.

Okay, thanks, it seems we are all https now. Let’s monitor it and see if there are any problems.

now not only Discourse is blocked for Chrome but the main Suttacentral website as well

and both are for Opera too, which reports error 80

are there any indications of reduction in these websites traffic as of late?

I’m using Chromium, Chrome, and Firefox, and all are okay. Opera is not working, but it’s an ancient version, I haven’t updated it for years. Have you disabled BitDefender as per @blake’s advice earlier?

We have now upgraded our handling of SSL connections. The changes may take a while to propagate. Please let us know if you’re experiencing problems from, say, tomorrow.

1 Like

i don’t use any AV software, the only thing i have running which is theoretically able to block connection is Windows Firewall on two different machines connected to two different ISPs

but turning it off doesn’t help

i’ll monitor the connectivity in the coming days

Thanks, your help is really appreciated.

Currently, recent versions of Chrome are working for me on Linux and on a Window7 VM. I did have some things not working a few days ago, but it all seems fine at the moment.

And I’m now getting both SC and Discourse working fine on Opera, so it looks like our SSL problems will hopefully be over…

now i confirm accessibility with Opera and Chrome for me

let’s :pray: it stays that way