简体   繁体   English

TLS握手消息解析

[英]TLS Handshake message parsing

I am currently trying to implement a tls handshake into a http proxy that I am writing. 我目前正在尝试将tls握手实现到我正在编写的http代理中。 I know that I could use OpenSSL to do the work for me but I am interested in writing it myself. 我知道我可以使用OpenSSL为我完成这项工作,但是我对自己编写它感兴趣。

I am currently working through the TLS RFC and am confused about how to parse the ClientHello message, particularly the fact that it may or may not have a session ID and that there seems to be a no count on the number of ciphersuites or compression methods. 我目前正在通过TLS RFC进行工作,并且对如何解析ClientHello消息感到困惑,尤其是它可能具有或不具有会话ID,并且似乎没有密码套件或压缩方法的数量这一事实。

Does anyone know the best way of doing this? 有谁知道最好的方法吗?

The session_id is preceded by the length. session_id之前是长度。 Same with the cipher suites and compression algorithms. 与密码套件和压缩算法相同。

What's you're missing is section 4.3 of the RFC: 您所缺少的是RFC的4.3部分:

Variable length vectors are defined by specifying a subrange of legal lengths, inclusively, using the notation . 可变长度向量是通过指定有效长度的子范围(包括在内)来定义的。 When encoded, the actual length precedes the vector's contents in the byte stream . 进行编码时, 实际长度在字节流中位于向量的内容之前 The length will be in the form of a number consuming as many bytes as required to hold the vector's specified maximum (ceiling) length. 长度将采用数字形式,该数字消耗保持向量指定的最大(上限)长度所需的字节数。 A variable length vector with an actual length field of zero is referred to as an empty vector. 实际长度字段为零的可变长度向量称为空向量。

Take a look at THIS INCREDIBLE BOOK . 看看这本不可思议的书 I had to implement the TLS 1.2 for an embedded system without using any GPL software and this was enormously helpful. 我必须在不使用任何GPL软件的情况下为嵌入式系统实现TLS 1.2,这非常有帮助。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM