使用 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 (15 Feb 2016) by Christoph Egger (siccegge)。
^{（由 Junio C Hamano -- gitster -- in 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 (24 Sep 2021) by Ævar Arnfjörð Bjarmason (avar)。
^{（由 Junio C Hamano -- gitster -- in 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.