Closed rptaylor closed 1 week ago
You may want to have a look at #2150, in particular this comment.
Does this mean that any certificate issued by any unverified self-signed certificate would be accepted with only a warning?
The documentation is misleading. It says:
Defines the CA verification level.
It really should say "define the trusted root CA verification level".
That is, if you have a fully verified chain, leading to a root CA found in the CA trust store (e.g., CA file or /etc/grid-security/certificates
), do you check the signature on the trusted root CA itself?
Validating the trusted root CA makes little sense to me: if an attacker is competent enough to modify your CA store, they're probably competent enough to correctly self-sign their malicious CA.
At best, it's a waste of CPU cycles. At worst, since root CAs still are permitted to be SHA-1 self-signed, it causes a failure as in #2150.
Hi Brian,
OK, I agree. Could you come up withe the appropriate verbiage to substitute for the existing text and the change will happen.
Andy
From: Brian P Bockelman @.> Sent: Saturday, August 24, 2024 8:26 AM To: xrootd/xrootd @.> Cc: Subscribed @.***> Subject: Re: [xrootd/xrootd] question about gsi -ca:verifyss option (Issue #2316)
BEWARE: This email originated outside of our organization. DO NOT CLICK links or attachments unless you recognize the sender and know the content is safe.
Does this mean that any certificate issued by any unverified self-signed certificate would be accepted with only a warning?
The documentation is misleading. It says:
Defines the CA verification level.
It really should say "define the trusted root CA verification level".
That is, if you have a fully verified chain, leading to a root CA found in the CA trust store (e.g., CA file or /etc/grid-security/certificates), do you check the signature on the trusted root CA itself?
Validating the trusted root CA makes little sense to me: if an attacker is competent enough to modify your CA store, they're probably competent enough to correctly self-sign their malicious CA.
At best, it's a waste of CPU cycles. At worst, since root CAs still are permitted to be SHA-1 self-signed, it causes a failure as in #2150https://github.com/xrootd/xrootd/issues/2150.
— Reply to this email directly, view it on GitHubhttps://github.com/xrootd/xrootd/issues/2316#issuecomment-2308430248, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAUIW52QBDXPLDEP2K3KAOTZTCQ23AVCNFSM6AAAAABNBA4WN6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBYGQZTAMRUHA. You are receiving this because you are subscribed to this thread.Message ID: @.***>
How about replacing this:
Defines the CA verification level: noverify do not verify; verifyss verify if self-signed, issuing a warning if not; verify always verify the CA in the chain, failing when not possible. Default is verifyss.
with
Defines the trusted root CA self-signature verification level. The trusted root CAs are those installed in the CA file or directory. Options are: noverify do not verify the self-signature; this is the default behavior in OpenSSL; verifyss verify the self-signature, issuing a warning if verification fails; verify verify the self-signature, failing authentication when the verification fails. Default is verifyss.
Looks good to me, I'll make the documentation change. Thanks Brian.
I see, thanks for clarifying what the verification is referring to.
Documentation has been updated.
Hello,
https://xrootd.slac.stanford.edu/doc/dev56/sec_config.htm#_Toc119617433
describes the -ca option:
I can understand only verifying self-signed certificates as those would be the trust anchor roots which are distributed in /etc/grid-security/certificates, but if the result of verification failure is only a warning, it seems that verifyss as the default option is insecure. Does this mean that any certificate issued by any unverified self-signed certificate would be accepted with only a warning?