rfc2246.txt

RFC 的详细文档！

   First, we define a data expansion function, P_hash(secret, data)
   which uses a single hash function to expand a secret and seed into an
   arbitrary quantity of output:

       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
                              HMAC_hash(secret, A(2) + seed) +
                              HMAC_hash(secret, A(3) + seed) + ...

   Where + indicates concatenation.

   A() is defined as:
       A(0) = seed
       A(i) = HMAC_hash(secret, A(i-1))

   P_hash can be iterated as many times as is necessary to produce the
   required quantity of data. For example, if P_SHA-1 was being used to
   create 64 bytes of data, it would have to be iterated 4 times
   (through A(4)), creating 80 bytes of output data; the last 16 bytes
   of the final iteration would then be discarded, leaving 64 bytes of
   output data.

   TLS's PRF is created by splitting the secret into two halves and
   using one half to generate data with P_MD5 and the other half to
   generate data with P_SHA-1, then exclusive-or'ing the outputs of
   these two expansion functions together.

   S1 and S2 are the two halves of the secret and each is the same
   length. S1 is taken from the first half of the secret, S2 from the
   second half. Their length is created by rounding up the length of the
   overall secret divided by two; thus, if the original secret is an odd
   number of bytes long, the last byte of S1 will be the same as the
   first byte of S2.

       L_S = length in bytes of secret;
       L_S1 = L_S2 = ceil(L_S / 2);



Dierks & Allen              Standards Track                    [Page 12]

RFC 2246              The TLS Protocol Version 1.0          January 1999


   The secret is partitioned into two halves (with the possibility of
   one shared byte) as described above, S1 taking the first L_S1 bytes
   and S2 the last L_S2 bytes.

   The PRF is then defined as the result of mixing the two pseudorandom
   streams by exclusive-or'ing them together.

       PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
                                  P_SHA-1(S2, label + seed);

   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:

       73 6C 69 74 68 79 20 74 6F 76 65 73

   Note that because MD5 produces 16 byte outputs and SHA-1 produces 20
   byte outputs, the boundaries of their internal iterations will not be
   aligned; to generate a 80 byte output will involve P_MD5 being
   iterated through A(5), while P_SHA-1 will only iterate through A(4).

6. The TLS Record Protocol

   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, and reassembled, then delivered to
   higher level clients.

   Four record protocol clients are described in this document: the
   handshake protocol, the alert protocol, the change cipher spec
   protocol, and the application data protocol. In order to allow
   extension of the TLS protocol, additional record types can be
   supported by the record protocol. Any new record types should
   allocate type values immediately beyond the ContentType values for
   the four record types described here (see Appendix A.2). If a TLS
   implementation receives a record type it does not understand, it
   should just ignore it. Any protocol designed for use over TLS must be
   carefully designed to deal with all possible attacks against it.
   Note that because the type and length of a record are not protected
   by encryption, care should be take to minimize the value of traffic
   analysis of these values.






Dierks & Allen              Standards Track                    [Page 13]

RFC 2246              The TLS Protocol Version 1.0          January 1999


6.1. Connection states

   A TLS connection state is the operating environment of the TLS Record
   Protocol. It specifies a compression algorithm, encryption algorithm,
   and MAC algorithm. In addition, the parameters for these algorithms
   are known: the MAC secret and the bulk encryption keys and IVs for
   the connection in both the read and the write directions. Logically,
   there are always four connection states outstanding: the current read
   and write states, and the pending read and write states. All records
   are processed under the current read and write states. The security
   parameters for the pending states can be set by the TLS Handshake
   Protocol, and the Handshake Protocol can selectively make either of
   the pending states current, in which case the appropriate current
   state is disposed of and replaced with the pending state; the pending
   state is then reinitialized to an empty state. It is illegal to make
   a state which has not been initialized with security parameters a
   current state. The initial current state always specifies that no
   encryption, compression, or MAC will be used.

   The security parameters for a TLS Connection read and write state are
   set by providing the following values:

   connection end
       Whether this entity is considered the "client" or the "server" in
       this connection.

   bulk encryption algorithm
       An algorithm to be used for bulk encryption. This specification
       includes the key size of this algorithm, how much of that key is
       secret, whether it is a block or stream cipher, the block size of
       the cipher (if appropriate), and whether it is considered an
       "export" cipher.

   MAC algorithm
       An algorithm to be used for message authentication. This
       specification includes the size of the hash which is returned by
       the MAC algorithm.

   compression algorithm
       An algorithm to be used for data compression. This specification
       must include all information the algorithm requires to do
       compression.

   master secret
       A 48 byte secret shared between the two peers in the connection.

   client random
       A 32 byte value provided by the client.



