When I try to access https://www.plus.net/ with Firefox on Fedora I get SSL_ERROR_NO_CYPHER_OVERLAP. This doesn’t happen on Windows (Fedora 35/Windows 11, Firefox 97 in both cases; SSL3 and TLS settings in about:config are identical). Why is this the case? A similar error was reported on Get Support | Mozilla Support but with an older version of Firefox (86). In that case the user downloaded the version direct from Mozilla and that worked - the implication being that there was an issue with the Fedora version of Firefox. I have found that the site mentioned in that post now works. I have not attempted to use the vanilla Mozilla version of Firefox so I can’t verify if that works on plus.net. What is potentially different between the Fedora and Mozilla versions and can it be fixed, or what do i ask plus.net to change (and why)?
There are two levels here - Firefox (and other major browsers) have removed support for TLS1.0 and TLS1.1 and it’s possible in Firefox (for not much longer!) to allow those protocols, but the same is also the case for Fedora itself.
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
Obviously, the ideal thing to do is upgrade your server because it serving an insecure TLS. If that’s not an option here is the other piece you need for this to work in Fedora: Changes/StrongCryptoSettings2 - Fedora Project Wiki
Lastly, I should note that Fedora 36 is moving to OpenSSLv3, so depending on how that goes, there’s a possibility that TLS 1.0/1.1 support may be dropped entirely. Keep in mind that this isn’t specific to Fedora, but all operating systems and browsers have deprecated support for these protocols.
That doesn’t really answer my question.
Firefox built by Mozilla works for the plus.net site (I have now tested it on Fe
dora). Firefox built by Fedora does not. What is the difference? How can I ask
plus.net to change things if I don’t know what Fedora is doing differently?
As I said, the tls and ssl3 settings for both firefox versions are identical - there is something else going on. It’s not the OS - I can run the two versions of firefox at the same time and one works and the other does not.
I was looking at changing ISPs and initially I was going to reject plus.net simply because it appeared to be “insecure”. This is obviously not necessarily the case and I want to understand why I’m having these issues.
When you enter a website, your browser and the web server negotiate how to establish a secure connection (they negotiate cryptographic algorithms and protocols).
Your browser has a cipher suite with its preferences: key agreement, symmetric cipher, mode of operation, hash. The negotiation also includes the TLS version (although this is not the issue of this website).
The peferences are a matter of configuration of the browser: https://wiki.mozilla.org/Security/Server_Side_TLS *
To achieve high level of security, the default Fedora firefox is configured to not accept Old backward compatibility preferences (see the mozilla page, although it is not fully up to date). I assume Fedora-default Firefox uses “intermediate” by default. E.g., my torbrowser, which is also a firefox, is configured to accept a connection with plus.net (which is funny, because especially tor browser depends on strong crypto to fulfill its purpose :- ).
If I use my Fedora-default firefox, I have the same issue as you. If I use torbrowser to open http://plus.net/ it works but calls “Old backward compatibility” preferences (which seems enabled by default in torbrowser firefox). It negotiated ECDHE-RSA-AES256-GCM-SHA384 with TLS v1.2. These preferences are considered to no longer offer desirable security levels and so, a Firefox that is configured to not accept the old (and less secure) ciphersuites will reject.
The website above shows the three general configurations that can be used with Firefox.
Generally, ECDHE-RSA-AES256-GCM-SHA384 are secure algorithms and not outdated. But there may be different ECDHE-RSA-AES256-GCM-SHA384 preferences, with slight differences in the details. E.g., the “elliptic curves” among ECDHE (which is a protocol and no algorithm, to be precise :- ) preferences may vary, and this has a strong impact on security.
* formally, I should refer to https://wiki.mozilla.org/Security/Cipher_Suites but that is extremely outdated. The explanations of the server page above correspond to the client as well in this respect.
Apparently, not the Firefox crypto settings, but Fedora’s crypto settings play a role. There is the command “update-crypto-settings” where you can set the required strength of the crypto. On my system, the setting was: DEFAULT:HSHA1, and the site opened without problem.In order to get the current default, I renamed the /etc/crypto-policies folder and reinstalled crypto-policies, setting is now DEFAULT. The site no longer opens.
I assume you mean update-crypto-policies ? This is indeed related (it manages the SSL/TLS backends), but it is unlikely to be the origin for this issue because of the error message. Firefox manages it’s cipher suite preferences itself, you can adjust the cipher suite preferences in about:config (that’s an URL for firefox to change it’s configurations; but be careful with that!). Also, plus.net does not insist on sha1 (neither in the encryption nor does it use sha1 for RSA). Further, I can reproduce the problem with two different browsers (one works, one not) on the same Fedora.
Nevertheless, it is not the cipher selection itself that breaks the negotiation but some other related preference (at least on my “normal” Fedora firefox). As I won’t invest the time to exactly verify which one it is, I cannot exclude update-crypto-policies explicitly as an impact factor. As you indicated, firefox is bound to what SSL/TLS implementations offer. But at least on my machine, another browser is able to open the website with the same backends.
Yet, the question was not how to modify firefox to load plus.net but to answer why it does not work by default: on Fedora, the backwards compatibility to the preferred cipher suites of plus.net is disabled by default, which aims to increase security. I don’t know if the configuration that enables it on Windows is related to something of Windows or to the Firefox configuration (and how both interact). It’s indeed a good point of h.janssen that there are external factors, too. I neglected that.
Yes, of course update-crypto-policies, my error. For some reasons, the plus.net server requires the SHA1 signature algorithm offered by the web browser, and returns an error if it is not there. In DEFAULT crypto configuration, you are not able to get the certificates via the “openssl s_client” test method. The Fedora firefox is compiled to follow the Fedora configured crypto policies, the native Firefox takes it’s own.
Google chrome (and MS Edge for Linux) return, started from a terminal, a few SSL errors when entering the plus.net site, but load the site anyhow. If you follow the communication in Wireshark, it appears that Chrome starts the TLS handshake a second time, but with SHA1 added. Given the fact that a vast majority of sites opens in Fedora without problem, I think this as a wrong configuration of the plus.net server and not compliant with actual standards, somewhat remarkable for a provider (or just a reseller?)
I am also used to this error usually occurring because a server insists on SHA1 for hash, which is unfortunately still the case on several pages. However, in this one case I assume SHA1 is not the cause but just another potential symptom next to the no-cipher-overlap error: plus net accepts at least SHA386 (see my posts above) next to SHA1 (which seems to be the fallback option for chrome?). The incompatibility rises from something else, although the origin of both issues is likely to be the same. Yet, the outcome remains the same in either case: the website seems to only work if legacy cipher suites are enabled, which potentially decreases security.
As you said, a wrong server-side configuration is one possibility, a legacy configuration the other (although the latter can be seen as a manifestation of the former : ) Maybe, some of the changes made to TLS 1.2 in rfc8446 (which defines TLS 1.3 + introduces some changes to TLS 1.2) have not yet been implemented. Maybe it’s the constellation of ciphers/versions. However, the question has been answered 
And obviously, we are both curious about that topic
The authentication takes place after the negotiation. So, if the negotiation fails, the following will not take place at all.
Thanks. Sounds like a misconfigured server. Not a good advertisement for an ISP. I’m not going to move ISPs in the short term (more important things like holidays abroad coming up) so I’ll have to hope they’ve fixed the issue or take it up with them later.
Not that bad. There is a SSL Labs test site which provides a possibility to test the SSL quality of a website. Both my Fedora Apache in standard config and Plus end with rank A and pass all simulated browsers. So the only point to blame Plus is that they did not test Fedora 35, and they do not support TLSv1.3. Even OpenSSL1.1.1c passes, Fedora has version 1.1.1l and includes the algorithm tested but fails. It has to do with TLS1.2 and requirement of the Fedora-disabled SHA1 in signatures, but here ends my knowledge of this very complicated stuff…
I hope you can have nice holidays abroad despite the current geopolitical situation.
Thanks for that. Your work is much appreciated!
So my take on that is that plus.net needs to ALLOW SHA1 in the signatures rather than REQUIRE it.
Such automated tests are superficial and at the best a rough indication. They can only test what can be tested automatically and can only find what they explicitly are intended to look for (and cannot follow indications) - also they can only test what explicitly cannot be related to penetration tests for legal reasons (in automated scenarios, this already excludes much). This does not mean that your argument is wrong. But an automated SSL test should not be the foundation when determining the security of something.
This argument neglects that there is a reason for Fedora’s defaults 
They are not implemented just for fun. The related question is why have Fedora developers decided to not (or to no longer) accept some types of behavior/implementations (and which)? The answer to “which” lies in the cipher negotiation phase. SHA1 and TLS 1.2 are themselves not the problem because the website accepts negotiations to SHA386, and Fedora Firefox default still accepts TLS 1.2. Again, this does not automatically imply that this page is insecure.
The SHA1 in the signature is fine as this is just the fingerprint, the “cryptographic” hash in the signature is SHA256. Also, the verification of the certificate takes place before the cipher negotiation. So, if there would be an issue with it, the negotiation would not have been started at all.
However, to finally close the issue, I took some time to identify the cause.
I found out that any browser got a net_error -113 (not just firefox). This implies
// The client and server don't support a common SSL protocol version or
// cipher suite.
Because of that, Fedora Firefox now ends the connection because it does not implement current TLS 1.2 / 1.3 (more about that later). It seems that the page tries to negotiate from the beginning a SHA1-based cipher suite. In the current TLS 1.2/1.3 standards, this is only the last fall back option, a browser might assume that there are no further alternatives, or simply that the other side does not fulfill current standards if it begins with SHA1.
However, other browsers have the same issue but they do not end the connection after that but further try to establish a connection. After some tries, they manage it to do so.
So, the error is common among all browsers I tested (I added Falkon to the “testing store” we created in this thread : ). But some are less radical in enforcing the current standard, as it is still possible to find a common cipher suite after some tries (SHA1 is still fallback). Nevertheless, the outcome is an increased use of SHA1 whenever possible, which is no longer recommended.
However, why is this the case? There are two types of TLS 1.2, the older RFC 5246 / 6176, which are considered to be no longer sufficient, and the post-RFC 8446 TLS 1.2, which is considered appropriate. The latter does not contain new functions or algorithms (which is why it is still 1.2) but it tries to avoid some issues like SHA1 if possible.
My assumption is that the page implements only the older TLS 1.2 but not the post-RFC 8446 TLS 1.2. Only the latter is currently the standard. However, if your browser enforces the current post-RFC 8446 TLS 1.2, this is possible even if the web server does not: it just has to reject SHA1 in negotiations until something else is offered by the server. There are still secure cipher suites in the original standard, the major difference is just that SHA1 is now only legacy/fallback option. So, pre- and post-8446 TLS 1.2 can still establish a connection. But the latter would not lead to SHA1 (it is now just the last try if everything else does not work). This is only to offer it to legacy browsers that don’t support anything else. However, in this case, it is the server who tries to get SHA1.
Thus, if your browser enforces to not use SHA1, the connection is (at least from the cipher suite perspective) sufficiently secure, but it is your browser that has to enforce it. Fedora seems to insist that web servers fulfill the current TLS 1.2/1.3 standards (I assume to decrease the risk of ending up with SHA1; some connections/browser might accept it even if they could do better; as well as to enforce current standards). It might be added that the current RFC 8446 was passed in 2018.
@moz59 The signatures are fine Negotiations of cipher suites take only place if signatures have been successfully verified. These are two different processes.