Bug 1913098

The bug is on the server side. The server rejects the client hello from OpenSSL and NSS if it does not enable RSA-SHA1 signature algorithm. Interestingly enough the RSA-SHA256 is then apparently actually used. I do not think we can do much with it on the crypto-policies side.

It would be interesting to investigate why the gnutls client hello is not rejected. It could be that RSA-SHA1 is sent in the signature algorithm extension even with the DEFAULT Fedora 33 policy which would be incorrect.

As for the "better diagnostic" - there is basically no way how for this issue we could provide better diagnostic as there is no information in the alert that the server sends when it rejects the connection.

I do not think we would ever be able to disable obsolete and weak algorithms and protocol versions if the requirements would be as such.

Hmm, okay. Can you share how you figured that out? I'm a system admin and generally consider myself pretty well-versed on diagnosing SSL/TLS issues, but was stumped on this one. If I can say "here's what's wrong and here's how to show it" I can file a bug with Juniper.

I've just set the policy to DEFAULT:FEDORA32 and tried making the opensslcnf.conf file as close as possible to the Fedora 33 DEFAULT opensslcnf.conf. And the smallest change that needs to be done to enable openssl s_client to connect is to add RSA+SHA1 at the end of the SignatureAlgorithms list. Then, because the actual peer signing digest selected by the server is SHA256, it is obvious that the server just incorrectly rejects the client hello regardless of the RSA+SHA256 being present even in the umodified Fedora 33 DEFAULT policy.

Dug into this some more, and I think I see the source of the problem. The site is including extra certs in its chain, including the root that is an old RSA+SHA1-signed cert (there are still quite a few RSA+SHA1 certs in the default trust store on Fedora 33). They actually don't need to include that cert, both since it is the root (and is either in the trust store or not trusted on any client), and because there's another trust path that doesn't even require this cert.

I'm guessing that the clients/libraries that work must allow more algorithms in the negotiation (maybe they don't accept certs signed with them though?) for better compatibility. And then since there's a trust path that doesn't need the RSA+SHA1 path, they don't fail? I don't know if there's a way to get OpenSSL or Firefox to work like that, at least from the crypto policy level.

Hmm, well in Firefox, trusted certs (those in the root store) aren't supposed to have their signature checked. Being a trusted cert implies that the cert is implicitly valid. I ran into an NSS issue with the NSS libpkix library, where in some conditions it would check the signature of the root cert when it shouldn't have (OCSP processing). Firefox has it's own cert processing library and maybe it checks the root cert signature. The other question is is there a path where there's a RSA+SHA1 intermediate certificate that's causing problems.

In the traditional cert processing in NSS, when there are multiple path, it prefers that most recent unexpired certificate to continue down the patch. If that path is invalid, the cert check fails. In NSS libpkix processing, the signature is part of the choice on whether or not a particular patch is valid (and picks the first valid patch that meets all the cert processing criteria). I don't know how the firefox cert processing works or how openssl works.

Bob, please note that this is a server side problem. The server rejects the hello when there is no RSA+SHA1 in the signature algorithms. It does not get to the point where the client would check the chain at all. At least that's the case when openssl connect to the server.

I suppose it could be solved on the server side easily just by dropping the sha1 signed root cert from the chain it sends to the client. As there is no point in sending the root cert to the client anyway.

I'm trying to see if I can get to the right people at Juniper to look at this (not so far).

But I'm not sure if the RSA+SHA1 cert is the whole problem or not. It definitely appears to be for OpenSSL, but not sure about Firefox and other clients that fail. Obviously there's some inconsistency, since some clients work just fine. Either the policy isn't being applied the same, or different clients interpret it differently. For user experience, there may be some room for improvement along the "be generous in what you accept lines" - if allowing RSA+SHA1 in the negotiation but then erroring out later if it is actually required allows a better interoperability, that may be something to consider. I can only guess that gnutls (and others?) may be following that approach.

Or, if that's considered an unacceptable approach, then all clients need to fail in the same manner. Midori, Chromium, gnutls, and wget should behave the same as Firefox, curl, lynx, and openssl.

$ openssl s_client -connect support.juniper.net:443 -sigalgs RSA+SHA384:RSA+SHA1:RSA+SHA256  ->  connects, RSA+SHA256
(same for several permutations of the above list)

$ openssl s_client -connect support.juniper.net:443 -sigalgs RSA+SHA1:RSA+SHA256  ->  immediate SSL alert number 40
(same for RSA+SHA256:RSA+SHA384, RSA+SHA256:RSA+SHA1, RSA+SHA384:RSA+SHA256, RSA+SHA384:RSA+SHA1, RSA+SHA1:RSA+SHA384, RSA+SHA1:RSA+SHA256, RSA+SHA384, RSA+SHA256, RSA+SHA1)

