再见三次握手
Bye bye 3 way handshake

原始链接: https://billatnapier.medium.com/bye-bye-three-way-handshake-and-hello-to-0-rtt-d11d9c4f4fdf

OpenSSL 3.5.0 支持后量子密码学 (PQC) 和 0-RTT,旨在加快连接速度。传统的 TCP 三次握手速度较慢,尤其是在当今“始终在线”的环境中频繁重新连接的情况下。0-RTT 集成到 TLS 1.3 中,允许客户端立即发送数据,无需等待服务器确认。客户端最初会进行完整的握手连接,接收用于未来重新连接的会话票据。客户端使用预共享密钥 (PSK) 进行身份验证。 然而,0-RTT 也存在安全风险,例如重放攻击,攻击者可以复制并向多个服务器重新发送客户端的 0-RTT 消息。服务器 A 接受了该消息,但服务器 B 可能会请求握手,从而导致重放攻击,使客户端将消息从服务器 A 重新发送到服务器 B。业界也正在从 TCP 向基于 UDP 的 QUIC 协议迁移,该协议与 0-RTT 配合良好。

Hacker News 最新 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录 再见三次握手 (billatnapier.medium.com) hmaxdml 1小时前 13 分 | 隐藏 | 过去 | 收藏 | 1 评论 lastdong 25分钟前 [–] Cloudflare在其博客中进一步讨论了重放攻击和缓解措施。https://blog.cloudflare.com/introducing-0-rtt/ 回复 加入我们,参加6月16日至17日在旧金山举办的AI创业学校! 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请YC | 联系我们 搜索:

原文
Prof Bill Buchanan OBE FRSE

And, so, today, OpenSSL 3.5.0 was released, and which supports a range of PQC methods and 0-RTT [here]:

Overall, we have stuck with the 3-way handshake for many decades, and it is now seen as too slow in a modern “always-on, always-connected” world. In a normal Web connection, the client sends a SYN TCP request, the server then replies with a TCP SYN/ACK, and then the client sends back an ACK. This obviously slows down the connection, and where we might close a connection, and want it opened up again in a short interval. In fact, HTTP was meant to be stateless, and where we disconnect after a connection is made. Most browsers overcome this with a keep-alive packet.

But all of this will change with 0-RTT (Zero Round Trip Time) and which is integrated into TLS 1.3. This will allow a client to immediately reconnect without the requirement for the three-way handshake. Basically, it allows data to be sent by a client without waiting for the server to respond. With this, the client connects to a server for the first time and does a full TCP 3-way handshake. This handshake also contains cryptographic session information that defines a session ticket. This ticket can then be used by the client to connect to the server at some time in the future. Overall, the server does not have to respond before the client can send data with the ticket. The server can then decide whether it wants to respond to the ticket information.

Normally, there would be a negotiation of the cyphers that are used, such as for the key exchange method, the symmetric key method and the digital signature method. For this, the client sends a Client Hello with the ciphers it would like to use, and the server responds with a Server Hello on the cipher it picks:

With a 0-RTT approach, the client does not have to wait for the server to authenticate itself using a PSK (Pre-shared-key) extension, as agreed upon before the session. The client can then send data at any time without using the three-way handshake or authentication. The client thus has to remember one key per server, but the server will have to remember the PSKs for all the clients that connect to it. If the server forgets the PSK, the client can request a new session ticket.

Unfortunately, there are hacks for this, and the client does not check the certificate of the server it is connecting to, and also for replay attacks. This is defined in the TLS 1.3 specification [here]:

A basic attack is where a client sends a 0-RTT message to Server A. This message is then copied by Eve, and who sends it to both Server A and Server B. Server A will accept it, but Server B will request a full handshake with the client. The client then resends the message to B, and will thus allow for a replay of the message for Server A to Server B —and thus a replay attack.

Overall, we are typically moving away from TCP-type communications and towards the UDP-based QUIC protocol [here]:

0-RTT fits in well with the QUIC protocol, and which is supported in TLS 1.3.

联系我们 contact @ memedata.com