英文:
Is it safe to verify client certificate in ServeHTTP and ignore bad client certificate?
问题
在我的基于Go HTTPS服务器的应用程序中，我在tls.Config中将ClientAuth设置为RequestClientCert，然后在对ServeHTTP函数的第一次调用中，我从PeerCertificates中获取客户端证书链，并在创建的结构中保存验证结果，然后将其作为上下文值传递给ServeHTTP处理程序，以便后续对ServeHTTP的调用可以重用结果而无需重新验证。
对于我这样一个Go的新手来说，这似乎是实现mTLS的最简单方法。此外，我可以向客户端发送错误响应，说明其证书存在问题或其访问权限已被撤销，而不仅仅是断开连接。我可以编写包含证书信息、客户端IP和尝试访问的URL的日志消息。我还可以为没有证书或证书不再有效的客户端提供一些基本访问权限。我还想将某些证书限制在特定的IP范围内。由于VerifyPeerCertificates和VerifyConnection似乎没有提供太多工具来猜测客户端IP并保存访问权限，而且将认证代码分散在多个函数中对我来说不是一个好主意，所以我决定在ServeHTTP处理程序中完成所有操作。
我做得对吗？这种方法是否存在安全问题？
英文:
In my app based on Go HTTPS server, I set ClientAuth to RequestClientCert in tls.Config, then in the first call to my ServeHTTP function I call Verify on a client certificate chain taking it from PeerCertificates and save result in the structure created in ConnContext and passed as a context value to the ServeHTTP handler, so that further calls to ServeHTTP reuse the result without reverification.
For me as a newbie in Go, it seems to be an easiest way to implement mTLS. Besides, instead of just dropping connection, I can make an error response to a client saying what's wrong with its certificate, or that its access rights have been revoked. I can write a log message containing both certificate info, client IP and URL it tried to access. I can also give some basic access to clients that have no certificate or whose certificates are not good any more. I also would like to limit some certificates to specific IP ranges. Since VerifyPeerCertificates and VerifyConnection seem to give not much tools for guessing client IP and saving access rights, and spreading authentication code over severeal function does not look like a good idea to me, I decided to do everything in ServeHTTP handler.
Am I doing everything right? Are there any security issues in such an approach?
答案1
得分: 2
在保护TLS连接免受中间人攻击时，需要正确验证服务器证书，但客户端证书在保护TLS连接和传输数据方面并不起作用。
因此，在TLS握手期间，不验证客户端证书，而是完成TLS握手，无论客户端证书是否有效，都是可以的。正如问题中正确提出的那样，这样可以向客户端提供更多信息性的响应，而不仅仅是中断TLS连接。
当然，在使用证书来识别客户端之前，应该对证书进行适当的验证。
英文:
While proper validation of the server certificate is needed to protect the TLS connection against man in the middle attacks, the client certificate is not used in protecting the TLS connection and transferred data.
Therefore it is fine to not verify the client certificate during the TLS handshake, but complete the TLS handshake no matter if the client certificate is valid. As correctly proposed in the question - this way it is possible to provide more informative responses to the client instead of just breaking the TLS connection.
Of course the certificate should be properly validated before using it to identify the client.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论