All three are used in the certificates being sent back, and the server wants all three advertised,
even though there's a valid chain that uses just SHA-256&SHA-384.

---

Now, gnutls advertises all these three sigalgs, including RSA-SHA1, despite `insecure-sig = RSA-SHA1`:

$ gnutls-cli support.juniper.net -d4 2>&1 | grep SHA1
|<4>| EXT[0x55ff017007b0]: sent signature algo (2.1) RSA-SHA1
 - subject `CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB', issuer `CN=AAA Certificate Services,O=Comodo CA Limited,L=Salford,ST=Greater Manchester,C=GB', serial 0x01, RSA key 2048 bits, signed using RSA-SHA1 (broken!), activated `2004-01-01 00:00:00 UTC', expires `2028-12-31 23:59:59 UTC', pin-sha256="vRU+17BDT2iGsXvOi76E7TQMcTLXAqj0+jGPdW7L1vM="

Setting a needinfo on Daiki to inquire why gnutls still advertises RSA-SHA1.
Is that a concious decision to better interoperate with servers that otherwise wouldn't send unnecessary SHA-1 certs, like Chris suggests?

As Hubert Kario has commented off-ticket,
overadvertising sigalgs is an interoperability concern in its own,
as the server might then send a weaker/unsupported cert chain.

As, per https://gnutls.org/manual/html_node/Disabling-algorithms-and-protocols.html,
insecure-sig is used to mark the signature algorithm as insecure for any use,
we should consider ceasing to advertise them as well,
bringing the implementations closer to each other.


Turning the ticket into 'gnutls client advertises disabled signature algorithms'.

$ rpm -q gnutls
gnutls-3.6.15-1.fc33.x86_64
$ grep -i sha1 /etc/crypto-policies/back-ends/gnutls.config
insecure-hash = SHA1
insecure-sig = RSA-SHA1
insecure-sig = DSA-SHA1
insecure-sig = ECDSA-SHA1
insecure-sig-for-cert = rsa-sha1
insecure-sig-for-cert = dsa-sha1
insecure-sig-for-cert = ecdsa-sha1
$ gnutls-cli support.juniper.net -d4 2>&1 | grep SHA1
--- 8< ---
|<4>| EXT[0x55e5d1c537b0]: sent signature algo (2.1) RSA-SHA1
|<4>| EXT[0x55e5d1c537b0]: sent signature algo (2.3) ECDSA-SHA1
--- 8< ---
(connection succeeds)

Expected results: SHA-1 sigalgs are not advertised, connection (sigh) fails.

Thanks everybody for digging in to the differences... that was part of my confusion in this.  It would be nice that, where practical (which of course not all things are), something called a "system-wide crypto policy" should work basically the same in all clients/libraries.

Also: I've opened multiple tickets with Juniper - supposedly IT is "investigating", but then I was asked if Chrome works (which it does, at least right now), so I don't know if they're going to change anything.  Sigh... I remember when they were a much smaller and more responsive company (and probably would have fixed their part in a day).

(In reply to Chris Adams from comment #10)
> Thanks everybody for digging in to the differences... that was part of my
> confusion in this.  It would be nice that, where practical (which of course
> not all things are), something called a "system-wide crypto policy" should
> work basically the same in all clients/libraries.

that's the idea, lack of consistency on gnutls side (and all the applications that use it) was an oversight on our part

unfortunately, this behaviour requires the software in question to load a distribution-provided configuration file and then not override the provided defaults, which Chrome won't do

Just FYI: I never heard anything more from Juniper, but I did just notice that they fixed their SSL certs (trimmed the chain to exclude the unneeded RSA+SHA1 root... still sending the unneeded RSA+SHA384 root, but whatever), so I can reach it from Firefox on Fedora 33 now. And yeah, I fully understand (and support) that Chrome is not covered by Fedora at all... unfortunate fact though that "does it work in Chrome... then we're done" is how most (non-Fedora) sites operate these days.

Leaving the BZ open for gnutls update to match policy.

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle.
Changing version to 36.

This bug has been idle for quite a while, and I guess will soon be marked for closure as Fedora 36 reaches end of life. I have no way to test any change (as the server I had the original issue with did finally fix their issue), and I don't know if gnutls behavior has been (or will be changed). Is there any reason to keep this open?

> I don't know if gnutls behavior has been (or will be changed)

I think it has been, in https://gitlab.com/gnutls/gnutls/-/merge_requests/1447

Ahh good. Sounds like they got testing covered too, so I'm going to close this bug.