RE: [RFE] Signing using SSL

[<rsbecker@nexbridge.com>]

On March 29, 2022 1:26 PM, Fabian Stelzer wrote:
>On 29.03.2022 11:44, rsbecker@nexbridge.com wrote:
>>On March 16, 2022 12:45 PM, I wrote:
>>>On March 16, 2022 12:27 PM, Fabian Stelzer wrote:
>>>>On 16.03.2022 10:34, rsbecker@nexbridge.com wrote:
>>>>>Following up on our IRC discussion on Monday, I have had a request
>>>>>to support signing git commits and tags with SSL certificates
>>>>>instead of SSH/GPG. The organization is heavily invested in SSL
>>>>>infrastructure, so they want to go down that path.
>>>>>
>>>>>The basic technique for doing this is, for example:
>>>>>
>>>>>openssl dgst -sha256 -sign key -out content.sha256 signature.txt
>>>>>-passin passphrase
>>>>>
>>>>>There is a pre-step to compute the sha256, in this example, into a
>>>>>file provided to openssl. We could use openssl to compute the hash also.
>>>>>
>>>>>Verification is a bit different than what SSH or GPG does:
>>>>>
>>>>>openssl dgst -sha256 -verify  <(openssl x509 -in certificate -pubkey
>>>>>-noout) -signature sign.txt.sha256 signature.txt
>>>>>
>>>>>and reports either
>>>>>
>>>>>Verified OK
>>>>>Or
>>>>>Verification Failure
>>>>>
>>>>>It does not look like completion codes are consistently involved.
>>>>>
>>>>>This also does look structurally different than both GPG and SSH and
>>>>>more work to set up. It may be possible to provide wrappers and
>>>>>pretend we are in SSH, but I'm not sure that is the right path to take.
>>>>>
>>>>>Any pointers on how this might be done in existing git
>>>>>infrastructure, or should I look into making this work in code?
>>>>>Sorry to say that the documentation is not that clear on this.
>>>>
>>>>Why not gpgsm? It can deal with x509 certs and is already supported.
>>>>I am using this to do s/mime signing/encryption with an yubikey
>>>>hardware token but static certs/keys should be even simpler. However
>>>>I'm not sure how good this works on other platforms.
>>>>
>>>>Take a look into the GPGSM prereq in t/lib-gpg.sh for a few hints on
>>>>how to set this up.
>>>
>>>Good idea but this is a non-starter. I have a limit of GPG 1.4, which
>>>only has the single legacy object. GPG added a dependency to mmap,
>>>which is not available on any of my platforms. That was one reason we were so
>happy to have SSH support.
>>
>>I have been investigating this capability in more depth. After discussing with
>OpenSSL, explicitly adding SSL signing to git would introduce CVE-2022-0778 into git
>and allow a hostile upstream repo to introduce a deliberately defective key that
>could trigger this CVE unless customers have patched OpenSSL. Given the lack of
>broad-based adoption of the fixes to this point, I am reluctant to pursue this
>capability at this time. (Actually referencing my own advice in Git Rev News 82).
>The impact on git would be looping processes when signatures are evaluated. This
>would break workflows that depend on signed content and have downloaded
>keys with the CVE attributes.
>>
>>Does anyone agree/disagree with me on delaying this?
>>--Randall
>>
>
>Do you actually need SSL Signing so you can verify commits with a single CA key?
>Or do you have all the certs public keys anyway?
>
>I know quite a few setups where every employee is issued an x509 cert (often PIV
>Certs, preferably on a smartcard/token) and a central ldap is available with all
>issued certs. This is usually used for authentication and s/mime.
>
>However this can easily be used with ssh signing as well. I do so myself.  I use my
>own s/mime cert loaded into an ssh-agent (pkcs11 smartcard) to sign commits and
>generate an allowed signers file with all the pubkeys extracted from the certs i get
>from the PKIs ldap server.

I would prefer to use SSH - mostly because I am much more comfortable in that space - but SSH has not been authorized for use at this customer. They are a pure SSL shop with each developer having their own SSL unique cert based on the internal corporate CA (as they explained it). I don't have info at this point on the type of cert they are using. Signing is desired to be done by each developer/operator with their own private cert.

The vulnerability is that if SSL certs are used for signatures and a hostile cert gets in via an SSL path. it can trigger the CVE, according to the OpenSSL team.