问题标签 [tls1.3]

我正在 Vertx Java 上开发应用程序并使用 Mongodb 作为数据库，当我尝试连接 Mongodb 实例时，它会抛出以下错误

在使用 TLS 1.3 协议（Java 11 及更高版本默认使用 TLS 1.3）的 Java 运行时环境中使用 OCSP 装订时，可能会出现以下异常：

javax.net.ssl.SSLHandshakeException：扩展名 (5) 不应出现在证书请求中

该异常是由于 Java 11 及更高版本中的 TLS 1.3 的一个已知问题。为避免在使用使用 TLS 1.3 协议的 Java 运行时环境时出现此异常，您可以强制应用程序使用 TLS 1.2 协议。为此，请将 jdk.tls.client.protocols 系统属性设置为“TLSv1.2”。

所以我尝试传递 VM 参数

但是没有运气，有人可以帮忙吗？

我正在尝试使用 MQTT.fx 建立与 test.mosquitto.org 的 mqtt 连接。我在 Windows 10 上。

选择 TLSv1.2 作为我的协议可以正常工作。但是使用 TLSv1.3 连接失败。“TSLv1.3 SSLContext 不可用”

MQTT.fx 不支持 TLSv1.3 吗？
我找不到任何关于使用 MQTT.fx 的问题的其他信息。

根据Linux 上的 TLS 1.3 和 OpenSSL 1.1.1，我可以在我的“控制台应用程序（.NET Core）”项目中使用 linux 下的 TLS 1.3。

我的代码

我在centos7下编译openssl-1.1.1h.tar.gz得到了libssl.so.1.1和libcrypto.so.1.1，然后我在我的项目中添加了这两个库作为“内容”

将此项目发布到单个文件

现在我在centos下运行这个程序（注意：没有安装openssl1.1.1），当我尝试连接到这个服务器时出现以下异常。

我认为这是因为程序无法加载这些库

然后我将此路径添加到 LD_LIBRARY_PATH

现在它可以正常工作了！！

因为某些特殊原因，我不应该在我的目标 Centos PC 上安装 openssl1.1.1 并更改 LD_LIBRARY_PATH。这就是我在我的程序中打包 libssl.so.1.1 和 libcrypto.so.1.1 的原因。

程序如何在不更改“LD_LIBRARY_PATH”的情况下找到库？

或者

程序如何只为自己更改 LD_LIBRARY_PATH？

请给我一些建议！帮我！

我写了一个小测试程序来创建

1. 自定义的自签名 CA 证书#1
2. 创建由该 CA 颁发的服务器证书#2 - 根证书#1
3. 创建带有证书#2 的服务器
4. 创建一个 RootCA 指向证书#1 的客户端
5. 客户端尝试连接到服务器并收到错误：

获取 "https://localhost:2000": x509: certificate signed by unknown authority（可能是因为 "x509: Ed25519 验证失败" 同时尝试验证候选权威证书 "test-ca"）

我知道有很多这样的例子。我以为我跟他们很近，但我在这里。我在这里只展示最相关的结构，但程序的全文可以在这里找到：

我错过了什么或做错了什么？

尝试实施 TLS 1.2 与 TLS 1.3 握手测量，重点是会话恢复。

TLS 1.2 运行良好，可恢复 ID 和票证，但更改为 TLS 1.3 时却不行。

不幸的是，wireshark 数据是加密的，但 java 声明如下：

我们不是试图实现 0RTT 恢复，而是使用 SessionTickets。客户端不会向服务器发送 PresharedKey。

代码（客户端）：

服务器 ：

提前致谢 ：）

我在尝试启用 SSLVerifyClient 时遇到问题，因此用户可以使用浏览器上安装的证书进行访问。

我已经创建了 CA、证书、密钥和一切。在我的 Apache conf 上，我有这个：

我有“LocationMatch”，因为我只想要那里的证书。

这里的日志：

[2021 年 1 月 13 日星期三 12:25:18.705565] [ssl:error] [pid 10148:tid 1832] [client 127.0.0.1:50913] AH10158: 无法执行握手后身份验证

[2021 年 1 月 13 日星期三 12:25:18.705565] [ssl:error] [pid 10148:tid 1832] SSL 库错误：错误：14268117：SSL 例程：SSL_verify_client_post_handshake：未收到扩展

