tls.Config.VerifyPeerCertificate 是否绕过 golang 中默认提供的检查?

问题描述 投票:0回答:1

我想实施更严格的检查,只允许证书中使用少数常用名称。

我正在查看此提交https://go-review.googlesource.com/c/go/+/26654/4/src/crypto/tls/handshake_client.go#310

在我看来,verifyPeerCertificate 只是增强了证书验证过程,而不是绕过现有检查并仅依赖于自定义实现。

这种理解对吗?我确实在堆栈溢出上看到了截然不同的答案

go ssl tls1.2
1个回答
0
投票

文档清楚地描述了该行为。引用:

// VerifyPeerCertificate, if not nil, is called after normal
// certificate verification by either a TLS client or server. It
// receives the raw ASN.1 certificates provided by the peer and also
// any verified chains that normal processing found. If it returns a
// non-nil error, the handshake is aborted and that error results.
//
// If normal verification fails then the handshake will abort before
// considering this callback. ...

因此,除非

InsecureSkipVerify
为真(见下文),否则它将以正常方式验证证书。如果内置验证失败,它将失败,即在这种情况下甚至不调用
VerifyPeerCertificate
。这意味着
VerifyPeerCertificate
无法覆盖内置验证以使其通过,但它可以向证书添加额外的约束并覆盖内置验证的肯定结果以使其失败。

//                        ... If normal verification is disabled (on the
// client when InsecureSkipVerify is set, or on a server when ClientAuth is
// RequestClientCert or RequireAnyClientCert), then this callback will be
// considered but the verifiedChains argument will always be nil. When
// ClientAuth is NoClientCert, this callback is not called on the server.
// rawCerts may be empty on the server if ClientAuth is RequestClientCert or
// VerifyClientCertIfGiven.

因此,当

InsecureSkipVerify
为 true 时,
VerifyPeerCertificate
独自负责验证,并且不会进行内置验证。

© www.soinside.com 2019 - 2024. All rights reserved.