Dierks & Allen              Standards Track                    [Page 14]

RFC 2246              The TLS Protocol Version 1.0          January 1999


   server random
       A 32 byte value provided by the server.

   These parameters are defined in the presentation language as:

       enum { server, client } ConnectionEnd;

       enum { null, rc4, rc2, des, 3des, des40 } BulkCipherAlgorithm;

       enum { stream, block } CipherType;

       enum { true, false } IsExportable;

       enum { null, md5, sha } MACAlgorithm;

       enum { null(0), (255) } CompressionMethod;

       /* The algorithms specified in CompressionMethod,
          BulkCipherAlgorithm, and MACAlgorithm may be added to. */

       struct {
           ConnectionEnd          entity;
           BulkCipherAlgorithm    bulk_cipher_algorithm;
           CipherType             cipher_type;
           uint8                  key_size;
           uint8                  key_material_length;
           IsExportable           is_exportable;
           MACAlgorithm           mac_algorithm;
           uint8                  hash_size;
           CompressionMethod      compression_algorithm;
           opaque                 master_secret[48];
           opaque                 client_random[32];
           opaque                 server_random[32];
       } SecurityParameters;

   The record layer will use the security parameters to generate the
   following six items:

       client write MAC secret
       server write MAC secret
       client write key
       server write key
       client write IV (for block ciphers only)
       server write IV (for block ciphers only)

   The client write parameters are used by the server when receiving and
   processing records and vice-versa. The algorithm used for generating
   these items from the security parameters is described in section 6.3.



Dierks & Allen              Standards Track                    [Page 15]

RFC 2246              The TLS Protocol Version 1.0          January 1999


   Once the security parameters have been set and the keys have been
   generated, the connection states can be instantiated by making them
   the current states. These current states must be updated for each
   record processed. Each connection state includes the following
   elements:

   compression state
       The current state of the compression algorithm.

   cipher state
       The current state of the encryption algorithm. This will consist
       of the scheduled key for that connection. In addition, for block
       ciphers running in CBC mode (the only mode specified for TLS),
       this will initially contain the IV for that connection state and
       be updated to contain the ciphertext of the last block encrypted
       or decrypted as records are processed. For stream ciphers, this
       will contain whatever the necessary state information is to allow
       the stream to continue to encrypt or decrypt data.

   MAC secret
       The MAC secret for this connection as generated above.

   sequence number
       Each connection state contains a sequence number, which is
       maintained separately for read and write states. The sequence
       number must be set to zero whenever a connection state is made
       the active state. Sequence numbers are of type uint64 and may not
       exceed 2^64-1. A sequence number is incremented after each
       record: specifically, the first record which is transmitted under
       a particular connection state should use sequence number 0.

6.2. Record layer

   The TLS Record Layer receives uninterpreted data from higher layers
   in non-empty blocks of arbitrary size.

6.2.1. Fragmentation

   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, minor;
       } ProtocolVersion;



Dierks & Allen              Standards Track                    [Page 16]

RFC 2246              The TLS Protocol Version 1.0          January 1999


       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.0, which uses the version { 3, 1 }. The
       version value 3.1 is historical: TLS version 1.0 is a minor
       modification to the SSL 3.0 protocol, which bears the version
       value 3.0. (See Appendix A.1).

   length
       The length (in bytes) of the following TLSPlaintext.fragment.
       The length should 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.

 Note: Data of different TLS Record layer content types may be
       interleaved. Application data is generally of lower precedence
       for transmission than other content types.

6.2.2. Record compression and decompression

   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.