问题是，我已经搜索了好几天，今天我发现问题出在 TLS 1.3 上。如果我取消注释SSLProtocol -all +TLSv1.2行（必须在 LocationMatch 之外，否则 Apache 甚至无法启动，我已经测试过了），Apache 将使用 TLS 1.2，然后一切正常。浏览器要求提供证书，然后选择有效的证书，我被允许访问该页面。如果我使用 TLS 1.3（默认选项），我总是获得“禁止访问。您无权访问此资源。原因：无法执行握手后身份验证”。

我一直在寻找几个小时，但我找不到解决方案。我唯一发现的是，在 Firefox 中，about:config 启用了security.tls.enable_post_handshake_auth。对于基于 Chromium 的浏览器，结果是一样的，但我找不到像 Firefox 那样的“deeper-conf”解决方案。无论如何，这不会是一个解决方案。

版本在这里：Apache/2.4.46 (Win64) - OpenSSL/1.1.1g - PHP/7.4.10 - 端口 443

我的配置有问题还是 TLS 有问题？

谢谢你。

编辑：正如@Steffen Ullrich 在下面的评论中所说，浏览器尚不支持此功能（在 Firefox 中，但仅在 about:config 中启用了一个选项，这不是用户友好的，也不是一个选项，至少不适合我）。如果有人和我有同样的问题，那么在 2021 年 1 月 14 日那天是没有办法的。

我正在尝试验证 RFC8879 的实现。是否有任何实现了这个 RFC 的网络服务器或 TLS 库？我做了一些研究，结果表明流行的 webservers/tls 库还没有实现这个 RFC。

我知道 Chrome 浏览器在其 ClientHello (brotli) 中支持证书压缩，是否有任何服务器在其 ServerHello 中支持此功能？谷歌的服务器似乎没有响应 CompressedCertificate 消息。

从我在该模块的Python 文档ssl中可以看到，无法控制如何将 Client Hello 发送到服务器。此外，由于 TLS 协议的Encrypted Client Hello扩展在某种程度上是实验性的，Firefox 仅通过隐藏about:config选项支持它。

话虽如此，今天有没有办法通过 Python 的加密客户端 Hello 创建与 SSL/TLS 服务器的连接？如果可能，我更喜欢使用该requests库的答案，以便可以立即将其应用于连接到 HTTPS 端点。

I've deployed a local instance of https://librespeed.org/ in order to test my LAN speeds. After changing some old cables, the speeds were good (~800mpbs symmetric).

I wanted to leave the service running and give it a URL, so I created a docker-compose.yml and gave it some labels in order to expose it through Traefik (as my other services). To my surprise, after this change the speed was dramatically reduced (~450mbps, almost 50% decrease).

At first I blamed Traefik, but then I just disabled HTTPS and the speeds where back to ~800mbps.

What I've checked:

• All other settings and stack are exactly the same.
• TLS handshake seems to be happening only once, so this does not explain the difference.
• The cypher being used is TLS_AES_128_GCM_SHA256, 128bit keys, TLS 1.3. I didn't change any of Traefik default settings about cyphers, so this is probably Traefik's default.
• The browser used to test was Firefox 84.0.2 (64-bit).

What I'd like to know:

• Is this a common performance downgrade?
• Is Traefik really slow encrypting traffic?
• Does dockerization impact AES encryption in some way (perhaps blocking some hardware access)?

Thanks in advance

Edit: the noble people of reddit made me realize that my old CPU does not have hardware AES acceleration, so that answers most of my concerns. I think this question is still relevant anyway, at least to alert other people that this can happen).

我正在尝试查看 QUIC 数据包的有效负载，但没有运气。我可以使用浏览器生成的 SSLLOGFILE 文件解密精细的 TLS 数据包并将其加载到 Wireshark，我可以看到 HTTPS 和 DoH，并且几乎所有 TLS 加密数据包都被正确解密。

对于 QUIC，情况并非如此，我可以浏览这篇文章：https ://bugs.chromium.org/p/chromium/issues/detail?id=1101691

他们在那里说 SSLKEYLOGFILE 导出 quic 的密钥的问题已经在 chrome 89 中得到修复，所以我下载了 chrome 90（chrome dev 版本），但仍然没有运气。

任何想法我做错了什么？

我可以看到 QUIC 数据包，可以看到客户端 hello，并且所有未加密的 QUIC 数据包都在 Wireshark 中正确解析，但仍然没有解密。