TLS 1.3客户端hello结构,在C中支持Linux用户空间,任何人都可以告诉什么结构应该看起来像代表客户端hello

我喜欢通过代码来理解tls。tls 1.3和密码套装，所以我开始了，起初我发现在tls 1.3握手是客户端用hello消息发起与服务器的握手。在此页面上的文档https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.2
它说这
此消息的结构：

uint16 ProtocolVersion;
  opaque Random[32];

  uint8 CipherSuite[2];    /* Cryptographic suite selector */

  struct {
      ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
      Random random;
      opaque legacy_session_id<0..32>;
      CipherSuite cipher_suites<2..2^16-2>;
      opaque legacy_compression_methods<1..2^8-1>;
      Extension extensions<8..2^16-1>;
  } ClientHello;

字符串
所以我从来没有在C的类型称为opaque，它是由gcc支持，或者我需要包括任何glibc头文件，或者我需要什么？
所以我相信应该有另一个结构struct CipherSuite如何表示这个结构这个结构包含什么字段。你知道吗？在谷歌上搜索如何表示这个我发现了一些库，我不明白它是什么。不是在C。和其他搜索结果我我不明白，但我明白的是

Put simply, a cipher suite is a collection of different algorithms, protocols, and all the other good stuff that encrypts and decrypts data between two communicating parties

型
所以struct CipherSuite包含算法（s）意味着多个算法，所以一些算法的数组，这个二维数组的大小意味着数组的长度和宽度，
struct CipherSuite { char some_algorithms[unknow][unknow]
那么有多少算法，每个算法的字节大小是多少，或者是否包含任何其他结构来表示CipherSuite？有人能告诉我吗？谢谢
什么是struct Clienthello中的扩展，什么是Extension extensions<8..2^16-1>;？

这个结构是在RFC 8446中定义的，它是伪代码，它不直接Map到任何一种编程语言，所以它不是C。
请参阅https://datatracker.ietf.org/doc/html/rfc8446#section-3，它解释了所使用的模型和词汇表。
所以我从来没有在C语言中看到过不透明的类型
opaque在这里的意思是，对于TLS“引擎”，内容无关紧要，可以认为是乱码（随机）。这对其他部分当然有意义，但对TLS没有意义。
以规范中的这句话为例：
应用程序数据消息包含对TLS不透明的数据。
所以opaque在这个级别上意味着“非结构化”。
所以我相信应该有另一个结构体，结构体CipherSuite，如何表示这个结构体，这个结构体包含什么字段，你知道吗？
cipherSuite看起来像这样：

uint8 CipherSuite[2];    /* Cryptographic suite selector */

      struct {
          ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
          Random random;
          opaque legacy_session_id<0..32>;
          CipherSuite cipher_suites<2..2^16-2>;
          opaque legacy_compression_methods<1..2^8-1>;
          Extension extensions<8..2^16-1>;
      } ClientHello;

字符串
在§4.1.2中定义的ClientHello消息中
uint8 CipherSuite[2]意味着密码套件是2个项目，每个项目是一个无符号字节（uint 8）。
您可以在“B.4. Cipher Suites”中看到以下值：

+------------------------------+-------------+
              | Description                  | Value       |
              +------------------------------+-------------+
              | TLS_AES_128_GCM_SHA256       | {0x13,0x01} |
              |                              |             |
              | TLS_AES_256_GCM_SHA384       | {0x13,0x02} |
              |                              |             |
              | TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
              |                              |             |
              | TLS_AES_128_CCM_SHA256       | {0x13,0x04} |
              |                              |             |
              | TLS_AES_128_CCM_8_SHA256     | {0x13,0x05} |
              +------------------------------+-------------+

型
因此，TLS 1.3中定义的5个密码套件中的每一个都Map到2个字节，第一个总是在所有5种情况下都具有值0x13。
那么有多少算法，每个算法的字节大小是多少，或者是否包含任何其他结构体来表示CipherSuite？
如果你真的想在低级别上实现TLS 1.3，你真的需要完整地阅读RFC 8446。多次。从上到下，从下到上。甚至有专门关于实现建议的章节。但只有当你想学习时才这样做，否则，今天的任何语言都应该有一个适当的库来处理TLS 1.3的所有底层细节，你应该在代码中使用这个库，而不是重新发明
什么是结构Clienthello中的扩展扩展什么是扩展<8..2^16-1>;？
这是解释稍后在文本中：
扩展：客户端通过在extensions字段中发送数据来向服务器请求扩展功能。实际的“Extension”格式在第4.2节中定义。在TLS 1.3中，某些扩展的使用是强制性的，因为功能已经转移到扩展中以保持ClientHello与以前版本的TLS的兼容性。服务器必须忽略无法识别的扩展。
使用第3节中解释的语法，Extension extensions<8..2^16-1>是一个可变长度的向量，这意味着“extensions”字段的大小从8到2^16-1字节，并且内容的类型为Extension，在第4.2节的文档中定义为：

struct {
        ExtensionType extension_type;
        opaque extension_data<0..2^16-1>;
    } Extension;

型

TLS 1.3客户端hello结构,在C中支持Linux用户空间,任何人都可以告诉什么结构应该看起来像代表客户端hello

1条答案

相关问题

热门标签

最新问答