Forgot to mention: in regards of FIPS compliance we only care about codepaths with OpenSSL backend.

Some additional remarks: 

(1) In SSSD source code SHA1 is used to form certificate id. In RFC6960 I can't find any explicit restrictions on hash functions that can be used to form those fields.
https://cryptography.io/en/latest/x509/ocsp/ says: "A HashAlgorithm instance. For OCSP only SHA1, SHA224, SHA256, SHA384, and SHA512 are allowed." But I don't know if this is reliable source of information.
In case of uncertainty we could enforce hash other than SHA1 in FIPS mode only.

(2) But RFC says something about hash functions used for signatures:
 * Clients ... SHALL be capable of processing responses signed using RSA with SHA-256
 * Clients SHOULD ... also be capable of processing responses signed using RSA with SHA-1
 * Clients MAY support other algorithms.

(Btw, from my point of view, it means that OCSP responder definitely must be capable to work with SHA-256. So I think it is safe to replace SHA1 as in (1) with SHA-256)

What I worry about here: validation of response signed with SHA-1 might fail in FIPS mode.

As a client, SSSD doesn't have direct control of signature used to sign response. But there is "4.4.7. Preferred Signature Algorithms" extension. May be it might make sense to use this extension to indicate SSSD would prefer SHA-1 not to be used.

