介绍

作为我们的设备身份验证和合规计划的一部分，Pinterest 已通过自定义身份提供商实施面向员工的双向 TLS ，从而带来积极的用户体验。

在尝试使用浏览器或应用程序中的证书进行身份验证时，您可能听说过或亲身经历过一些令人不快的行为。甚至相互 TLS 的维基百科页面也提到 mTLS 是一种“..用户友好性较低的体验，[并且]它很少用于最终用户应用程序……”。

在 Pinterest，我们需要使用自定义身份提供程序，将 Mutual TLS 作为我们员工 SSO 身份验证的一部分。这意味着我们需要支持跨所有主要平台以及来自浏览器和本机应用程序的身份验证。

在这篇博文中，我们将讨论我们所做的一些更改，以确保面向用户的 mTLS 为我们的员工提供无缝体验。

自动浏览器证书选择

为了在 macOS 或 Windows 平台上提供无缝的身份验证体验，我们部署了一项策略，使用AutoSelectCertificateForUrls Chrome 策略代表用户自动选择正确的客户端证书。这导致最终用户没有证书提示。其他浏览器也存在类似的策略。

遗憾的是，类似的政策无法在 Android/iOS 上实施。

击败 SSLClientAuthCache——重新提示证书

我们试图通过基于 mTLS 的身份验证来缓解的一个显着痛点与用户意外关闭证书提示或选择了不正确的证书时的用户体验有关。“重新提示”用户获取证书的唯一方法是重新启动浏览器。

图 1：在 macOS 上运行 Chrome 的用户无法在需要 mTLS 的网站上“重新提示”证书，原因是证书选择不正确。

虽然强制重启浏览器对于 Windows/macOS 平台上的一些人来说可能是一个可以接受的解决方案，但在 iOS 或 Android 上的本机应用程序中做出错误决定的后果尤其可怕。

请注意，即使重新启动本机应用程序也无法解决以下示例中的问题。

图 2：在本机 Android 应用程序中，用户无法在需要 mTLS 的网站上“重新提示”证书，即使在重新启动应用程序后也是如此。

在基于 Chromium 的浏览器上负责此行为的缓存是SSLClientAuthCache，它被描述为：

用于存储 SSL 客户端证书决策的简单缓存结构。提供基于服务器主机和端口的条目查找、插入和删除。

此缓存的简化表示如下：

同样显而易见的是，为什么取消证书提示不会导致重新提示，因为基于 Chromium 的浏览器将“已取消”证书提示视为有意操作：

所需证书可能为 NULL，表示不向 |server| 发送任何证书的偏好。

在上面对 SSLClientAuthCache 的描述中，您可能已经注意到缓存执行查找“..基于服务器的主机和端口的条目。”这表明可以通过更改客户端正在与之交互的服务器的端口或主机名来为该表创建一个新条目。

由于我们控制客户端与之交互的边缘基础设施，我们可以利用此行为通过服务器端更改来击败 SSLClientAuthCache。我们可以简单地将没有通过有效证书的用户重定向到一个随机子域，然后触发用户的浏览器重新提示输入证书。如果用户仍然没有出示证书，他们将被重定向到一个错误页面，他们可以在必要时重试。

在下面的 GIF 中，我们演示了我们使用自定义身份提供程序实现的 mTLS。请注意，即使在本机应用程序中，也可以通过直观的方式补救取消证书提示。

图 3：在本机 Android 应用程序中，用户能够在需要 mTLS 的网站上“重新提示”证书。

下面是在我们的边缘基础设施 ( Envoy )中实现的负责此的路由逻辑，它也可以在其他代理/网络服务器实现中复制。

图 4：Envoy 路由逻辑以击败 /authorize 端点上的 SSLClientAuthCache，这需要 mTLS。

禁用 HTTP/2

为了正确触发随机子域的证书提示，我们还需要禁用 HTTP/2。其原因与 HTTP/2 的连接重用属性有关，在 HTTP/2 RFC 的第 9.1.1 节中进行了描述。

