Bug 29184

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?

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 => RESOLVED
Resolution: (none) => OLD