(In reply to Alexey Tikhonov from comment #2)
> What I worry about here: validation of response signed with SHA-1 might fail
> in FIPS mode.


Comment from Tomáš Mráz about current OpenSSL impl:

"The SHA1 in the FIPS mode is disabled only for use withing the TLS protocol, not for certificate, CRL, or OCSP signatures.
Another question is whether this is really FIPS compliant. It isn't as SHA1 is not allowed to be used for signatures anymore. However especially for OCSP disabling the SHA1 support would break too much stuff I am afraid."


So it seems like:
 - this bug is not urgent, as this stuff would not break anything right now;
 - still I think it is good to do, as sha1 will be deprecated everywhere eventually.

Upstream ticket:
https://pagure.io/SSSD/sssd/issue/4032

* master:
 * ad9dd137e2f8ad46cfb921fb7bf137fb3442692e
 * a97ec73e04b6347bb6aa9794f5ea9f4ca3424801
 * ba01db0dcd43ef1b2079d9cc209534d45a3e938d

Should not this have internal target release 8.2.0 as the rest of the FIPS related patches? Alexey, do you know?

In any case I am giving devel ack because we do have patches.

How can I test this?

This is fixed with the implementation of ocsp_dgst right?

Does this require special configuration on the OCSP server to test?  If so, is this easily accomplished in IPA?

What exactly does setting this do?  Limit which types of certificates can be used to only those that can be verified with the hash specified?

(In reply to Scott Poore from comment #9)
> How can I test this?
> 
> This is fixed with the implementation of ocsp_dgst right?

Yes, while adding the ocsp_dgst option the default was changed to sha256 as well.

> 
> Does this require special configuration on the OCSP server to test?  If so,
> is this easily accomplished in IPA?

No, afaik no special configuration is needed on the server side. The client will use the specified hash function and expects that the server replies with the same. In my testing IPA was able to reply with all supported hash functions listed in the sssd.conf man page.

> 
> What exactly does setting this do?  Limit which types of certificates can be
> used to only those that can be verified with the hash specified?

No, the OCSP request does not contain the full certificate but a certificate ID is generated with the given hash function. Look for CertID in https://tools.ietf.org/html/rfc6960 if you want to know the details.

HTH

bye,
Sumit

So can verify simply by checking for the p11_child.log file after setting ocsp_dgst and attempting to authenticate?

I can see messages when I set it to the different digests:

[root@client ~]# grep "Using.*for OCSP" /var/log/sssd/p11_child.log
...
(Wed Jan 15 19:21:46 2020) [[sssd[p11_child[357]]]] [parse_cert_verify_opts] (0x4000): Using sha256 for OCSP.
(Wed Jan 15 19:22:16 2020) [[sssd[p11_child[684]]]] [parse_cert_verify_opts] (0x4000): Using sha384 for OCSP.
(Wed Jan 15 19:22:45 2020) [[sssd[p11_child[1043]]]] [parse_cert_verify_opts] (0x4000): Using sha512 for OCSP.
(Wed Jan 15 19:23:14 2020) [[sssd[p11_child[1375]]]] [parse_cert_verify_opts] (0x4000): Using sha1 for OCSP.

[root@client ~]# grep Unsupported.*OCSP /var/log/sssd/p11_child.log
(Wed Jan 15 18:58:43 2020) [[sssd[p11_child[30598]]]] [parse_cert_verify_opts] (0x0020): Unsupported digest for OCSP [bad256], using default sha256.

So, can I use that to test/verify?

For what it worth:

(1) I would not rely on debug logs of software being tested. Checking OCSP server logs or tcpdump would make much more sense (if possible, of course).

(2) Please keep in mind, the main purpose of this ticket is to assure SHA-1 is not used by default on a RHEL8 machine with FIPS mode enabled. Testing that new feature (digest configuration) works as expected is also useful, of course.

(In reply to Alexey Tikhonov from comment #12)
> For what it worth:
> 
> (1) I would not rely on debug logs of software being tested. Checking OCSP
> server logs or tcpdump would make much more sense (if possible, of course).

I need to confirm that I can run tcpdump in the background with my pytest automation.  I think I can but, I haven't tried.

Would you be able to help me with how to use tcpdump to filter out that information?

I captured packets of a manual ocsp lookup and can look at it with wireshark but, I'm not sure how to filter out and process the packets to get the hashing algorithm used from tcpdump or tshark command lines.

When I look at it in wireshark I see the OCSP Request (and Response) and I can see hashAlgorithm listed but, I'm not sure how to interpret it.  Attaching file with screen grab to show that.


> 
> (2) Please keep in mind, the main purpose of this ticket is to assure SHA-1
> is not used by default on a RHEL8 machine with FIPS mode enabled. Testing
> that new feature (digest configuration) works as expected is also useful, of
> course.

Once I figure out the best way to confirm hash used, I'll be sure to cover that test case.

Thanks

Created attachment 1652885 [details]
wireshark parse of ocsp request capture

Verified.

Version ::

sssd-2.2.3-11.el8.x86_64

Results ::

# grep -r ocsp_dgst /etc/sssd/

# CFG=/etc/sssd/conf.d/sssd_ocsp.conf

# cat $CFG
cat: /etc/sssd/conf.d/sssd_ocsp.conf: No such file or directory

#####################################
# 1. test default
#####################################

# cat > $CFG <<EOF
> [sssd]
> EOF

# chmod 600 $CFG

# systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd

# tshark -s0 -w /tmp/ocsp_dgst.default.pcap > /dev/null 2>&1 &
[1] 31380

# su - ipauser1 -c 'su - ipauser1 -c whoami'
PIN for sctest (OpenSC Card): 
ipauser1

# killall tshark

# tshark -r /tmp/ocsp_dgst.default.pcap -V ocsp | grep hashAlgorithm.*256
Running as user "root" and group "root". This could be dangerous.
                    hashAlgorithm (sha256)
                            hashAlgorithm (sha256)
^^^ PASS

#####################################
# 2. test specifying sha256
#####################################

# cat > $CFG <<EOF
> [sssd]
> certificate_verification = ocsp_dgst=sha256
> EOF

# systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd

# tshark -s0 -w /tmp/ocsp_dgst.sha256.pcap > /dev/null 2>&1 &
[1] 31929

# su - ipauser1 -c 'su - ipauser1 -c whoami'
PIN for sctest (OpenSC Card): 
ipauser1

# killall tshark

# tshark -r /tmp/ocsp_dgst.sha256.pcap -V ocsp | grep hashAlgorithm.*256
Running as user "root" and group "root". This could be dangerous.
                    hashAlgorithm (sha256)
                            hashAlgorithm (sha256)
^^^ PASS

#####################################
# 3. test specifying sha384
#####################################

# cat > $CFG <<EOF
> [sssd]
> certificate_verification = ocsp_dgst=sha384
> EOF

# systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd

# tshark -s0 -w /tmp/ocsp_dgst.sha384.pcap > /dev/null 2>&1 &
[1] 32039

# su - ipauser1 -c 'su - ipauser1 -c whoami'
PIN for sctest (OpenSC Card): 
ipauser1

# killall tshark

# tshark -r /tmp/ocsp_dgst.sha384.pcap -V ocsp | grep hashAlgorithm.*384
Running as user "root" and group "root". This could be dangerous.
                    hashAlgorithm (sha384)
                            hashAlgorithm (sha384)

^^^ PASS

#####################################
# 4. test specifying sha512
#####################################

# cat > $CFG <<EOF
> [sssd]
> certificate_verification = ocsp_dgst=sha512
> EOF

# systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd

# tshark -s0 -w /tmp/ocsp_dgst.sha512.pcap > /dev/null 2>&1 &
[1] 31818

# su - ipauser1 -c 'su - ipauser1 -c whoami'
PIN for sctest (OpenSC Card): 
ipauser1

# killall tshark

# tshark -r /tmp/ocsp_dgst.sha512.pcap -V ocsp | grep hashAlgorithm.*512
Running as user "root" and group "root". This could be dangerous.
                    hashAlgorithm (sha512)
                            hashAlgorithm (sha512)

^^^ PASS

#####################################
# 5. test specifying sha1
#####################################


# cat > $CFG <<EOF
> [sssd]
> certificate_verification = ocsp_dgst=sha1
> EOF

# systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd

# tshark -s0 -w /tmp/ocsp_dgst.sha1.pcap > /dev/null 2>&1 &
[1] 32149

# su - ipauser1 -c 'su - ipauser1 -c whoami'
PIN for sctest (OpenSC Card): 
ipauser1

# killall tshark

# tshark -r /tmp/ocsp_dgst.sha1.pcap -V ocsp | grep hashAlgorithm.*SHA-1
Running as user "root" and group "root". This could be dangerous.
                    hashAlgorithm (SHA-1)
                            hashAlgorithm (SHA-1)

^^^ PASS

#####################################
# 6. test specifying invalid hash algorithm
#####################################

# cat > $CFG <<EOF
> [sssd]
> certificate_verification = ocsp_dgst=bad256
> EOF

# systemctl stop sssd; rm -rf /var/lib/sss/{db,mc}/*; systemctl start sssd

# tshark -s0 -w /tmp/ocsp_dgst.default.pcap > /dev/null 2>&1 &
[1] 32262

# su - ipauser1 -c 'su - ipauser1 -c whoami'
PIN for sctest (OpenSC Card): 
ipauser1

# killall tshark

# tshark -r /tmp/ocsp_dgst.default.pcap -V ocsp | grep hashAlgorithm.*256
Running as user "root" and group "root". This could be dangerous.
                    hashAlgorithm (sha256)
                            hashAlgorithm (sha256)

^^^ PASS it should fall back to default if bad algorithm listed

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1863

@Alex -

Re you comment https://bugzilla.redhat.com/show_bug.cgi?id=1718478#c2

OCSP responders are NOT guaranteed to accept SHA2 algorithms, and depends on the deployment's configuration.  We have encountered an issue where an OCSP responder configured for only SHA1 will deny entry to a system when SHA256 is not enabled for a CA.  Looking thru the RFC, I don't see mention of a responder to be required to answer for all hash types.

I'm sure we're not the only ones noticing this change has broken PKI authentication, and it may be prudent to attempt a fallback back down to SHA1 if SHA2 fails.

Also, I've not been able to locate the language in FIPS140 that bans SHA1's use.  Could you please refer to this in the standards document?

(In reply to Karl Grindley from comment #20)
> @Alex -
> 
> Re you comment https://bugzilla.redhat.com/show_bug.cgi?id=1718478#c2
> 
> OCSP responders are NOT guaranteed to accept SHA2 algorithms, and depends on
> the deployment's configuration.  We have encountered an issue where an OCSP
> responder configured for only SHA1 will deny entry to a system when SHA256
> is not enabled for a CA.  Looking thru the RFC, I don't see mention of a
> responder to be required to answer for all hash types.
> 
> I'm sure we're not the only ones noticing this change has broken PKI
> authentication, and it may be prudent to attempt a fallback back down to
> SHA1 if SHA2 fails.
> 
> Also, I've not been able to locate the language in FIPS140 that bans SHA1's
> use.  Could you please refer to this in the standards document?

https://github.com/SSSD/sssd/pull/837#issuecomment-672847772

(In reply to Alexey Tikhonov from comment #21)
> (In reply to Karl Grindley from comment #20)
> > @Alex -
> > 
> > Re you comment https://bugzilla.redhat.com/show_bug.cgi?id=1718478#c2
> > 
> > OCSP responders are NOT guaranteed to accept SHA2 algorithms, and depends on
> > the deployment's configuration.  We have encountered an issue where an OCSP
> > responder configured for only SHA1 will deny entry to a system when SHA256
> > is not enabled for a CA.  Looking thru the RFC, I don't see mention of a
> > responder to be required to answer for all hash types.
> > 
> > I'm sure we're not the only ones noticing this change has broken PKI
> > authentication, and it may be prudent to attempt a fallback back down to
> > SHA1 if SHA2 fails.
> > 
> > Also, I've not been able to locate the language in FIPS140 that bans SHA1's
> > use.  Could you please refer to this in the standards document?
> 
> https://github.com/SSSD/sssd/pull/837#issuecomment-672847772

Alexey - can we kindly reopen this ticket to track?

(In reply to Karl Grindley from comment #22)
> > 
> > https://github.com/SSSD/sssd/pull/837#issuecomment-672847772
> 
> Alexey - can we kindly reopen this ticket to track?

We can't reopen this ticket but I opened new bz 1869683