除了客户端的密钥/证书管理之外,还有其他原因吗?
为什么在 TLS 协议中通常不执行客户端身份验证?
什么是认证?这是为了确保在隧道另一端的人就是你所相信的人。这实际上取决于您要使用的身份类型。
对于大多数网站来说,有趣的概念是连续性。他们并不真正关心谁是连接的;确实,网站的重点是每个人都可以阅读。网站希望实现的真实性是确保两个连续的请求确实来自同一个客户端(无论该客户端可能是谁)。这是因为网站体验是由用户的操作(他点击的链接)驱动的一系列逻辑页面的体验,而攻击者所追求的是干预该电影般的框架。用户和网站设计者考虑会话,攻击者想要劫持会话。
这种真实性是通过几种机制实现的:
- 来自同一客户端的连续 HTTP 请求通过同一连接(具有“保持活动”功能)。
- SSL 提供了一种会话恢复机制,它重用协商的共享密钥(即SSL/TLS 标准第 7.3 节中描述的“缩写握手” )。
- HTTP 请求可以包含服务器选择的cookie ;通常,随机的、特定于用户的值作为 cookie 发送给用户,并且在看到它在后续请求中返回时,服务器确信请求来自同一用户。
cookie足以确保连续性。
客户证书会增加什么额外价值?嗯,不多。证书是一种分发密钥/名称绑定的方法。大多数情况下,客户端证书(在 Web 上下文中)是相关的:
Web 服务器需要扩展的用户身份概念,这是由其他人定义的。例如,想象一个公民可以访问的政府服务,但必须经过适当的身份验证,例如在线选举系统。是什么让具有明确姓名和出生日期的公民由整个国家管理,但与运行服务的人不同。客户端证书是一种将身份验证从颁发证书的 PKI 传输到公民的方式,传输到在线选举系统,该系统根本无权说出谁被命名为什么,但仍然必须清楚地记录谁连接。
系统设计者不太信任现有 Web 浏览器的稳健性。如果用户的浏览器被劫持,那么秘密 cookie 就可能被盗,用户基本上永远丢失了。另一方面,如果用户有智能卡,并且该智能卡存储了私钥(与客户端证书结合使用),那么完整的浏览器劫持仍然是一个大问题,但它更包含:由于智能卡不会泄露宝贵的私钥,而是会做出光荣的切腹行为,因此可以恢复这种情况。一旦执行了强制格式化并重新安装,事情就会再次安全。
该网站不仅要真实性,还希望获得不可否认性。不可否认性是一个法律概念,需要系统技术部分的支持,而这种支持就是数字签名。我们不在 SSL/TLS 提供的范围内,这里。SSL/TLS 客户端身份验证决不能成为可用于解决用户与服务器本身之间的某些法律冲突的证据(银行服务器无法显示连接记录并说“看,那个用户真的 让我以那个价格购买这些动作”,因为银行很容易伪造整个成绩单)。对于这样的事情,需要客户证书和一些使用该证书来签署实际数据的客户端代码。但是,一旦向客户端颁发证书的艰巨工作已经完成,仅将它们用于 HTTPS 是有意义的。
在 Web 服务器的常见情况下,这些场景都不适用。所以不使用客户端证书,因为它们会在不增加任何额外价值的情况下引发实际问题。那将是寻找问题的解决方案。
主要原因是 95% 的互联网用户不知道什么是客户端证书,更不用说如何使用它了。一些用户几乎无法使用用户名和密码,而且大多数用户仍然不会使用双因素身份验证。在单独的设备(台式机、笔记本电脑、平板电脑、智能手机等)上安装客户端证书以对单个服务进行身份验证也很麻烦。
因此,快速列表:
- 无知。人们只是不知道它们是什么或它们为什么有用。
- 方便。人们不必费心将他们的设备配置为使用客户端证书。
- 支持。如果今天的人们在忘记密码或无法登录时仍然需要致电技术支持,您能想象如果他们必须安装客户端证书,还需要多少次支持电话吗?IE、Firefox、Chrome、Opera、Safari等以及各种移动设备的安装,使这个问题更加严重。
- 复杂。需要额外的服务器端代码来验证与用户帐户相关的证书。
- 流行。还没有主要网站在大规模使用它们,所以没有其他人会这样做。我意识到这是一个 catch-22,但技术采用通常是这样。
- 自满。大多数供应商都认为密码(或 2FA)对于他们的目的来说足够强大,即使这些供应商正在保护高度敏感/关键的信息,例如财务数据。
因此,虽然很高兴看到大规模的客户端证书,但我真的不认为它会发生,除非一个严重的事件促使供应商这样做。
客户端正在尝试访问 URL 中标识的特定服务器。所以客户端需要对服务器进行身份验证。
另一方面,在 HTTPS 的大多数使用中,任何客户端都可以联系服务器。服务器对客户端没有任何先验知识。因此,服务器无需针对客户端进行身份验证。服务器想要验证用户,而不是客户端机器。
在 Internet 设置中,客户端可能位于代理后面、动态 IP 地址等。服务器可能不需要验证任何内容。验证客户端的唯一要点是记录其身份以供将来使用,无论是出于取证目的还是跨多个连接跟踪客户端。由于用户可能从多台机器进行连接,因此跟踪客户端机器没有多大意义。记录客户端身份对于事后识别恶意客户端或用户的作用很小(攻击者很可能生成了一个不提供任何有用信息的证书),不值得花任何精力。
在只有已知客户端才能连接到服务器的 Intranet 设置中,客户端身份验证很有用并被使用。
在 Gmail、Yahoo 和其他使用 PKI 对服务器进行身份验证的 Web 应用程序等情况下,客户端身份验证不是使用证书完成的,而是使用更简单的身份验证,例如用户/名称密码。想想这个。您的浏览器可以为各种 CA 和网站存储 x 个证书。但是 Gmail 可以为其数百万用户持有证书吗?它根本不可扩展。
这是关于为什么不使用客户端证书的一个非常简化的答案。但是,当您通过 SSH 连接到服务器时,可能会使用客户端证书。