ClientHello.random and ServerHello.random values are hashed with the
   session's master_secret. Provided that the master_secret has not been
   compromised and that the secure hash operations used to produce the
   encryption keys and MAC secrets are secure, the connection should be
   secure and effectively independent from previous connections.
   Attackers cannot use known encryption keys or MAC secrets to
   compromise the master_secret without breaking the secure hash
   operations (which use both SHA and MD5).

   Sessions cannot be resumed unless both the client and server agree.
   If either party suspects that the session may have been compromised,
   or that certificates may have expired or been revoked, it should
   force a full handshake. An upper limit of 24 hours is suggested for
   session ID lifetimes, since an attacker who obtains a master_secret
   may be able to impersonate the compromised party until the
   corresponding session ID is retired. Applications that may be run in
   relatively insecure environments should not write session IDs to
   stable storage.

F.1.5. MD5 and SHA

   TLS uses hash functions very conservatively. Where possible, both MD5
   and SHA are used in tandem to ensure that non-catastrophic flaws in
   one algorithm will not break the overall protocol.

F.2. Protecting application data

   The master_secret is hashed with the ClientHello.random and
   ServerHello.random to produce unique data encryption keys and MAC
   secrets for each connection.




 
RFC 2246              The TLS Protocol Version 1.0          January 1999


   Outgoing data is protected with a MAC before transmission. To prevent
   message replay or modification attacks, the MAC is computed from the
   MAC secret, the sequence number, the message length, the message
   contents, and two fixed character strings. The message type field is
   necessary to ensure that messages intended for one TLS Record Layer
   client are not redirected to another. The sequence number ensures
   that attempts to delete or reorder messages will be detected. Since
   sequence numbers are 64-bits long, they should never overflow.
   Messages from one party cannot be inserted into the other's output,
   since they use independent MAC secrets. Similarly, the server-write
   and client-write keys are independent so stream cipher keys are used
   only once.

   If an attacker does break an encryption key, all messages encrypted
   with it can be read. Similarly, compromise of a MAC key can make
   message modification attacks possible. Because MACs are also
   encrypted, message-alteration attacks generally require breaking the
   encryption algorithm as well as the MAC.

 Note: MAC secrets may be larger than encryption keys, so messages can
       remain tamper resistant even if encryption keys are broken.

F.3. Final notes

   For TLS to be able to provide a secure connection, both the client
   and server systems, keys, and applications must be secure. In
   addition, the implementation must be free of security errors.

   The system is only as strong as the weakest key exchange and
   authentication algorithm supported, and only trustworthy
   cryptographic functions should be used. Short public keys, 40-bit
   bulk encryption keys, and anonymous servers should be used with great
   caution. Implementations and users must be careful when deciding
   which certificates and certificate authorities are acceptable; a
   dishonest certificate authority can do tremendous damage.

















 
RFC 2246              The TLS Protocol Version 1.0          January 1999


G. Patent Statement

   Some of the cryptographic algorithms proposed for use in this
   protocol have patent claims on them. In addition Netscape
   Communications Corporation has a patent claim on the Secure Sockets
   Layer (SSL) work that this standard is based on. The Internet