尽管 RFC 提到“不希望客户端重用连接的服务器可以通过发送 421（错误定向请求）状态代码来表明它对请求没有权威”，但我们发现Envoy 不遵守RFC在这方面，421 响应不会发送给客户。

在任何情况下，即使 Envoy 确实遵守 RFC，期望客户端接收和处理 421 响应会不必要地使我们的实施复杂化，因此我们发现简单地禁用 HTTP/2 与我们的自定义身份提供商通信是最好的解决方案。

CA 的专有名称

另一个可以改善用户体验的服务器端更改是正确配置可接受 CA 的可分辨名称列表，这在 TLS 1.2 RFC 的证书请求中进行了描述。许多客户端应用程序（即浏览器）将尝试仅向用户提供已由该列表中出现的 CA 之一签名的客户端证书。

如 RFC 中所述，如果列表为空，则客户端可以发送任何有效证书。然后，您的浏览器将提示您从您可能拥有的所有证书中进行选择，即使它们不会被服务器接受。这会给用户带来特别糟糕（且可避免）的体验，因为系统会提示他们从服务器最终会拒绝的证书列表中进行选择。

图 5：当证书颁发机构的可分辨名称未填充在客户端证书请求中时，证书选择提示。

问题

Web 视图兼容性

由于我们将 mTLS 身份验证作为 Okta SSO 身份验证流程的一部分实施，因此本机应用程序需要能够将用户重定向到能够访问钥匙串/证书存储的浏览器。

如果应用程序开发人员遵循联合身份验证的最佳实践，这将不是问题。不幸的是，我们遇到了大量“企业”工具的本机应用程序，这些应用程序继续提示用户从 WebView 中向 Okta 进行身份验证，而不是使用适当的替代方法，例如适用于 Android的Chrome 自定义选项卡和适用于 iOS的ASWebAuthenticationSession /苹果系统。

除了WebViews 针对 FIDO2 和 mTLS 存在的兼容性问题之外，WebViews还存在真正的安全问题，包括网络钓鱼和 SSO 会话劫持。

在我们与潜在供应商分享的技术要求中，我们更详细地介绍了 WebView 使用带来的风险，以及我们要求应用程序开发人员遵循的正确实现，以便 mTLS 和 FIDO2 正常工作。

iOS 非 Safari 用户

在 iOS 上，Chrome 无法访问系统钥匙串中的证书。这给我们的一些在 iOS 设备上将 Chrome 安装为默认浏览器的用户带来了问题。

更糟糕的是，有些本机应用程序会打开默认浏览器进行身份验证，而不是使用SFSafariViewController或ASWebAuthenticationSession 之类的东西，这意味着将 Chrome 作为默认浏览器的用户根本无法使用这些应用程序。

我们的指导是仅将 Safari 用作 iOS 上的默认浏览器。

Android 工作资料

虽然从安全的角度来看，希望配置的证书只能由用户工作配置文件中的应用程序访问，但从用户体验的角度来看，这可能会导致摩擦。用户并不清楚为什么他们试图在个人资料中访问的应用程序无法访问仅存在于工作资料钥匙串中的证书。

我们确实将此作为向 Android 设备用户显示的错误消息中的故障排除步骤（即“确保您使用的是工作配置文件应用程序”），但它可能会导致帮助台票据以寻求解决方案。

结论

自从大约 3 个月前为 SSO 实施基于 Mutual TLS 的解决方案以来，我们平均每周进行 13k 次身份验证。相关帮助台工单的平均数量少于五张。

对于那些回避使用 mTLS 进行面向用户的身份验证的人，我们强烈建议将其作为一种选择。

非常感谢 Pinterest 流量工程团队的合作伙伴帮助实施此解决方案。

作者:Armen Tashjian | Security Engineer, Corporate Security

出处:https://medium.com/pinterest-engineering/employee-facing-mutual-tls-8643fe0cc0f9

创业项目群，学习操作 18个小项目，添加微信：923199819 备注：小项目！

本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请发送邮件至 zoodoho@qq.com举报，一经查实，本站将立刻删除。
如若转载，请注明出处：https://www.zodoho.com/108676.html

www.pinterest.com,国内怎么上pinterest

介绍