java 验证码透明背景

因此，我有一个幼稚的想法，即除了证书有效性检查（在Java中）之外，将证书透明性验证作为每个请求的一部分也很容易。

牺牲了整个周末的一半时间，我可以证明这并不是一件小事。 但是， 证书透明性是什么？ 简而言之，它是世界上所有TLS证书的公开日志（即使SSL已过时，仍称为SSL证书）。 您可以检查该日志中是否发布了日志，如果不发布，则有些可疑，因为CA必须将其所有已颁发的证书推送到日志中。 还有其他用例，例如，为您的域注册新证书的通知，以检测可能被劫持的DNS管理面板或CA（ Facebook免费提供了这样的工具 ）。

我想做的是前者–使来自Java应用程序的每个请求在证书透明性日志中验证对方的证书。 似乎这不是开箱即用的（如果可以，我找不到它。 在一次有关JEP 244的讨论中 ，似乎讨论了与证书透明性有关的TLS扩展，但是我找不到它是否是最终支持）。

我开始认为您可以简单地获取证书，然后通过证书的指纹检查其是否包含在日志中。 这太容易了-允许通过哈希检查的日志，但这不是证书的指纹，而是签名的证书时间戳-由日志在包含之前发布的签名。 引用CT RFC ：

SCT（签名证书时间戳）是日志将证书合并到Merkle树中的承诺

merkle树是一种非常酷的数据结构，它通过提供比整个日志短得多的“包含证明”，使外部参与者确信该日志中包含某些内容（从而节省了大量带宽）。 实际上，默克尔树的凉爽是为什么我首先对证书透明性感兴趣的原因（因为我们在我当前的面向日志的公司中使用默克尔树）

因此，为了检查是否包含 ，您必须以某种方式获取SCT。 最初，我认为使用Certificate Transparency Java库是可能的，但事实并非如此。 拥有它之后，您可以使用客户端在日志中对其进行检查，但是获取它比较困难。 （注意：对于服务器端验证，可以通过HTTP查询日志； 但是浏览器可以使用DNS查询来保留用户的匿名性）。

可以通过三种方式来获得SCT，具体取决于服务器和/或日志和/或CA选择支持的方式：SCT可以包含在证书中，也可以在TLS握手期间作为TLS扩展提供。 ，也可以在握手期间再次包含在TLS装订响应中。 不幸的是，我检查的少数证书中没有存储SCT，因此我必须进入较低级别并调试TLS握手。

我启用了TLS hadnshake 冗长的输出 ，并且瞧瞧-那里什么都没有。 Google确实将SCT包含为TLS扩展（根据Qualys），但Java输出未对此进行任何说明。

幸运的是（？）Google发布了Conscrypt –一种基于Java的安全性提供程序，基于Google的OpenSSL分支。 事情开始变得一团糟……但我还是去了，包括Conscrypt并将其注册为安全提供程序。 我必须使用Conscrypt TrustManager建立连接（已使用JDK中的所有受信任证书初始化）：

KeyStore trustStore = KeyStore.getInstance("JKS");
trustStore.load(new FileInputStream(System.getenv("JAVA_HOME") + "/lib/security/cacerts"), "changeit".toCharArray());
ctx.init(null,new TrustManager[] {new TrustManagerImpl(trustStore, null, null, null, logStore, null, new StrictCTPolicy())}, new SecureRandom());URL url = new URL("https://google.com");
HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
conn.setSSLSocketFactory(ctx.getSocketFactory());
conn.connect();
conn.getInputStream();
conn.disconnect();

当然，它最初并不起作用，因为Conscrypt不提供某些核心接口（CTLogStore和CTPolicy类）的实现。 实际上，CTLogStore是保留有关所有已知日志信息的重要位（我仍然发现将“日志提供程序”简称为“ log”很奇怪，但这是公认的术语）。 有一个以JSON形式存在的已知日志列表 ，这很酷，只是花了我一段时间（在外部帮助下）才能弄清楚那些公钥到底是什么。 它们是什么-RSA，ECC？ 它们如何编码？ 您在RFC和文档中都找不到。 在这里可以看到它是“ SubjectPublicKeyInfo ASN.1结构的DER编码”。 啊。

BouncyCastle进行营救。 我与BouncyCastle的恋爱关系深深。 我讨厌它的直观性和API的复杂性，但是我喜欢它（几乎）具有您可能需要的所有与密码相关的东西。 在花费一些时间试图弄清楚如何将公共密钥转换为PublicKey对象之后，我发现使用PublicKeyFactory.createKey(Base64.getDecoder().decode(base64Key)); 为您提供使用任何算法的参数-它可以返回椭圆曲线关键参数或RSA关键参数。 您只需要将它们包装在另一个类中，然后将它们传递到另一个工厂（通常为BouncyCastle），就可以拥有公共密钥。

当然，现在Google的Conscrypt不再起作用，因为在转换之后，publicKey的编码版本与原始字节不相同，因此日志ID计算错误。 但是我经过一番思考后解决了这个问题，最后，它奏效了–查询了证书透明性日志，并证明该证书有效并且正确地包含在日志中。

整个代码可以在这里找到 。 是的，它使用了多个安全提供程序，一些奇怪的BouncyCastle API和Google提供程序中缺少的一些简单实现。 可能会缓存已知的证书，以便不执行对日志的重复调用，但这超出了我的实验范围。

证书透明性似乎是当今互联网的核心内容。 但是，它是如此晦涩且难以使用。

为什么列表中的公共密钥类型没有记录（它们至少应在公共密钥旁边放置一个OID，因为事实证明，并非所有日志都使用椭圆曲线-其中两个使用RSA）。 也许有一个很好的解释，但是为什么在日志中包括SCT而不是证书的指纹？ 那么，为什么不要求在证书中包括SCT，而不需要将服务器和客户端包含在TLS握手中，而证书和证书又需要升级呢？

据我所知，由于数以百万计的Let's加密证书在那里，证书透明性倡议现在面临可伸缩性问题。 每个日志（提供者）都应将整个日志提供给所有请求它的人。 解决这不是一件容易的事，并且朝着这个方向努力了，但是目前还没有明显的解决方案。

最后，如果Java没有简便的方法来实现这一点，那么所有的加密库都可用，我想知道其他语言的情况如何。 他们支持证书透明性还是需要升级？

也许我们都很好，因为浏览器支持它，但是浏览器并不是发出HTTP请求的唯一对象。 API调用是一个巨大的用例，如果可以对其进行劫持，则所造成的损害甚至可能比被诱骗的单个用户还要大。 因此，我认为应该在两方面加大投入：
1.改进RFC和2.改进编程生态系统。 我希望这篇文章至少能有所贡献。

翻译自: https://www.javacodegeeks.com/2019/01/certificate-transparency-verification-java.html

java 验证码透明背景