TLS-OBC 是一项 RFC 提案，它通过在 TLS 连接的两端使用证书来提高 SSL/TLS 安全性。这里的特别之处在于允许客户端动态创建本地自签名证书。
它还可以保护用户免受“相关域 Cookie 攻击”，更多信息在这里
是否有任何已知问题会导致预先存在的浏览器证书部署和 TLS-OBC 出现问题？
用于系统管理员的 TLS-OBC：http ://www.browserauth.net/
TLS-OBC RFC：https ://datatracker.ietf.org/doc/html/draft-balfanz-tls-obc-01
（TLS-OBC 还不是 RFC，只是一个提案，并且与所有草案一样，可能会发生变化。）
如前所述，TLS-OBC 是SSL/TLS协议的扩展。这种扩展有一个方案，可以在ClientHello和ServerHello消息的末尾添加。除非客户端和服务器同意使用它们，否则不会发生与 TLS-OBC 相关的任何事情。可能，一些非常旧且有缺陷的服务器可能会ClientHello从客户端阻塞，但对于所有其他扩展程序也可以这样说，并且它不会阻止浏览器使用，例如，服务器名称指示。所以那里没有真正的问题。
我在此草稿中看到的可能问题包括：
当使用 TLS-OBC 时，服务器不应发送已接受 CA 的列表，并且客户端无论如何都必须忽略它们。这意味着给定的服务器接受 OBC 类型的证书或标准证书，但不能同时接受两者。而且，服务器必须在知道目标路径之前做出这个决定，所以它是一个服务器范围的设置。
OBC 在跟踪客户方面非常有效——这就是它的重点，真的，当它被用作“强化 cookie”时。这意味着与 cookie 相同的隐私问题。我想实现 TLS-OBC 的浏览器将提供与使用 cookie 相同的选择（即拒绝某些特定服务器使用 OBC 的方法）。
与普通客户端证书相反，OBC 不能防止机构中间人攻击（当代理服务器即时创建虚假服务器证书时——假设客户端信任库中安装了同谋 CA，这是一些想要密切监控员工的大型组织中相对常见的设置）。“攻击者”（可能是合法的攻击者，作为系统管理员）只需替换他自己的 OBC。
大多数情况下，我不清楚 OBC 以何种方式真正提高了安全性。