相互 SSL - 多少身份验证才足够？
假设您有一个双向 SSL 服务，除了 SSL 之外，该服务还具有应用程序身份验证。因此，客户端提供证书（以及服务器），但客户端请求（例如，REST 请求）还包含后端应用程序服务器用来进行身份验证的用户名/密码。
就客户端认证的“程度”而言，似乎有多个级别。一级 (a) 只是让客户端提供由服务器 CA 存储中的 CA 签名的证书。另一个明显的级别 (b) 是服务器执行 (a) 并确保应用程序凭据正确。第三级 (c) 是执行 (a) 和 (b) 并确保客户端证书与帐户唯一关联。
(c) 的好处是它可以防止“可信 CA”信任的人滥用非法获得的应用程序密码。
我意识到这一切都不太可能，但我想知道在多大程度上 (c) 被假定为相互 SSL 的一部分，而不是简单地 (a) 或 (b)？
Suppose you have a mutual SSL service, which in addition to the SSL, has application authentication. Thus, clients provide certificates (as well as servers), but the client request (e.g., REST request) also contains a username/password which the back-end application server authenticates with.
In terms of the "degree" of client authentication, it seems that there are multiple levels. One level (a) is simply for the client to provide a cert that is signed by a CA which is in the server CA store. Another obvious level (b) is for the server to enfore (a) plus ensure that the application credentials are correct. A third level (c) is to do (a) and (b) plus ensure that the client cert is uniquely associated with the account.
The benefit of (c) is thet it prevents someone who is trusted by a "trusted CA" to abuse an application password illegally obtained.
I realize this is all very unlikely, but I am wondering to what extent (c) is assumed to be part of mutual SSL, versus simply (a) or (b)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，我在考虑类似的东西 。
您可以做的一件事是为您的应用程序提供一个不包含任何 CA 的单独信任库。这样您就可以只向具有您授权的自签名证书的客户端授予访问权限。
Yeah, I was thinking about something similar.
One thing that you can do is give your application a separate truststore that does not contain any CAs. This way you can just give access to clients with self-signed certificates that you have authorized.
我假设“相互 SSL”是指具有基于服务器和客户端证书的身份验证的 TLS v1.0、1.1 或 1.2，而“相互 SSL 的一部分”是指 TLS 规范的一部分。
使用这种解释，只有 (a) 是相互 SSL 的一部分。 TLS 规范包括与 SSL 握手消息共享证书。它不包括用户名/密码检查或针对帐户检查 SSL 证书。
I'll assume that by "mutual SSL" you mean TLS v1.0, 1.1, or 1.2 with both server and client certificate-based authentication, and by "part of mutual SSL" you mean part of the TLS specification.
Using this interpretation, only (a) is part of mutual SSL. The TLS specification includes sharing the certificate with an SSL handshake message. It does not include username/password checks or checking the SSL cert against an account.