TLS 1.3 客户端问候结构。 在 Linux 用户空间支持的 C 语言中。 谁能告诉我什么结构应该代表客户你好

Question

我喜欢通过代码来理解 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 头 .h 文件或者我需要什么？

所以我相信应该有另一个结构struct CipherSuite如何表示这个结构这个结构包含什么文件。 你知道吗？ 在谷歌上搜索如何表示这个我发现了一些我不明白它是什么的库。 wasnt in C.和其他搜索结果II无法理解，但我理解的是

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包含算法意味着多个算法所以一些算法的数组这两个 D 数组的大小意味着数组的长度和呼吸所以

struct CipherSuite { char some_algorithms[unknow][unknow]

那么有多少算法，每个算法的字节大小是多少，或者是否包含任何其他结构也代表 CipherSuite？ 谁能告诉我这个？ 谢谢

什么是struct Clienthello中的 Extensions 这个Extension extensions<8..2^16-1>; ?

Answer 1

这个结构在 RFC 8446 中定义，它是伪代码，它不直接映射到任何类型的编程语言，所以它不是 C。

请参阅https://datatracker.ietf.org/doc/html/rfc8446#section-3 ，其中解释了使用的模型和词汇。

所以我从来没有在 C 的类型中看到过不透明的

这里的opaque表示对于 TLS“引擎”，内容无关紧要，可以认为是胡言乱语（随机）。 这对其他部分当然有意义，但对 TLS 则不然。 以规范中的这句话为例：

应用程序数据消息包含对 TLS 不透明的数据。

所以opaque在这个级别意味着“非结构化”。

所以我相信应该有另一个结构 struct 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 个项目，每个项目都是一个无符号字节 (uint8)。

您可以在“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 个密码套件中的每一个都映射到 2 个字节，对于所有 5 种情况，第一个始终具有值0x13 。

那么有多少算法，每个算法的字节大小是多少，或者是否包含任何其他结构也代表 CipherSuite？

如果您真的想在低级别实现 TLS 1.3，您确实需要完整阅读 RFC 8446。 多次。 从上到下，从下到上。 甚至还有一些专门提供实施建议的部分。 但是只有在您想学习时才这样做，否则今天的任何语言都应该已经有一个适当的库来处理 TLS 1.3 的所有低级细节，并且您应该在代码中使用该库，而不是重新发明它。

什么是 struct Clienthello 中的 Extension，这个 Extension extensions<8..2^16-1>; 是什么？

稍后在正文中解释：

扩展：客户端通过在扩展字段中发送数据向服务器请求扩展功能。 实际的“扩展”格式在第 4.2 节中定义。 在 TLS 1.3 中，某些扩展的使用是强制性的，因为功能已转移到扩展中以保持 ClientHello 与先前版本的 TLS 的兼容性。 服务器必须忽略无法识别的扩展。

使用第 3 节中解释的语法， Extension extensions<8..2^16-1>是一个可变长度向量，这意味着“扩展”字段是大小为8到2^16-1字节的内容，并且内容是第 4.2 节文档中其他地方定义的Extension类型，如下所示：

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