lihongjie0209
commented
3 years ago The TLS Record Protocol
这个协议属于tls中的底层协议, 用于消息的压缩, 加密, hash计算和发送等功能
The TLS Record Protocol is a layered protocol. At each layer, messages may include fields for length, description, and content. The Record Protocol takes messages to be transmitted, fragments the data into manageable blocks, optionally compresses the data, applies a MAC, encrypts, and transmits the result. Received data is decrypted, verified, decompressed, reassembled, and then delivered to higher-level clients.
分组
The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType MAY be coalesced into a single TLSPlaintext record, or a single message MAY be fragmented across several records).
struct {
uint8 major;
uint8 minor;
} ProtocolVersion;
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
type
The higher-level protocol used to process the enclosed fragment.
version The version of the protocol being employed. This document describes TLS Version 1.2, which uses the version { 3, 3 }. The version value 3.3 is historical, deriving from the use of {3, 1} for TLS 1.0. (See Appendix A.1.) Note that a client that supports multiple versions of TLS may not know what version will be employed before it receives the ServerHello. See Appendix E for discussion about what record layer version number should be employed for ClientHello.
length The length (in bytes) of the following TLSPlaintext.fragment. The length MUST NOT exceed 2^14.
fragment The application data. This data is transparent and treated as an independent block to be dealt with by the higher-level protocol specified by the type field.
Implementations MUST NOT send zero-length fragments of Handshake, Alert, or ChangeCipherSpec content types. Zero-length fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure.
压缩
All records are compressed using the compression algorithm defined in the current session state. There is always an active compression algorithm; however, initially it is defined as CompressionMethod.null. The compression algorithm translates a TLSPlaintext structure into a TLSCompressed structure. Compression functions are initialized with default state information whenever a connection state is made active. [RFC3749] describes compression algorithms for TLS.
Compression must be lossless and may not increase the content length by more than 1024 bytes. If the decompression function encounters a TLSCompressed.fragment that would decompress to a length in excess of 2^14 bytes, it MUST report a fatal decompression failure error.
Dierks & Rescorla Standards Track [Page 20]
RFC 5246 TLS August 2008
struct {
ContentType type; /* same as TLSPlaintext.type */
ProtocolVersion version;/* same as TLSPlaintext.version */
uint16 length;
opaque fragment[TLSCompressed.length];
} TLSCompressed;length The length (in bytes) of the following TLSCompressed.fragment. The length MUST NOT exceed 2^14 + 1024.
fragment The compressed form of TLSPlaintext.fragment.
Note: A CompressionMethod.null operation is an identity operation;
no fields are altered.
Implementation note: Decompression functions are responsible for
ensuring that messages cannot cause internal buffer overflows.加密
The encryption and MAC functions translate a TLSCompressed
structure into a TLSCiphertext. The decryption functions reverse
the process. The MAC of the record also includes a sequence
number so that missing, extra, or repeated messages are
detectable.
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (SecurityParameters.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
case aead: GenericAEADCipher;
} fragment;
} TLSCiphertext;type The type field is identical to TLSCompressed.type.
version The version field is identical to TLSCompressed.version.
length The length (in bytes) of the following TLSCiphertext.fragment. The length MUST NOT exceed 2^14 + 2048.
fragment The encrypted form of TLSCompressed.fragment, with the MAC.
HMAC and the Pseudorandom Function
主要的目的是完整性校验和随机数生成
随机数生成的逻辑有点类似CBC, 前一个的输出就是后一个的输入, 通过迭代生成不同长度的随机数
The TLS record layer uses a keyed Message Authentication Code (MAC) to protect message integrity. The cipher suites defined in this document use a construction known as HMAC, described in [HMAC], which is based on a hash function. Other cipher suites MAY define their own MAC constructions, if needed.
In addition, a construction is required to do expansion of secrets into blocks of data for the purposes of key generation or validation. This pseudorandom function (PRF) takes as input a secret, a seed, and an identifying label and produces an output of arbitrary length.
In this section, we define one PRF, based on HMAC. This PRF with the SHA-256 hash function is used for all cipher suites defined in this document and in TLS documents published prior to this document when TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a stronger standard hash function.
First, we define a data expansion function, P_hash(secret, data), that uses a single hash function to expand a secret and seed into an arbitrary quantity of output:
Dierks & Rescorla Standards Track [Page 14]
RFC 5246 TLS August 2008
where + indicates concatenation.
A() is defined as:
P_hash can be iterated as many times as necessary to produce the required quantity of data. For example, if P_SHA256 is being used to create 80 bytes of data, it will have to be iterated three times (through A(3)), creating 96 bytes of output data; the last 16 bytes of the final iteration will then be discarded, leaving 80 bytes of output data.
TLS's PRF is created by applying P_hash to the secret as:
The label is an ASCII string. It should be included in the exact form it is given without a length byte or trailing null character. For example, the label "slithy toves" would be processed by hashing the following bytes: