rfc2246.txt

中、英文RFC文档大全打包下载完全版 .

   can be instantiated using the same session through the resumption
   feature of the TLS Handshake Protocol.

7.1. Change cipher spec protocol

   The change cipher spec protocol exists to signal transitions in
   ciphering strategies. The protocol consists of a single message,
   which is encrypted and compressed under the current (not the pending)
   connection state. The message consists of a single byte of value 1.

       struct {
           enum { change_cipher_spec(1), (255) } type;
       } ChangeCipherSpec;

   The change cipher spec message is sent by both the client and server
   to notify the receiving party that subsequent records will be
   protected under the newly negotiated CipherSpec and keys. Reception
   of this message causes the receiver to instruct the Record Layer to
   immediately copy the read pending state into the read current state.
   Immediately after sending this message, the sender should instruct
   the record layer to make the write pending state the write active
   state. (See section 6.1.) The change cipher spec message is sent
   during the handshake after the security parameters have been agreed
   upon, but before the verifying finished message is sent (see section
   7.4.9).

7.2. Alert protocol

   One of the content types supported by the TLS Record layer is the
   alert type. Alert messages convey the severity of the message and a
   description of the alert. Alert messages with a level of fatal result
   in the immediate termination of the connection. In this case, other
   connections corresponding to the session may continue, but the
   session identifier must be invalidated, preventing the failed session
   from being used to establish new connections. Like other messages,
   alert messages are encrypted and compressed, as specified by the
   current connection state.

       enum { warning(1), fatal(2), (255) } AlertLevel;

       enum {
           close_notify(0),
           unexpected_message(10),
           bad_record_mac(20),
           decryption_failed(21),
           record_overflow(22),



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


           decompression_failure(30),
           handshake_failure(40),
           bad_certificate(42),
           unsupported_certificate(43),
           certificate_revoked(44),
           certificate_expired(45),
           certificate_unknown(46),
           illegal_parameter(47),
           unknown_ca(48),
           access_denied(49),
           decode_error(50),
           decrypt_error(51),
           export_restriction(60),
           protocol_version(70),
           insufficient_security(71),
           internal_error(80),
           user_canceled(90),
           no_renegotiation(100),
           (255)
       } AlertDescription;

       struct {
           AlertLevel level;
           AlertDescription description;
       } Alert;

7.2.1. Closure alerts

   The client and the server must share knowledge that the connection is
   ending in order to avoid a truncation attack. Either party may
   initiate the exchange of closing messages.

   close_notify
       This message notifies the recipient that the sender will not send
       any more messages on this connection. The session becomes
       unresumable if any connection is terminated without proper
       close_notify messages with level equal to warning.

   Either party may initiate a close by sending a close_notify alert.
   Any data received after a closure alert is ignored.

   Each party is required to send a close_notify alert before closing
   the write side of the connection. It is required that the other party
   respond with a close_notify alert of its own and close down the
   connection immediately, discarding any pending writes. It is not
   required for the initiator of the close to wait for the responding
   close_notify alert before closing the read side of the connection.




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


   If the application protocol using TLS provides that any data may be
   carried over the underlying transport after the TLS connection is
   closed, the TLS implementation must receive the responding
   close_notify alert before indicating to the application layer that
   the TLS connection has ended. If the application protocol will not
   transfer any additional data, but will only close the underlying
   transport connection, then the implementation may choose to close the
   transport without waiting for the responding close_notify. No part of
   this standard should be taken to dictate the manner in which a usage
   profile for TLS manages its data transport, including when
   connections are opened or closed.

   NB: It is assumed that closing a connection reliably delivers
       pending data before destroying the transport.

