Some feeds are unable to update: e.g. https://www.php.net/releases/feed.php https://merkurist.de/mainz/Newsfeed it is stated a network error with http-code 0. I think there is some problem with https traffic and the certificates used. I assume this problem is present in other applications.
There is already a new release, but I'm unsure if this has to be assigned to the webkit component
Thank you for the report. Julien is both the registered and currently active maintainer of this package, so assigning the bug to him.
Assignee: bugsquad => julien.moragny
Hello, thanks for the report. After some investigation, the issue seems to come from webkitgtk which doesn't like the certificate of those sites. I can reproduce with midori which also use webkitgtk.
so I assume we have some more applications which have or might have some problems in future
Yes, Epiphany can't open the two URLs given in comment 1 and show a message about a weak encryption.
I've checked the certificates: https://www.ssllabs.com/ssltest/analyze.html?d=php.net&s=185.85.0.29 except there is still support for tls 1.0/1.1 - I don't see why this connection is stated as weak
(In reply to Marc Krämer from comment #6) > I've checked the certificates: > https://www.ssllabs.com/ssltest/analyze.html?d=php.net&s=185.85.0.29 > > except there is still support for tls 1.0/1.1 - I don't see why this > connection is stated as weak Deprecating TLS 1.0 and TLS 1.1 RFC 8996 https://datatracker.ietf.org/doc/rfc8996/
CC: (none) => davidwhodgins
I know, but it supports TLS 1.2 - so there is no reason not to work. Many sites still allow TLS 1.0/1.1, e.g. for old android systems... It would be nice to have the support back - I'm monitoring changes on sites and push updates (e.g. php). If the monitoring is not working, just because the sites still use TLS 1.1 this is not acceptable.
I've asked someone to test https://www.php.net/releases/feed.php on debian. he used Epiphany 3.38.2, Webkitgtk 2.32.1 (which is quite the same). No warning on debian, everything works. Do we have a problem? Old/expired/missing certificate?
Ah, it tells the sites certificate uses a weak signature. Can we fix this? Or who is responsible for this. Firefox, chrome etc. do show these sites without complaining. And in lifera I'm not able to accept the weak certificate.
what are we going to do about this?! Open upstream bug?
URL: (none) => https://github.com/lwindolf/liferea/issues/1013
from liferea bug tracker Do you use Fedora Linux? If yes you have to change the crypto policy to legacy, long story short, some old/unsecure protocols are not allowed anymore. Check current policy: update-crypto-policies --show It probably returns DEFAULT. Set policy to LEGACY: update-crypto-policies --set LEGACY and restart system more info: https://fedoraproject.org/wiki/Changes/CryptoPolicy https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
I can confirm after changing this setting liferea works again. Is this really the way to do it? Why did we change this?
It changed as when crypto-policies was built for Mageia 8 it was based on what was provided upstream at https://gitlab.com/redhat-crypto/fedora-crypto-policies
from users point of view this is not what is expected: Firefox, chromium, ... all work as expected (no warning etc), only some applications like epiphany and liferea consider this as weak. For the user (like me) this looks like a fault, not like a "feature"
so who is it to blame for this? And what should be do? I don't think we can force every site to follow our default security rule.
It isn't a cert problem or a security rule problem. The cert is considered valid for both sites in firefox, but not liferea, epiphany or midori on the same Mageia installation. The problem is either a bug in code common to liferea, epiphany and midori, or a lib they all use such as one from webkit2 that firefox and thunderbird do not use or do not use the same way. https://www.php.net/releases/feed.php opens somewhat in firefox which detects an atom rss feed, and opens the "open with ..." dialog as firefox does not handle rss feeds. Note that noscript must be disabled for that site. It works in thunderbird which has a built in rss reader. In liferea, epiphany and midori, it gives the false insecure connection method. Firefox shows the cert is secure, on the same Mageia installation. https://merkurist.de/mainz/Newsfeed opens ok in firefox and thunderbird. It also gives the false insecure connection message in liferea, epiphany and midori. Workaround for now is to use a different rss reader such as thunderbird until the exact problem can be located and fixed. As to what the default security rules are, that's controlled by Mozilla, Google, and Microsoft. Julien, do the above test results help narrow down the problem?
Increasing the severity since a major feature is not working.
Severity: normal => major
The signature of the root-ca (Certum CA) is SHA1withRSA Default policy is "Signature algorithms: with SHA-256 hash or better (not DSA)" My assumption is that not the full chain is signed with SHA-256, so the connection fails. But this is just a guess - I don't see other changes between default and legacy policy which may lead to a protocol error. nmap (nmap --script ssl-enum-ciphers -p 443 php.net) shows the following errors: Key exchange (dh 2048) of lower strength than certificate key Key exchange (ecdh_x25519) of lower strength than certificate key
For https://www.php.net/releases/feed.php cert for *.php.net has a sha-256 sig using a 4096bit rsa key That cert is signed by Certum Domain Validation CA sha2 with a sha-256 sig using a 2048 bit rsa key That cert is signed by Certum Trusted Network CA with a sha-256 sig using a 2048 bit rsa key for https://merkurist.de/mainz/Newsfeed cert for *.merkurist.de has a sha-256 sig using a 2048bit rsa key That cert is signed by Certum Domain Validation CA SHA2 with a sha-256 sig using a 2048 bit rsa key That cert is signed by Certum Trusted Network CA using a sha-256 sig with a 2048 bit rsa key
Hello, sorry for the delay (holidays) and thanks for finding the root(s) of the problem. To summarize: - a component (libsoup probably) used in liferea follow the system crypto policy when negociating SSL/TLS connections - the system crypto policy has been tightened for mga8 and later - as a result some website/rss with "weak" encryption cannot be connected with anymore - in parallel, liferea displays an erroneous message when an ssl connection fails At this stage, I don't know what we could do. Weakening the crypto polices (to LEGACY or FEDORA32 [1]) would have to be brought to the dev ML (or council?) and will probably be rejected. I doubt upstre [1] e.g. sudo update-crypto-policies --set DEFAULT:FEDORA32 .
To complete the previous message (fat finger and all that). I doubt upstream would want to implement a management of crypto policies inside liferea and even so, it won't be soon or in stable release. So, to my knowledge, we are stuck. Regarding the erroneous message, a pull request has been sent and we can provide an update with the patch if/when it's accepted. regards Julien
From what I can see, it's a bug. With the crypto policy set to default the sites work in thunderbird but not in liferea, epiphany and midori. So the workaround for now is to use thunderbird, but it should be working in the other apps too.
Note that changing the setting from default to legacy is not an option. If it were done, it would only affect new installs with online media included as existing settings would not be altered.
@Dave: maybe we should (?) alter settings in post install... For me changing the setting worked - at least this has to be added to the errata - but I'd like to get a cleaner solution another option could be to revert the tightend crypto settings in general
It could be done, with the old settings saved as a .rpmsave file. Reducing the security of all of our users for the few impacted by this problem though, is not something that would be acceptable.
@Dave: what do you suggest as solution? If I don't misunderstand, this setting affects some applications, and some system services (wget?, java?). But all common browsers still think the old "unsecure" setting is quite good enough. With the current setting we are telling, epiphany and others are no good browsers since the are not able to show websites, all others show without complaining. And if you start epiphany/lifera on debian everything works - so we have the impression mageia is not working correct.
The sites involved work in thunderbird, but not liferea, epiphany, or midori. That shows it is not a cert or nss problem, but is due to application problems. liferea is working with other sites such as ... $ liferea https://seclists.org/rss/oss-sec.rss That shows it isn't a problem with all cert handling, just something unique to those sites. liferea works if the nss cert setting is changed from default to legacy. That shows the problem can be narrowed down to something in how liferea (and the other applications impacted) are using nss to check certificates. We need to identify what is causing those specific sites to fail and fix it. Some lib used by liferea, epiphany, and midori likely has something like a comparison checking for "greater than" when it should be "greater than or equal to", or vice-versa. The lib or embedded code used in thunderbird for the same functionality has the correct code. That's my best guess at this point. Lowering the security impacts all encrypted connections, such as online banking etc., making man in the middle attacks slightly easier to perform (not easy, just slightly easier). Just because the browsers such as firefox will work with the lower security settings allowed, doesn't mean it's a good idea for everyone to use all of the time. Encrypted connection failures are a pain to debug. I don't have the skill or enough detailed knowledge of how applications handle certificates to get further in identifying the cause. Adding packagers team to cc list, as I have no idea which specific package has the problem. Hopefully someone more familiar with the details of how certs are handled will be able to spot the problem code.
CC: (none) => pkg-bugs
no change needed anymore
Status: NEW => RESOLVEDResolution: (none) => OLD