tls.txt

huffman编码压缩

TLS interoperability              
1.  Introduction

   One of the basic foundations of the various SSL protocol versions SSL
   v2 [SSLv2], SSL v3.0 [SSLv3], TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346]
   is that they are supposed to be able to work seamlessly with other
   implementations of both older versions of the protocol, and newer
   versions that were not even under consideration at the time the
   implementation was written.  The older versions are not supposed to
   be able to understand the new protocol versions, but using their
   version of the protocol, they are supposed to be able to negotiate a
   connection with the newer version, provided that the newer
   implementation is willing and able to do so.  That ability may depend
   on both the implementer's willingness to support the older versions
   due to engineering constraints and known security problems with the
   older version.  But, assuming that both implementations support the
   same version of the protocol, they should be able to communicate.

   Over the years it has become an unfortunate reality that while most
   SSL and TLS implementations do work together in the above mentioned
   ideal fashion, there are far too many implementations that do not (in
   particular) properly implement the forward compatibility portions of
   the specifications.  This has caused a number of serious problems
   which again may have led client vendors to delay implementation or
   deployment of new TLS-related functionality or versions.  Other
   vendors may have deployed the new features, but have only been able
   to do so by adding automatic workarounds that in many respects
   actually disable security features of the protocol.

   Even if one discounts the fact that SSL v2 and SSL v3 were
   incompatible at the binary level, with every upgrade since; the
   migration from SSL v3 to TLS 1.0, the addition of TLS Extensions and
   the current migration from TLS 1.0 to TLS 1.1, clients have
   encountered servers that were not willing to accept connections from
   clients that supported these features.

   To make matters worse, from the client vendor's viewpoint, many of
   the sites causing these problems are sites that are vital to their
   customers, such as banking and shopping sites.

   This document will present a number of the implementation mistakes
   that have been observed throughout the author's period as the lead
   developer of an SSL/TLS client.  In most cases one has knowledge only
   about what happened, not the precise reason why.  The cases listed
   here are not intended as an exhaustive list of problems that have
   occurred in implementations of the SSL/TLS protocol, but to give an
   overview of what the situation is.

   Finally, there will be a short evaluation of what may have caused the
2.  The SSL v3 to TLS 1.0 transition

   The SSL v3 specification [SSLv3] includes the following version
   forward compatibility and security features:

   o  A field in the Client Hello that tells the server the highest
      version the client supports.  If the server supports a more recent
      version than the client does, then it is supposed to select the
      client's version, otherwise it is to use its own highest supported
      version.

   o  A field in the RSA Client Key Exchange message that contains the
      highest version the client supports.  The server must check this
      version number against the version number received in the Client
      Hello.  If it is different, somebody may have attempted to reduce
      the security of the connection by downgrading the negotiated
      version.

   These two features were intended to make it possible for
   implementations using newer SSL/TLS versions to connect to older
   implementations, and vice versa.

   Unfortunately, a number of server implementations got at least one of
   those points wrong.  Some SSL v3 servers refuse to even answer when a
   client using TLS 1.0 or higher tries to establish a connection,
   others answer, but the negotiation fails after the RSA Client Key
   Exchange step because they use the negotiated version number, not the
   version number in the Client Hello, to check the version number in
   the RSA Key Exchange block.

   Appendix A.1 and Appendix A.2 contain a couple of examples of the
   first type of problem, refusal to talk to TLS 1.0 clients.  In these
   cases, the server usually closes down the connection immediately
   without an error code, although in some cases they do send an error
   first.

   In the second type of problem the server correctly chooses SSL v3 as
   the version, but the last part of the handshake fails because the
   server assumes that the decrypted RSA Key Exchange message should
   contain the SSL v3 protocol version, not the TLS 1.0 version number
   (which is the correct one).  In such cases the server also closes the
   connection.  An example of a similar case, involving a TLS 1.1 client
   and a TLS 1.0 server is found in Appendix A.6.

  To be able to connect to these servers clients have had to restart
   the negotiation on a new connection, with TLS 1.0 disabled, an action
   which for the RSA cipher suites mean that the version roll back
   protection is non-existent.

   In addition to the above examples, a SSL v3 server that used whatever
   version the client identified in the Client Hello Version field as
   the version selected in the Server Hello has also been observed.
   That is, if the client identified {3,0} as its highest version the
   server selected (correctly) {3,0}, but if the client identified {3,1}
   or (the unspecified) {4,0} (Appendix A.8) the server selected {3,1}
   and {4,0}, respectively, even though it could not know what those
   protocol versions were.  This incorrect version selection will
   invariably result in a handshake failure during the Client Key
   Exchange phase or a MAC/decryption failure during the decryption of
   the Finished Message

   When the client used the SSL v2 Client Hello the version was
   correctly negotiated, which lead this problem being hidden until TLS
   1.0 clients recently stopped using the SSL v2 Client Hello in the
   initial connection and started using the TLS 1.0 (or later) Client
   Hello instead, as part of the transition to support TLS
   ExtensionsSection 4.  As the server would previously only see a SSL
   v3.0 Client Hello after the client had determined the server
   supported SSL v3.0 as its highest version, such as during session
   resume or renegotiation, the server would only see a SSL v3.0 version
   number from the client.  It is likely that the vendor, as part of
   mistaken optimization, just copied the version field into the
   session's state without checking that the version was the correct
   one.