7.2.2. Error alerts

   Error handling in the TLS Handshake protocol is very simple. When an
   error is detected, the detecting party sends a message to the other
   party. Upon transmission or receipt of an fatal alert message, both
   parties immediately close the connection. Servers and clients are
   required to forget any session-identifiers, keys, and secrets
   associated with a failed connection. The following error alerts are
   defined:

   unexpected_message
       An inappropriate message was received. This alert is always fatal
       and should never be observed in communication between proper
       implementations.

   bad_record_mac
       This alert is returned if a record is received with an incorrect
       MAC. This message is always fatal.

   decryption_failed
       A TLSCiphertext decrypted in an invalid way: either it wasn`t an
       even multiple of the block length or its padding values, when
       checked, weren`t correct. This message is always fatal.

   record_overflow
       A TLSCiphertext record was received which had a length more than
       2^14+2048 bytes, or a record decrypted to a TLSCompressed record
       with more than 2^14+1024 bytes. This message is always fatal.

   decompression_failure
       The decompression function received improper input (e.g. data
       that would expand to excessive length). This message is always
       fatal.



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


   handshake_failure
       Reception of a handshake_failure alert message indicates that the
       sender was unable to negotiate an acceptable set of security
       parameters given the options available. This is a fatal error.

   bad_certificate
       A certificate was corrupt, contained signatures that did not
       verify correctly, etc.

   unsupported_certificate
       A certificate was of an unsupported type.

   certificate_revoked
       A certificate was revoked by its signer.

   certificate_expired
       A certificate has expired or is not currently valid.

   certificate_unknown
       Some other (unspecified) issue arose in processing the
       certificate, rendering it unacceptable.

   illegal_parameter
       A field in the handshake was out of range or inconsistent with
       other fields. This is always fatal.

   unknown_ca
       A valid certificate chain or partial chain was received, but the
       certificate was not accepted because the CA certificate could not
       be located or couldn`t be matched with a known, trusted CA.  This
       message is always fatal.

   access_denied
       A valid certificate was received, but when access control was
       applied, the sender decided not to proceed with negotiation.
       This message is always fatal.

   decode_error
       A message could not be decoded because some field was out of the
       specified range or the length of the message was incorrect. This
       message is always fatal.

   decrypt_error
       A handshake cryptographic operation failed, including being
       unable to correctly verify a signature, decrypt a key exchange,
       or validate a finished message.





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


   export_restriction
       A negotiation not in compliance with export restrictions was
       detected; for example, attempting to transfer a 1024 bit
       ephemeral RSA key for the RSA_EXPORT handshake method. This
       message is always fatal.

   protocol_version
       The protocol version the client has attempted to negotiate is
       recognized, but not supported. (For example, old protocol
       versions might be avoided for security reasons). This message is
       always fatal.

   insufficient_security
       Returned instead of handshake_failure when a negotiation has
       failed specifically because the server requires ciphers more
       secure than those supported by the client. This message is always
       fatal.

   internal_error
       An internal error unrelated to the peer or the correctness of the
       protocol makes it impossible to continue (such as a memory
       allocation failure). This message is always fatal.

   user_canceled
       This handshake is being canceled for some reason unrelated to a
       protocol failure. If the user cancels an operation after the
       handshake is complete, just closing the connection by sending a
       close_notify is more appropriate. This alert should be followed
       by a close_notify. This message is generally a warning.

   no_renegotiation
       Sent by the client in response to a hello request or by the
       server in response to a client hello after initial handshaking.
       Either of these would normally lead to renegotiation; when that
       is not appropriate, the recipient should respond with this alert;
       at that point, the original requester can decide whether to
       proceed with the connection. One case where this would be
       appropriate would be where a server has spawned a process to
       satisfy a request; the process might receive security parameters
       (key length, authentication, etc.) at startup and it might be
       difficult to communicate changes to these parameters after that
       point. This message is always a warning.

   For all errors where an alert level is not explicitly specified, the
   sending party may determine at its discretion whether this is a fatal
   error or not; if an alert with a level of warning is received, the





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


   receiving party may decide at its discretion whether to treat this as
   a fatal error or not. However, all messages which are transmitted
   with a level of fatal must be treated as fatal messages.

7.3. Handshake Protocol overview

   The cryptographic parameters of the session state are produced by the
   TLS Handshake Protocol, which operates on top of the TLS Record
   Layer. When a TLS client and server first start communicating, they
   agree on a protocol version, select cryptographic algorithms,
   optionally authenticate each other, and use public-key encryption
   techniques to generate shared secrets.

   The TLS Handshake Protocol involves the following steps:

     - Exchange hello messages to agree on algorithms, exchange random
       values, and check for session resumption.

     - Exchange the necessary cryptographic parameters to allow the
       client and server to agree on a premaster secret.

     - Exchange certificates and cryptographic information to allow the
       client and server to authenticate themselves.

     - Generate a master secret from the premaster secret and exchanged
       random values.

     - Provide security parameters to the record layer.

     - Allow the client and server to verify that their peer has
       calculated the same security parameters and that the handshake
       occurred without tampering by an attacker.

   Note that higher layers should not be overly reliant on TLS always
   negotiating the strongest possible connection between two peers:
   there are a number of ways a man in the middle attacker can attempt
   to make two entities drop down to the least secure method they
   support. The protocol has been designed to minimize this risk, but
   there are still attacks available: for example, an attacker could
   block access to the port a secure service runs on, or attempt to get
   the peers to negotiate an unauthenticated connection. The fundamental
   rule is that higher levels must be cognizant of what their security
   requirements are and never transmit information over a channel less
   secure than what they require. Th