使用 libcurl 固定 SSL 证书

Question

我想知道这个示例是否足以通过 libcurl 提供证书固定: http://curl.haxx.se/libcurl/c/cacertinmem.html

因为我发现 curl 也允许 http://curl.haxx.se/libcurl/c/CURLOPT_PINNEDPUBLICKEY.html

由于我将使用自签名证书并且只信任它，所以我不知道是否真的有必要固定它。

resume:如果我像示例一样仅将我的证书(自签名)添加到 x509 证书存储区，连接是否会受到威胁？我需要添加额外的支票吗？我需要使用 CURLOPT_PINNEDPUBLICKEY 选项吗？

谢谢。

Answer 1

您可以在 git 2.8(2016 年 3 月)中的新 curl 选项的实现中找到另一个示例:

参见 commit aeff8a6 (2016 年 2 月 15 日)作者 Christoph Egger (siccegge) .
^{(由 Junio C Hamano -- gitster -- 合并于 commit e79112d ，2016 年 2 月 24 日)}

http: implement public key pinning

Add the http.pinnedpubkey configuration option for public key pinning. It allows any string supported by libcurl -- base64(sha256(pubkey)) or filename of the full public key.

If cURL does not support pinning (is too old) output a warning to the user.

git config man page提及:

http.pinnedpubkey:

Public key of the https service.
It may either be the filename of a PEM or DER encoded public key file or a string starting with 'sha256//' followed by the base64 encoded sha256 hash of the public key. See also libcurl 'CURLOPT_PINNEDPUBLICKEY'.
git will exit with an error if this option is set but not supported by cURL.

---

在 Git 2.34(2021 年第 4 季度)中，更新了 SSL 证书固定方面的 HTTPS 错误处理:

参见 commit 3e8084f (2021 年 9 月 24 日)Ævar Arnfjörð Bjarmason (avar) .
^{(由 Junio C Hamano -- gitster -- 合并于 commit 97492aa，2021 年 10 月 11 日)}

http: check CURLE_SSL_PINNEDPUBKEYNOTMATCH when emitting errors

^{Signed-off-by: Ævar Arnfjörð Bjarmason}

Change the error shown when a http.pinnedPubKey doesn't match to point the http.pinnedPubKey variable added in aeff8a6 ("http: implement public key pinning", 2016-02-15, Git v2.8.0-rc0 -- merge listed in batch #8), e.g.:

git -c http.pinnedPubKey=sha256/someNonMatchingKey ls-remote https://github.com/git/git.git
fatal: unable to access 'https://github.com/git/git.git/' with http.pinnedPubkey configuration: SSL: public key does not match pinned public key!

Before this we'd emit the exact same thing without the " with http.pinnedPubkey configuration".
The advantage of doing this is that we're going to get a translated message (everything after the ":" is hardcoded in English in libcurl), and we've got a reference to the git-specific configuration variable that is causing the error.

Unfortunately we can't test this easily, as there are no tests that require https:// in the test suite, and t/lib-httpd.sh doesn't know how to set up such tests.
See this thread for the start of a discussion about what it would take to have divergent "t/lib-httpd/apache.conf" test setups.