我喜歡通過代碼來理解 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 的型別中看到opaquegcc 是否支持它，或者我需要包含任何 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什么 Extension extensions<8..2^16-1>;？
uj5u.com熱心網友回復：
這個結構在 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;
在ClientHello第 4.1.2 節中定義的訊息中
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 個位元組，第一個始終具有0x13所有 5 種情況的值。
那么有多少演算法，每個演算法的位元組大小是多少，或者是否包含任何其他結構也代表 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>是一個可變長度向量，這意味著“擴展”欄位是一個大小為 from8到2^16-1位元組的內容，并且該內容是Extension第 4.2 節中檔案中其他地方定義的型別，如下所示：
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/498209.html