[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Network Working Group                                       Y. Pettersen
Internet-Draft                                        Opera Software ASA
Intended status: Informational                          October 16, 2006
Expires: April 19, 2007


 Clientside interoperability experiences for the SSL and TLS protocols
                   draft-ietf-tls-interoperability-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 19, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document presents a number of problems encountered when
   implementing TLS 1.0, TLS 1.1 and TLS Extensions for clients, and
   their consequences.  The problems include servers that refuse to
   connect with clients supporting newer versions of the protocol, or
   that do not handle such negotiation properly.  Another problem
   encountered is the incorrect use of values in the protocol messages.





Pettersen                Expires April 19, 2007                 [Page 1]


Internet-Draft            TLS interoperability              October 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  The SSL v3 to TLS 1.0 transition . . . . . . . . . . . . . . .  4
   3.  The TLS 1.0 to TLS 1.1 transition  . . . . . . . . . . . . . .  5
   4.  The introduction of TLS Extensions . . . . . . . . . . . . . .  6
   5.  Incorrect use of Record Protocol version numbers . . . . . . .  7
   6.  Introducing Compression  . . . . . . . . . . . . . . . . . . .  9
   7.  Consequences . . . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  What should be done? . . . . . . . . . . . . . . . . . . . . . 10
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   12. Normative References . . . . . . . . . . . . . . . . . . . . . 11
   Appendix A.  Examples  . . . . . . . . . . . . . . . . . . . . . . 12
     A.1.  SSL v3 server refuses TLS 1.0 client(case 1) . . . . . . . 12
     A.2.  SSL v3 server refuses TLS 1.0 client (case 2)  . . . . . . 13
     A.3.  TLS 1.0 server refuses TLS 1.1 client  . . . . . . . . . . 15
     A.4.  TLS 1.0 server refuses TLS Extensions  . . . . . . . . . . 16
     A.5.  Renegotiation with SSL v3 records over TLS 1.0
           connection . . . . . . . . . . . . . . . . . . . . . . . . 17
     A.6.  Wrong version expected in RSA Client Key Exchange  . . . . 23
     A.7.  Refusing to accept compression methods . . . . . . . . . . 28
     A.8.  Copying the Client Hello Version field . . . . . . . . . . 28
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29
   Intellectual Property and Copyright Statements . . . . . . . . . . 30

























Pettersen                Expires April 19, 2007                 [Page 2]


Internet-Draft            TLS interoperability              October 2006


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



Pettersen                Expires April 19, 2007                 [Page 3]


Internet-Draft            TLS interoperability              October 2006


   current situation, and a few suggestions about what may be done to
   avoid these problems in the future, both for TLS and other protocols.


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.




Pettersen                Expires April 19, 2007                 [Page 4]


Internet-Draft            TLS interoperability              October 2006


   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.


3.  The TLS 1.0 to TLS 1.1 transition

   TLS 1.0 [RFC2246] also contained the same forward compatibility and
   version roll-back attack protections as SSL v3, and given the more
   formal specification of TLS 1.0, one might have hoped vendors would
   have taken better care to implement those specified provisions, so
   that a future transition from TLS 1.0 to TLS 1.1 [RFC4346] would work
   better.

   Again, however, a number of TLS server vendors did not implement
   these aspects properly, and in many cases it is not possible to tell
   what is causing the problem, the web server, or a gateway server
   between the client and the web server.

   Appendix A.3 shows a couple of cases where the server shuts down the
   connection immediately when it gets a Client Hello containing a TLS



Pettersen                Expires April 19, 2007                 [Page 5]


Internet-Draft            TLS interoperability              October 2006


   1.1 version number.  Similarly to the SSL v3 to TLS 1.0 transition
   servers using the wrong version number during the Client Key Exchange
   step have also been observed, as seen in Appendix A.6.

   While many of the servers just close the connection, there are also
   some TLS 1.0 servers that fall back to SSL v3 when being contacted by
   a TLS 1.1 client.


4.  The introduction of TLS Extensions

   SSL v3 [SSLv3], TLS 1.0 [RFC2246] , and TLS 1.1 [RFC4346] all specify
   the possibility of an extension of the Client Hello to contain more
   information.  This extension was defined with the TLS Extensions
   specification [RFC3546].

   TLS Extensions defines a field containing a sequence of data items
   that inform the server about the client's capabilities and/or
   requirements.  Two such fields are the Server Name Extension and the
   Certificate Status Extension, which can be used, respectively, to
   tell the server which server the client wants to connect to, allowing
   virtual server hosting for secure servers, and request that the
   server provides an OCSP response for the server's certificate.

   As with the negotiation of version number, not all server
   implementations have taken these requirements into consideration, and
   in many cases TLS 1.0 servers will refuse to accept connections from
   clients that send TLS Extensions in the Client Hello, usually
   indicated by closing the connection without sending any error
   message.  It was already known before work on TLS Extensions started
   that some SSL v3 servers would not tolerate the extended Client Hello
   used by TLS Extensions, even though the SSLv3 specification mentions
   the possibility of such an extension of the protocol.

   Various scenarios have been observed:

   o  Some servers accept TLS Extensions with TLS 1.0, but refuse to
      accept them from TLS 1.1 clients

   o  Some servers accept TLS Extensions only from a TLS 1.1 client

   o  Some servers refuse to accept TLS Extensions under any
      circumstances.

   Failures are usually signalled by closing the connection, optionally
   with an error alert, but servers that did not respond, leaving the
   connection open, have also been observed.




Pettersen                Expires April 19, 2007                 [Page 6]


Internet-Draft            TLS interoperability              October 2006


   In at least one case, the reason for the first scenario seems to be
   that the server incorrectly used the Record Protocol version number
   as the negotiation input for version number, not the Client Hello
   version number field, and for version 3.2 reclassified it as 3.0 (not
   3.1, as it should have), and then refused to accept the extended
   record, even if SSL v3 permits extended records.

   Similar handling, but with more "graceful" recovery may be the reason
   for the second scenario.

   The third case, by far the most common, may be caused by incorrect
   understanding of the specification, but it may also be the result of
   misguided efforts at protecting the server from an attack by using
   data format rules in the firewall that are too restrictive.  An
   indication of the latter is that the server in Appendix A.3
   originally only refused to accept connection requests from a TLS 1.1
   client, but four weeks after the site was first tested, it was no
   longer accepting TLS Extension requests (Appendix A.4).  However, it
   has not been possible to confirm or refute this theoretical
   possibility.


5.  Incorrect use of Record Protocol version numbers

   Three incorrect uses of the SSL/TLS protocols Record Protocol version
   numbers has been observed, one server side, and two client side.
   These have not had much impact until recently (2005) because most SSL
   and TLS clients have been using the SSL v2 Client Hello to provide
   backward compatibility with servers that only supports SSL v2.  As
   these servers are being upgraded, the need for this backward
   compatibility is diminishing, and most clients are now disabling this
   protocol in their default configuration, and they are therefore
   starting to use the SSL v3 and later Client Hellos in the initial
   handshake.

   The first incorrect use concerns which Record Protocol version number
   to use in the initial connection.  A single sentence in Section E of
   [RFC2246] covers this area, and specifies that "TLS clients who wish
   to negotiate with SSL 3.0 servers should send client hello messages
   using the SSL 3.0 record format and client hello structure, sending
   {3, 1} for the version field to note that they support TLS 1.0".

   What this implies (in the author's current, revised understanding) is
   that the client should use the server's highest known version number
   in the first handshake (which would mean SSL v3.0 when there is no
   information available about the server).

   At the very least, the author of this document missed the



Pettersen                Expires April 19, 2007                 [Page 7]


Internet-Draft            TLS interoperability              October 2006


   significance of this sentence.  It had not had any significance when
   clients were using SSL v2 handshakes initially, since during future
   handshakes the client would know which version the server supported.
   It did however turn out to have some impact on some, but not all, of
   the problems with TLS 1.1 described above.

   Changing the negotiation sequence to use SSL v3's 3.0 version number
   in the initial SSL/TLS record did, however, turn out to reveal
   another incorrect use of the Record Protocol version number: Some
   servers use it as the Client's Requested SSL/TLS protocol version-
   field instead of the Client Hello message field.

   This means that a client using an SSL v3.0 record to request a TLS
   1.0 connection from a TLS 1.0 capable server in some cases actually
   got an SSL v3 connection instead.  Curiously, it does not seem like
   the RSA Client Key Exchange test for version roll-back triggered,
   probably because the implementations did use the correct field to
   retrieve the version number used in that check, but did not check it
   against the negotiated version number.

   In other cases, such as in Appendix A.1 a SSL v3 server will not
   accept the TLS 1.0 version number in the protocol record, and will
   shut down the connection without any warning.

   In some cases this use of the Record Protocol field has had some
   curious effects.  In one case, if the client used the TLS 1.1 version
   number (3.2) while connecting to the server, the server would
   negotiate SSL v3.0, even though it did support TLS 1.0.  This caused
   (as described above) the server not to accept TLS Extensions when the
   TLS 1.1 Record Protocol was used.

   The third case concerned a client with which the author is not
   associated.  This client would negotiate a TLS 1.0 session using a
   SSL v3 Record Protocol message with a Client Hello requesting TLS
   1.0.  Once the TLS session was negotiated, the client sent a new
   Client Hello, presumably to renegotiate the connection without
   revealing any of the exchanged information to eavesdroppers.  It did
   this in the TLS 1.0 session, using a 3.0 Record Protocol version.

   Apparently this worked in many cases, but in the case of two
   financial websites they returned errors when the client sent their
   second Client Hello, one of them a normal TLS error code, the other
   (the same one as in Appendix A.3 and Appendix A.4) actually responded
   with an SSL v2 error code Appendix A.5, which the client naturally
   wasn't able to understand.






Pettersen                Expires April 19, 2007                 [Page 8]


Internet-Draft            TLS interoperability              October 2006


6.  Introducing Compression

   [RFC3749] introduced new compression capabilities to TLS.  The
   compression capability, which is intended to reduce bandwidth
   requirments, was documented already in [SSLv3], but until RFC3749 no
   compression methods, beside the Null method (no compression), had
   been defined.  SSL v3 and all versions of TLS clearly specified that
   the list of compression methods was the list of methods (including
   the Null method) supported by the client, in order of preference, and
   that the server must select one of them among those it supports.

   Clients and servers should therefore always be able to negotiate a
   compression method, even if it is the Null method.

   Testing performed by Pasi Eronen have, however, indicated that at
   least one server implementation (Appendix A.7) does not accept
   connections from clients that offer to do any kind of compression in
   addition to the Null method.


7.  Consequences

   As a consequence of the problems detailed above, many mass-market
   client vendors have had to deploy SSL/TLS implementations that
   disable protocol features if the server does not understand it.  In
   particular, this was necessary both for the move to TLS 1.0, and to
   TLS 1.1, but it has also become necessary for TLS Extensions.

   The reason for this automatic disabling of features is that most of
   these clients cannot refuse to connect to an SSL/TLS server whose
   "only" problem is that it refuses to connect to a client that
   supports a feature it does not support.

   The consequence, however, is that (at the very least) some security
   features in the protocol, such as the version roll-back protection
   (in the RSA-suites), are effectively disabled, because it is
   impossible for a client to distinguish between a non-compliant server
   and a malicious attack.  A related issue is that only the RSA suites
   defined in TLS have any version roll-back protection that does not
   depend on the security of the message digest functions.

   As long as SSL v3, TLS 1.0 and TLS 1.1 are as similar as they are,
   and relying on the same methods, this probably does not reduce the
   security of the protocol.  However, as future versions of TLS are
   unlikely to rely solely on the same mechanisms as the current
   versions of TLS due to attacks on those mechanisms becoming more
   feasible, the possibility of a version roll-back attack becomes more
   realistic.



Pettersen                Expires April 19, 2007                 [Page 9]


Internet-Draft            TLS interoperability              October 2006


8.  What should be done?

   Even though SSL and TLS clearly specified forward compatibility
   requirements in the specifications, a significant number of
   implementers did not implement them properly.  Similarly, a number of
   implementers got some of the backwards compatibility guidelines
   wrong.

   Many of these problems may have been caused, however indirectly, by
   the amount of detail in the specifications, which is unavoidable in
   any specification of some size.  It may be possible to counter that
   category of problems by organizing the documents differently, such as
   by adding sections that summarizes important parts of the protocol.

   Other problems may have been introduced because of external concerns,
   such as security.

   What can be done to improve the situation, for TLS, as well as other
   protocols?

   This document will not be able to provide the answer to that, but
   brings up the following questions:

   o  Should important aspects of a protocol be collected in an
      implementer's checklist?

   o  Should forward and backward compatibility requirements be better
      documented, e.g. by examples?

   o  Should specifications include reference implementations?  If so,
      who should develop them?

   o  Should such reference implementations also include tests that
      break border conditions?

   o  Should the IETF host reference implementations?

   o  Can and should future TLS implementations contain Key Exchange-
      independent version roll-back protection?  (Currently only the RSA
      suites in [SSLv3], [RFC2246] and [RFC4346] have such protection)

   o  Is it feasible for future TLS specifications to require that
      implementations must never automatically fall back to an earlier
      version of the protocol, in case negotiation fails?







Pettersen                Expires April 19, 2007                [Page 10]


Internet-Draft            TLS interoperability              October 2006


9.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


10.  Security Considerations

   This document discusses various problems with the implementations of
   the SSL and TLS protocol versions, and the interaction between
   implementations of newer and older versions of this protocol.  The
   solution to some of the problems discussed can have security
   implications, such as when a client automatically disables its
   support for a version of the protocol or a feature in the protocol
   when it encounters a problem with a server.


11.  Acknowledgements

   Many of the sites exhibiting the problems discussed above and used in
   some of the examples were originally discovered by external testers
   of the Opera Browser, such as the Elektrans and those who
   participated in the September 2004 My Opera TLS 1.1 Scavenger Hunt,
   and employees of Opera Software ASA.

   The example in Appendix A.7 was contributed by Pasi Eronen.


12.  Normative References

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 3546, June 2003.

   [RFC3749]  Hollenbeck, S., "Transport Layer Security Protocol
              Compression Methods", RFC 3749, May 2004.

   [RFC3943]  Friend, R., "Transport Layer Security (TLS) Protocol
              Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943,
              November 2004.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.



Pettersen                Expires April 19, 2007                [Page 11]


Internet-Draft            TLS interoperability              October 2006


   [SSLv2]    Feb18, "The SSL Protocol", Feb 1995,
              <http://wp.netscape.com/eng/security/SSL_2.html>.

   [SSLv3]    "The SSL Protocol Version 3.0", Nov 1996,
              <http://wp.netscape.com/eng/ssl3/draft302.txt>.


Appendix A.  Examples

A.1.  SSL v3 server refuses TLS 1.0 client(case 1)

   This server accepted connections from TLS 1.0 clients on one of two
   conditions

   1.  The Client used an SSL v2 Client Hello record

   2.  The client used an SSL v3 record protocol record to send the
       Client Hello with the TLS 1.0 version number.

A.1.1.  Failed connection

   This example shows a handshake started with TLS 1.0 Client Hello in a
   TLS 1.0 record, the result being that the server terminates the
   connection immediately.

 C: sending 82 bytes (Client Hello)
0000 : 16 03 01 00 4d 01 00 00 49 03 01 44 2c 2d 1f 67   ....M...I..D,-.g
0010 : 6c e5 05 a5 88 12 6b 8f a8 d3 e5 9e e0 55 e0 bd   l.....k......U..
0020 : 99 24 dd dc 72 36 8c c7 18 f5 69 00 00 22 00 39   .$..r6....i..".9
0030 : 00 38 00 37 00 36 00 35 00 33 00 32 00 31 00 30   .8.7.6.5.3.2.1.0
0040 : 00 2f 00 05 00 04 00 13 00 0d 00 16 00 10 00 0a   ./..............
0050 : 01 00                                             ..

 S: received 14 bytes (Alert messages 10 Unexpected message
    and Close Notify)
0000 : 15 03 00 00 02 02 0a 15 03 00 00 02 01 00         ..............

A.1.2.  Successful connection

   This example shows a TLS 1.0 Client Hello in a SSL v3.0 record, and
   the server responds with a Server Hello










Pettersen                Expires April 19, 2007                [Page 12]


Internet-Draft            TLS interoperability              October 2006


 C : sending 82 bytes (Client Hello)
0000 : 16 03 00 00 4d 01 00 00 49 03 01 44 2c 35 2d 17   ....M...I..D,5-.
0010 : ad 60 c8 4d 8a 51 a5 59 f9 cd bc 3e b1 9c a2 ff   .`.M.Q.Y...>....
0020 : 42 71 33 2f 80 86 3f 4b f6 62 ea 00 00 22 00 39   Bq3/...K.b...".9
0030 : 00 38 00 37 00 36 00 35 00 33 00 32 00 31 00 30   .8.7.6.5.3.2.1.0
0040 : 00 2f 00 05 00 04 00 13 00 0d 00 16 00 10 00 0a   ./..............
0050 : 01 00                                             ..

 S : received 47 bytes (Server Hello, v3.0)
0000 : 16 03 00 00 2a 02 00 00 26 03 00 44 2c 35 96 1d   ....*...&..D,5..
0010 : d5 02 df 00 eb 5d fb 32 2e 51 64 42 99 c4 94 c2   .....].2.QdB....
0020 : 46 61 b3 19 e1 50 28 93 57 a9 e9 00 00 05 00      Fa...P(.W......

A.1.3.  Successful Connection

   This example shows a SSL v2 Client Hello requesting a TLS 1.0
   connection.  The server responds with a SSL v3 Server Hello

 C : sending 138 bytes (SSL v2 Client Hello)
0000 : 80 88 01 03 01 00 6f 00 00 00 10 00 00 39 00 00   ......o......9..
0010 : 38 00 00 37 00 00 36 00 00 35 00 00 33 00 00 32   8..7..6..5..3..2
0020 : 00 00 31 00 00 30 00 00 2f 00 00 05 00 00 04 00   ..1..0../.......
0030 : 00 13 00 00 0d 00 00 16 00 00 10 00 00 0a 00 00   ................
0040 : 12 00 00 0c 00 00 15 00 00 0f 00 00 09 00 00 64   ...............d
0050 : 00 00 62 00 00 11 00 00 0b 00 00 14 00 00 0e 00   ..b.............
0060 : 00 08 00 00 03 00 00 06 01 00 80 07 00 c0 03 00   ................
0070 : 80 06 00 40 02 00 80 04 00 80 44 2c 36 28 d6 0e   ...@......D,6(..
0080 : d9 20 b8 9c d6 0f ad aa 80 d7                     . ........

 S : received 47 bytes (SSL v3 Server Hello)
0000 : 16 03 00 00 2a 02 00 00 26 03 00 44 2c 36 92 97   ....*...&..D,6..
0010 : 91 4f 1d b2 e1 96 e2 5c 99 c2 5c 21 8e 91 67 91   .O.....\..\!..g.
0020 : 4b 34 ee e7 78 56 65 7b 7a f0 ad 00 00 05 00      K4..xVe{z......

A.2.  SSL v3 server refuses TLS 1.0 client (case 2)

   Date:  April 5, 2006

   Server:  Lotus-Domino/5.0.8

   Site:  https://www.ecbanking.com.my/

   This site refused to connect with any client presenting the TLS 1.0
   version number in the Client Hello message







Pettersen                Expires April 19, 2007                [Page 13]


Internet-Draft            TLS interoperability              October 2006


A.2.1.  Failed connection

   This example uses an SSL v2 Client Hello, requesting a TLS 1.0
   connection.  The server closes the connection without sending any
   data or error messages to the client.

 C : Sending 138 bytes (SSL v2 Client Hello, requesting TLS 1.0)
0000 : 80 88 01 03 01 00 6f 00 00 00 10 00 00 39 00 00   ......o......9..
0010 : 38 00 00 37 00 00 36 00 00 35 00 00 33 00 00 32   8..7..6..5..3..2
0020 : 00 00 31 00 00 30 00 00 2f 00 00 05 00 00 04 00   ..1..0../.......
0030 : 00 13 00 00 0d 00 00 16 00 00 10 00 00 0a 00 00   ................
0040 : 12 00 00 0c 00 00 15 00 00 0f 00 00 09 00 00 64   ...............d
0050 : 00 00 62 00 00 11 00 00 0b 00 00 14 00 00 0e 00   ..b.............
0060 : 00 08 00 00 03 00 00 06 01 00 80 07 00 c0 03 00   ................
0070 : 80 06 00 40 02 00 80 04 00 80 44 33 0c 61 ef 3e   ...@......D3.a.>
0080 : 2f 10 6b 09 94 56 cc 7d 5c 18                     /.k..V.}\.

<S: close  of connection>

A.2.2.  Successful connection

   This example uses an SSL v2 Client Hello, requesting a SSL v3.0
   connection.  The server responds with a SSL v3.0 Server Hello

 C: Sending 138 bytes (SSL v2 Client Hello, requesting SSL v3.0)
0000 : 80 88 01 03 00 00 6f 00 00 00 10 00 00 39 00 00   ......o......9..
0010 : 38 00 00 37 00 00 36 00 00 35 00 00 33 00 00 32   8..7..6..5..3..2
0020 : 00 00 31 00 00 30 00 00 2f 00 00 05 00 00 04 00   ..1..0../.......
0030 : 00 13 00 00 0d 00 00 16 00 00 10 00 00 0a 00 00   ................
0040 : 12 00 00 0c 00 00 15 00 00 0f 00 00 09 00 00 64   ...............d
0050 : 00 00 62 00 00 11 00 00 0b 00 00 14 00 00 0e 00   ..b.............
0060 : 00 08 00 00 03 00 00 06 01 00 80 07 00 c0 03 00   ................
0070 : 80 06 00 40 02 00 80 04 00 80 44 33 0c 65 18 21   ...@......D3.e.!
0080 : bb 61 ee 4f 1b 7e 16 98 b2 2f                     .a.O.~.../

 S : Received 2560 bytes (SSL v3.0 Server Hello)
0000 : 16 03 00 0b 16 02 00 00 46 03 00 31 05 8d 10 01   ........F..1....
0010 : 5c 9c 2b f1 88 e8 e4 fa 42 0c 1a ff 95 df 49 a8   \.+.....B.....I.
0020 : a9 3d 74 35 fe 07 9d b3 6f 61 28 20 09 c3 e4 4e   .=t5....oa( ...N
0030 : e6 27 d1 90 11 55 19 ec 18 37 92 50 0d af 35 3b   .'...U...7.P..5;
0040 : 08 96 0f 53 32 67 e4 65 9e 75 19 62 00 05 00      ...S2g.e.u.b...

A.2.3.  Failed connection

   This example uses an TLS 1.0 Client Hello in a SSL v3.0 record,
   requesting a TLS 1.0 connection.  The server responds with a
   Unexpected Message alert message




Pettersen                Expires April 19, 2007                [Page 14]


Internet-Draft            TLS interoperability              October 2006


 C : Sending 110 bytes (TLS 1.0 Client Hello in SSL v3 record)
0000 : 16 03 00 00 69 01 00 00 65 03 01 44 33 16 76 4f   ....i...e..D3.vO
0010 : 90 61 33 15 6a 75 02 2c 23 70 7e f8 03 67 41 c8   .a3.ju.,#p~..gA.
0020 : 1d 30 22 5b ed be 8c 66 d3 bd 66 00 00 3e 00 39   .0"[...f..f..>.9
0030 : 00 38 00 37 00 36 00 35 00 33 00 32 00 31 00 30   .8.7.6.5.3.2.1.0
0040 : 00 2f 00 05 00 04 00 13 00 0d 00 16 00 10 00 0a   ./..............
0050 : 00 12 00 0c 00 15 00 0f 00 09 00 64 00 62 00 11   ...........d.b..
0060 : 00 0b 00 14 00 0e 00 08 00 03 00 06 01 00         ..............

 S : Received 7 bytes
0000 : 15 03 00 00 02 02 0a                              .......

A.2.4.  Successful connection

   This example uses an SSL v3 Client Hello, requesting a SSL v3.0
   connection.  The server responds with a SSL v3.0 Server Hello
 C : Sending 110 bytes (SSL v3 Client Hello)
0000 : 16 03 00 00 69 01 00 00 65 03 00 44 33 16 77 4b   ....i...e..D3.wK
0010 : fb 0a 6e d5 55 a7 45 86 95 16 01 a7 d2 c9 45 2c   ..n.U.E.......E,
0020 : 42 98 7e 71 59 87 03 72 6f d4 95 00 00 3e 00 39   B.~qY..ro....>.9
0030 : 00 38 00 37 00 36 00 35 00 33 00 32 00 31 00 30   .8.7.6.5.3.2.1.0
0040 : 00 2f 00 05 00 04 00 13 00 0d 00 16 00 10 00 0a   ./..............
0050 : 00 12 00 0c 00 15 00 0f 00 09 00 64 00 62 00 11   ...........d.b..
0060 : 00 0b 00 14 00 0e 00 08 00 03 00 06 01 00         ..............

 S : Received 2560 bytes (SSL v3 Server Hello)
0000 : 16 03 00 0b 16 02 00 00 46 03 00 30 e5 3f e0 52   ........F..0...R
0010 : f1 6a ae 5a a2 5b 51 5e 47 72 3d fa b4 10 0b 80   .j.Z.[Q^Gr=.....
0020 : 8a e1 ee e9 fa bc 72 67 cc 1e d2 20 7c 3b 3d 41   ......rg... |;=A
0030 : 80 77 d2 9f ca 73 81 b8 20 99 97 26 da 52 07 d3   .w...s.. ..&.R..
0040 : df f1 73 c9 14 e2 98 45 9a d2 e1 4c 00 05 00      ..s....E...L...

A.3.  TLS 1.0 server refuses TLS 1.1 client

   Date:  April 25, 2006

   Gateway:  WebSphere

   Site:  https://www.dnbnor.no/

   Highest supported version:  TLS 1.0

   This TLS 1.0 server shuts down the connection when it gets a
   connection request from a TLS 1.1 client.

   According to information provided in private communications with the
   system administrators this site uses a Lotus Domino WebSphere server
   as a front-end, and that is where the connection is cut.



Pettersen                Expires April 19, 2007                [Page 15]


Internet-Draft            TLS interoperability              October 2006


A.3.1.  SSL v2 Client Hello

   This example uses an SSL v2 Client Hello to request a TLS 1.1
   connection, but the server immediately closes the connection without
   any error message.

 C: Sending 138 bytes (SSL v2 Client Hello, TLS 1.1 version requested)
0000 : 80 88 01 03 02 00 6f 00 00 00 10 00 00 39 00 00   ......o......9..
0010 : 38 00 00 37 00 00 36 00 00 35 00 00 33 00 00 32   8..7..6..5..3..2
0020 : 00 00 31 00 00 30 00 00 2f 00 00 05 00 00 04 00   ..1..0../.......
0030 : 00 13 00 00 0d 00 00 16 00 00 10 00 00 0a 00 00   ................
0040 : 12 00 00 0c 00 00 15 00 00 0f 00 00 09 00 00 64   ...............d
0050 : 00 00 62 00 00 11 00 00 0b 00 00 14 00 00 0e 00   ..b.............
0060 : 00 08 00 00 03 00 00 06 01 00 80 07 00 c0 03 00   ................
0070 : 80 06 00 40 02 00 80 04 00 80 44 4e 53 a8 24 1b   ...@......DNS.$.
0080 : 29 8f 20 17 27 74 46 24 f4 d1                     ). .'tF$..

<S: Connection shutdown>

A.3.2.  TLS 1.0 Record, TLS 1.1 Client Hello

   This example uses a TLS 1.0 Client Hello in a TLS 1.0 Record to
   request a TLS 1.1 connection, but the server immediately closes the
   connection without any error message.

 C: 82 bytes
0000 : 16 03 01 00 4d 01 00 00 49 03 02 44 4e 54 c4 e8   ....M...I..DNT..
0010 : 59 f9 9a e4 35 27 4f 95 b0 4b 82 4a 01 71 ea 8e   Y...5'O..K.J.q..
0020 : c0 29 2d 8e 8e f2 07 81 3d f6 4e 00 00 22 00 39   .)-.....=.N..".9
0030 : 00 38 00 37 00 36 00 35 00 33 00 32 00 31 00 30   .8.7.6.5.3.2.1.0
0040 : 00 2f 00 05 00 04 00 13 00 0d 00 16 00 10 00 0a   ./..............
0050 : 01 00                                             ..

<S: connection shutdown>

A.4.  TLS 1.0 server refuses TLS Extensions

   Date:  April 25, 2006

   Gateway:  WebSphere

   Site:  https://www.dnbnor.no/

   Highest supported version:  TLS 1.0

   This server (the same as in Appendix A.3) shuts down the connection
   when it gets a connection request from a TLS 1.0 client with support
   for TLS Extensions.



Pettersen                Expires April 19, 2007                [Page 16]


Internet-Draft            TLS interoperability              October 2006


   According to information provided in private communications with the
   system administrators this site uses a Lotus Domino WebSphere server
   as a front-end, and that is where the connection is cut.

A.4.1.  TLS 1.0 with TLS Extensions

   This example uses a TLS 1.0 Client Hello with a ServerName and a
   Certificate Status TLS Extension in a TLS 1.0 Record to request a TLS
   1.0 connection, but the server immediately closes the connection
   without any error message.

 C: 150 bytes (TLS 1.0 Client Hello, with ServerName and
    Certificate Status TLS Extensions.
0000 : 16 03 01 00 91 01 00 00 8d 03 01 44 4e 54 c4 90   ...........DNT..
0010 : 98 a6 83 92 36 a8 79 6c a3 3f f8 dd 78 74 5b 7e   ....6.yl....xt[~
0020 : 8d fa a7 7d 1f ef 60 1e 99 bb 29 00 00 22 00 39   ...}..`...)..".9
0030 : 00 38 00 37 00 36 00 35 00 33 00 32 00 31 00 30   .8.7.6.5.3.2.1.0
0040 : 00 2f 00 05 00 04 00 13 00 0d 00 16 00 10 00 0a   ./..............
0050 : 01 00 00 42 00 00 00 12 00 10 00 00 0d 77 77 77   ...B.........www
0060 : 2e 64 6e 62 6e 6f 72 2e 6e 6f 00 05 00 28 01 00   .dnbnor.no...(..
0070 : 00 00 23 22 21 30 1f 06 09 2b 06 01 05 05 07 30   ..#"!0...+.....0
0080 : 01 02 04 12 04 10 64 7c 47 2d a1 b1 cb ab ca 36   ......d|G-.....6
0090 : d4 9e a6 64 92 e0                                 ...d..

<S: connection shutdown>

A.5.  Renegotiation with SSL v3 records over TLS 1.0 connection

   Date:  June 5, 2006

   Gateway:  WebSphere

   Site:  https://www.dnbnor.no/

   Highest supported version:  TLS 1.0

   This example was created using a specially modified TLS Client that
   immediately initiate a renegotiation of the TLS session, but does so
   using SSL v3 as the record protocol version, even over a TLS 1.0
   negotiated encrypted connection.  This is based on actual
   observations of a client the author is not associated with.

   When the renegotiation starts the server responds with an SSL v2
   error code, not an SSL v3 or TLS 1.0 error code.  At least one other
   server has been observed throwing TLS errors, as expected, but
   apparently a number of servers actually accept the type of
   negotiation performed in this case




Pettersen                Expires April 19, 2007                [Page 17]


Internet-Draft            TLS interoperability              October 2006


   According to information provided in private communications with the
   system administrators this site uses a Lotus Domino WebSphere server
   as a front-end, and that is where the connection is cut.

C : Sending 82 bytes (Client Hello requesting TLS 1.0 in a
    SSL v3.0  Record)
0000 : 16 03 00 00 4d 01 00 00 49 03 01 44 84 9f de 7c   ....M...I..D...|
0010 : f8 51 49 35 31 0a 0e d8 e1 a8 dc 97 dc 1b 22 b5   .QI51.........".
0020 : 96 96 c1 69 7b 5a 34 83 07 0d 5e 00 00 22 00 39   ...i{Z4...^..".9
0030 : 00 38 00 37 00 36 00 35 00 33 00 32 00 31 00 30   .8.7.6.5.3.2.1.0
0040 : 00 2f 00 05 00 04 00 13 00 0d 00 16 00 10 00 0a   ./..............
0050 : 01 00                                             ..

S : Received 2520 bytes (Server Hello TLS 1.0)
0000 : 16 03 01 0a 99 02 00 00 46 03 01 00 00 00 44 5c   ........F.....D\
0010 : 1d 7d 6a df 62 f0 f4 4c 74 f7 e5 df 31 e6 d2 43   .}j.b..Lt...1..C
0020 : 14 ee 56 9a 48 e9 90 97 56 b6 c6 20 00 00 51 c7   ..V.H...V.. ..Q.
0030 : 87 47 cd 99 56 93 d3 c5 1b f1 86 bb 19 88 59 e9   .G..V.........Y.
0040 : 58 58 58 58 44 84 9f e5 00 02 9b ae 00 35 00      XXXXD........5.

    (Certificate Part 1)
0040 :                                              0b                  .
0050 : 00 0a 47 00 0a 44 00 04 74 30 82 04 70 30 82 03   ..G..D..t0..p0..
0060 : d9 a0 03 02 01 02 02 10 77 f1 5a 9c af fb 1f 6b   ........w.Z....k
0070 : 38 2c 96 5b 53 7b ce aa 30 0d 06 09 2a 86 48 86   8,.[S{..0...*.H.
0080 : f7 0d 01 01 05 05 00 30 81 ba 31 1f 30 1d 06 03   .......0..1.0...
0090 : 55 04 0a 13 16 56 65 72 69 53 69 67 6e 20 54 72   U....VeriSign Tr
00a0 : 75 73 74 20 4e 65 74 77 6f 72 6b 31 17 30 15 06   ust Network1.0..
00b0 : 03 55 04 0b 13 0e 56 65 72 69 53 69 67 6e 2c 20   .U....VeriSign,
00c0 : 49 6e 63 2e 31 33 30 31 06 03 55 04 0b 13 2a 56   Inc.1301..U...*V
00d0 : 65 72 69 53 69 67 6e 20 49 6e 74 65 72 6e 61 74   eriSign Internat
00e0 : 69 6f 6e 61 6c 20 53 65 72 76 65 72 20 43 41 20   ional Server CA
00f0 : 2d 20 43 6c 61 73 73 20 33 31 49 30 47 06 03 55   - Class 31I0G..U
0100 : 04 0b 13 40 77 77 77 2e 76 65 72 69 73 69 67 6e   ...@www.verisign
0110 : 2e 63 6f 6d 2f 43 50 53 20 49 6e 63 6f 72 70 2e   .com/CPS Incorp.
0120 : 62 79 20 52 65 66 2e 20 4c 49 41 42 49 4c 49 54   by Ref. LIABILIT
0130 : 59 20 4c 54 44 2e 28 63 29 39 37 20 56 65 72 69   Y LTD.(c)97 Veri
0140 : 53 69 67 6e 30 1e 17 0d 30 35 30 39 30 35 30 30   Sign0...05090500
0150 : 30 30 30 30 5a 17 0d 30 37 30 39 30 35 32 33 35   0000Z..070905235
0160 : 39 35 39 5a 30 81 a8 31 0b 30 09 06 03 55 04 06   959Z0..1.0...U..
0170 : 13 02 4e 4f 31 0f 30 0d 06 03 55 04 08 13 06 42   ..NO1.0...U....B
0180 : 65 72 67 65 6e 31 10 30 0e 06 03 55 04 07 14 07   ergen1.0...U....
0190 : 53 61 6e 64 73 6c 69 31 15 30 13 06 03 55 04 0a   Sandsli1.0...U..
01a0 : 14 0c 45 44 42 20 49 54 20 44 72 69 66 74 31 12   ..EDB IT Drift1.
01b0 : 30 10 06 03 55 04 0b 14 09 44 6e 42 4e 4f 52 20   0...U....DnBNOR
01c0 : 49 54 31 33 30 31 06 03 55 04 0b 14 2a 54 65 72   IT1301..U...*Ter
01d0 : 6d 73 20 6f 66 20 75 73 65 20 61 74 20 77 77 77   ms of use at www
01e0 : 2e 76 65 72 69 73 69 67 6e 2e 63 6f 6d 2f 72 70   .verisign.com/rp



Pettersen                Expires April 19, 2007                [Page 18]


Internet-Draft            TLS interoperability              October 2006


01f0 : 61 20 28 63 29 30 30 31 16 30 14 06 03 55 04 03   a (c)001.0...U..
0200 : 14 0d 77 77 77 2e 64 6e 62 6e 6f 72 2e 6e 6f 30   ..www.dnbnor.no0
0210 : 81 9f 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05   ..0...*.H.......
0220 : 00 03 81 8d 00 30 81 89 02 81 81 00 b5 b5 b1 17   .....0..........
0230 : 6d c0 e4 78 64 7d 89 7d e9 fa 62 1b 6b 59 d4 39   m..xd}.}..b.kY.9
0240 : 8e 5a 78 d5 50 2b 5a 3d c7 5b 02 87 df 67 51 0f   .Zx.P+Z=.[...gQ.
0250 : b2 d9 43 6e 00 33 c3 88 fb 4e ac 31 85 82 ca a6   ..Cn.3...N.1....
0260 : 96 84 9c 99 64 fa 44 b6 c5 3e 87 bb 81 72 25 b0   ....d.D..>...r%.
0270 : de a5 27 5d 9d 17 e5 c7 73 6a 08 7e 90 c4 b9 e2   ..']....sj.~....
0280 : 78 f1 70 b5 06 44 4d 4d 60 fa e8 b8 a0 6b 04 11   x.p..DMM`....k..
0290 : 7e 4e f2 61 79 57 ad 0f a1 2d b8 b5 1b ea d2 a5   ~N.ayW...-......
02a0 : 96 28 53 cc 6b f8 f1 4c 15 5b 4b 17 02 03 01 00   .(S.k..L.[K.....
02b0 : 01 a3 82 01 85 30 82 01 81 30 09 06 03 55 1d 13   .....0...0...U..
02c0 : 04 02 30 00 30 0b 06 03 55 1d 0f 04 04 03 02 05   ..0.0...U.......
02d0 : a0 30 46 06 03 55 1d 1f 04 3f 30 3d 30 3b a0 39   .0F..U....0=0;.9
02e0 : a0 37 86 35 68 74 74 70 3a 2f 2f 63 72 6c 2e 76   .7.5http://crl.v
02f0 : 65 72 69 73 69 67 6e 2e 63 6f 6d 2f 43 6c 61 73   erisign.com/Clas
0300 : 73 33 49 6e 74 65 72 6e 61 74 69 6f 6e 61 6c 53   s3InternationalS
0310 : 65 72 76 65 72 2e 63 72 6c 30 44 06 03 55 1d 20   erver.crl0D..U.
0320 : 04 3d 30 3b 30 39 06 0b 60 86 48 01 86 f8 45 01   .=0;09..`.H...E.
0330 : 07 17 03 30 2a 30 28 06 08 2b 06 01 05 05 07 02   ...0*0(..+......
0340 : 01 16 1c 68 74 74 70 73 3a 2f 2f 77 77 77 2e 76   ...https://www.v
0350 : 65 72 69 73 69 67 6e 2e 63 6f 6d 2f 72 70 61 30   erisign.com/rpa0
0360 : 34 06 03 55 1d 25 04 2d 30 2b 06 09 60 86 48 01   4..U.%.-0+..`.H.
0370 : 86 f8 42 04 01 06 0a 2b 06 01 04 01 82 37 0a 03   ..B....+.....7..
0380 : 03 06 08 2b 06 01 05 05 07 03 01 06 08 2b 06 01   ...+.........+..
0390 : 05 05 07 03 02 30 34 06 08 2b 06 01 05 05 07 01   .....04..+......
03a0 : 01 04 28 30 26 30 24 06 08 2b 06 01 05 05 07 30   ..(0&0$..+.....0
03b0 : 01 86 18 68 74 74 70 3a 2f 2f 6f 63 73 70 2e 76   ...http://ocsp.v
03c0 : 65 72 69 73 69 67 6e 2e 63 6f 6d 30 6d 06 08 2b   erisign.com0m..+
03d0 : 06 01 05 05 07 01 0c 04 61 30 5f a1 5d a0 5b 30   ........a0_.].[0
03e0 : 59 30 57 30 55 16 09 69 6d 61 67 65 2f 67 69 66   Y0W0U..image/gif
03f0 : 30 21 30 1f 30 07 06 05 2b 0e 03 02 1a 04 14 8f   0!0.0...+.......
0400 : e5 d3 1a 86 ac 8d 8e 6b c3 cf 80 6a d4 48 18 2c   .......k...j.H.,
0410 : 7b 19 2e 30 25 16 23 68 74 74 70 3a 2f 2f 6c 6f   {..0%.#http://lo
0420 : 67 6f 2e 76 65 72 69 73 69 67 6e 2e 63 6f 6d 2f   go.verisign.com/
0430 : 76 73 6c 6f 67 6f 2e 67 69 66 30 0d 06 09 2a 86   vslogo.gif0...*.
0440 : 48 86 f7 0d 01 01 05 05 00 03 81 81 00 45 bc 3c   H............E.<
0450 : a1 80 f8 f9 30 d4 97 09 dd 21 22 55 13 b1 a7 fd   ....0....!"U....
0460 : b2 c4 7a 13 6a 65 7d 86 f1 5f ec 9a 27 e3 bf da   ..z.je}.._..'...
0470 : 0c e7 cc 64 cd b5 21 0e d1 5e 77 80 8f 73 6c b0   ...d..!..^w..sl.
0480 : 1b d9 1b 70 e2 c5 46 22 0a d3 c5 9e 42 6e 16 20   ...p..F"....Bn.
0490 : 43 e7 c3 a2 7c 9c 7a c0 f5 be c3 d5 a5 4f 3e 78   C...|.z......O>x
04a0 : 2d f8 ac 7c 8f 05 73 66 cb 81 a0 42 28 f8 06 01   -..|..sf...B(...
04b0 : 3a b5 8c 6c 34 1e d0 61 58 43 25 e0 fc d1 46 4d   :..l4..aXC%...FM
04c0 : 7e 1b 36 23 03 bb d6 4d 61 d8 d7 aa 05 00 03 87   ~.6#...Ma.......
04d0 : 30 82 03 83 30 82 02 ec a0 03 02 01 02 02 10 25   0...0..........%
04e0 : 4b 8a 85 38 42 cc e3 58 f8 c5 dd ae 22 6e a4 30   K..8B..X...."n.0



Pettersen                Expires April 19, 2007                [Page 19]


Internet-Draft            TLS interoperability              October 2006


04f0 : 0d 06 09 2a 86 48 86 f7 0d 01 01 05 05 00 30 5f   ...*.H........0_
0500 : 31 0b 30 09 06 03 55 04 06 13 02 55 53 31 17 30   1.0...U....US1.0
0510 : 15 06 03 55 04 0a 13 0e 56 65 72 69 53 69 67 6e   ...U....VeriSign
0520 : 2c 20 49 6e 63 2e 31 37 30 35 06 03 55 04 0b 13   , Inc.1705..U...
0530 : 2e 43 6c 61 73 73 20 33 20 50 75 62 6c 69 63 20   .Class 3 Public
0540 : 50 72 69 6d 61 72 79 20 43 65 72 74 69 66 69 63   Primary Certific
0550 : 61 74 69 6f 6e 20 41 75 74 68 6f 72 69 74 79 30   ation Authority0
0560 : 1e 17 0d 39 37 30 34 31 37 30 30 30 30 30 30 5a   ...970417000000Z
0570 : 17 0d 31 31 31 30 32 34 32 33 35 39 35 39 5a 30   ..111024235959Z0
0580 : 81 ba 31 1f 30 1d 06 03 55 04 0a 13 16 56 65 72   ..1.0...U....Ver
0590 : 69 53 69 67 6e 20 54 72 75 73 74 20 4e 65 74 77   iSign Trust Netw
05a0 : 6f 72 6b 31 17 30 15 06 03 55 04 0b 13 0e 56 65   ork1.0...U....Ve
05b0 : 72 69 53 69 67 6e 2c 20 49 6e 63 2e 31 33 30 31   riSign, Inc.1301
05c0 : 06 03 55 04 0b 13 2a 56 65 72 69 53 69 67 6e 20   ..U...*VeriSign
05d0 : 49 6e 74 65 72 6e 61 74 69 6f 6e 61 6c 20 53 65   International Se
05e0 : 72 76 65 72 20 43 41 20 2d 20 43 6c 61 73 73 20   rver CA - Class
05f0 : 33 31 49 30 47 06 03 55 04 0b 13 40 77 77 77 2e   31I0G..U...@www.
0600 : 76 65 72 69 73 69 67 6e 2e 63 6f 6d 2f 43 50 53   verisign.com/CPS
0610 : 20 49 6e 63 6f 72 70 2e 62 79 20 52 65 66 2e 20    Incorp.by Ref.
0620 : 4c 49 41 42 49 4c 49 54 59 20 4c 54 44 2e 28 63   LIABILITY LTD.(c
0630 : 29 39 37 20 56 65 72 69 53 69 67 6e 30 81 9f 30   )97 VeriSign0..0
0640 : 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 81   ...*.H..........
0650 : 8d 00 30 81 89 02 81 81 00 d8 82 80 e8 d6 19 02   ..0.............
0660 : 7d 1f 85 18 39 25 a2 65 2b e1 bf d4 05 d3 bc e6   }...9%.e+.......
0670 : 36 3b aa f0 4c 6c 5b b6 e7 aa 3c 73 45 55 b2 f1   6;..Ll[...<sEU..
0680 : bd ea 97 42 ed 9a 34 0a 15 d4 a9 5c f5 40 25 dd   ...B..4....\.@%.
0690 : d9 07 c1 32 b2 75 6c c4 ca bb a3 fe 56 27 71 43   ...2.ul.....V'qC
06a0 : aa 63 f5 30 3e 93 28 e5 fa f1 09 3b f3 b7 4d 4e   .c.0>.(....;..MN
06b0 : 39 f7 5c 49 5a b8 c1 1d d3 b2 8a fe 70 30 95 42   9.\IZ.......p0.B
06c0 : cb fe 2b 51 8b 5a 3c 3a f9 22 4f 90 b2 02 a7 53   ..+Q.Z<:."O....S
06d0 : 9c 4f 34 e7 ab 04 b2 7b 6f 02 03 01 00 01 a3 81   .O4....{o.......
06e0 : e3 30 81 e0 30 0f 06 03 55 1d 13 04 08 30 06 01   .0..0...U....0..
06f0 : 01 ff 02 01 00 30 44 06 03 55 1d 20 04 3d 30 3b   .....0D..U. .=0;
0700 : 30 39 06 0b 60 86 48 01 86 f8 45 01 07 01 01 30   09..`.H...E....0
0710 : 2a 30 28 06 08 2b 06 01 05 05 07 02 01 16 1c 68   *0(..+.........h
0720 : 74 74 70 73 3a 2f 2f 77 77 77 2e 76 65 72 69 73   ttps://www.veris
0730 : 69 67 6e 2e 63 6f 6d 2f 43 50 53 30 34 06 03 55   ign.com/CPS04..U
0740 : 1d 25 04 2d 30 2b 06 08 2b 06 01 05 05 07 03 01   .%.-0+..+.......
0750 : 06 08 2b 06 01 05 05 07 03 02 06 09 60 86 48 01   ..+.........`.H.
0760 : 86 f8 42 04 01 06 0a 60 86 48 01 86 f8 45 01 08   ..B....`.H...E..
0770 : 01 30 0b 06 03 55 1d 0f 04 04 03 02 01 06 30 11   .0...U........0.
0780 : 06 09 60 86 48 01 86 f8 42 01 01 04 04 03 02 01   ..`.H...B.......
0790 : 06 30 31 06 03 55 1d 1f 04 2a 30 28 30 26 a0 24   .01..U...*0(0&.$
07a0 : a0 22 86 20 68 74 74 70 3a 2f 2f 63 72 6c 2e 76   .". http://crl.v
07b0 : 65 72 69 73 69 67 6e 2e 63 6f 6d 2f 70 63 61 33   erisign.com/pca3
07c0 : 2e 63 72 6c 30 0d 06 09 2a 86 48 86 f7 0d 01 01   .crl0...*.H.....
07d0 : 05 05 00 03 81 81 00 08 01 ec e4 68 94 03 42 f1   ...........h..B.
07e0 : 73 f1 23 a2 3a de e9 f1 da c6 54 c4 23 3e 86 ea   s.#.:.....T.#>..



Pettersen                Expires April 19, 2007                [Page 20]


Internet-Draft            TLS interoperability              October 2006


07f0 : cf 6a 3a 33 ab ea 9c 04 14 07 36 06 0b f9 88 6f   .j:3......6....o
0800 : d5 13 ee 29 2b c3 e4 72 8d 44 ed d1 ac 20 09 2d   ...)+..r.D... .-
0810 : e1 f6 e1 19 05 38 b0 3d 0f 9f 7f f8 9e 02 dc 86   .....8.=........
0820 : 02 86 61 4e 26 5f 5e 9f 92 1e 0c 24 a4 f5 d0 70   ..aN&_^....$...p
0830 : 13 cf 26 c3 43 3d 49 1d 9e 82 2e 52 5f bc 3e c6   ..&.C=I....R_.>.
0840 : 66 29 01 8e 4e 92 2c bc 46 75 03 82 ac 73 e9 d9   f)..N.,.Fu...s..
0850 : 7e 0b 67 ef 54 52 1a 00 02 40 30 82 02 3c 30 82   ~.g.TR...@0..<0.
0860 : 01 a5 02 10 70 ba e4 1d 10 d9 29 34 b6 38 ca 7b   ....p.....)4.8.{
0870 : 03 cc ba bf 30 0d 06 09 2a 86 48 86 f7 0d 01 01   ....0...*.H.....
0880 : 02 05 00 30 5f 31 0b 30 09 06 03 55 04 06 13 02   ...0_1.0...U....
0890 : 55 53 31 17 30 15 06 03 55 04 0a 13 0e 56 65 72   US1.0...U....Ver
08a0 : 69 53 69 67 6e 2c 20 49 6e 63 2e 31 37 30 35 06   iSign, Inc.1705.
08b0 : 03 55 04 0b 13 2e 43 6c 61 73 73 20 33 20 50 75   .U....Class 3 Pu
08c0 : 62 6c 69 63 20 50 72 69 6d 61 72 79 20 43 65 72   blic Primary Cer
08d0 : 74 69 66 69 63 61 74 69 6f 6e 20 41 75 74 68 6f   tification Autho
08e0 : 72 69 74 79 30 1e 17 0d 39 36 30 31 32 39 30 30   rity0...96012900
08f0 : 30 30 30 30 5a 17 0d 32 38 30 38 30 31 32 33 35   0000Z..280801235
0900 : 39 35 39 5a 30 5f 31 0b 30 09 06 03 55 04 06 13   959Z0_1.0...U...
0910 : 02 55 53 31 17 30 15 06 03 55 04 0a 13 0e 56 65   .US1.0...U....Ve
0920 : 72 69 53 69 67 6e 2c 20 49 6e 63 2e 31 37 30 35   riSign, Inc.1705
0930 : 06 03 55 04 0b 13 2e 43 6c 61 73 73 20 33 20 50   ..U....Class 3 P
0940 : 75 62 6c 69 63 20 50 72 69 6d 61 72 79 20 43 65   ublic Primary Ce
0950 : 72 74 69 66 69 63 61 74 69 6f 6e 20 41 75 74 68   rtification Auth
0960 : 6f 72 69 74 79 30 81 9f 30 0d 06 09 2a 86 48 86   ority0..0...*.H.
0970 : f7 0d 01 01 01 05 00 03 81 8d 00 30 81 89 02 81   ...........0....
0980 : 81 00 c9 5c 59 9e f2 1b 8a 01 14 b4 10 df 04 40   ...\Y..........@
0990 : db e3 57 af 6a 45 40 8f 84 0c 0b d1 33 d9 d9 11   ..W.jE@.....3...
09a0 : cf ee 02 58 1f 25 f7 2a a8 44 05 aa ec 03 1f 78   ...X.%.*.D.....x
09b0 : 7f 9e 93 b9 9a 00 aa 23 7d d6 ac 85 a2 63 45 c7   .......#}....cE.
09c0 : 72 27 cc f4 4c c6 75 71 d2 39 ef 4f 42 f0 75 df   r'..L.uq.9.OB.u.
09d0 : 0a 90 c6 8e 20 6f 98 0f                           .... o..

S : received 198 bytes (Certificate part 2)
0000 : f8 ac 23 5f 70 29 36 a4 c9 86 e7 b1 9a 20 cb 53   ..#_p)6...... .S
0010 : a5 85 e7 3d be 7d 9a fe 24 45 33 dc 76 15 ed 0f   ...=.}..$E3.v...
0020 : a2 71 64 4c 65 2e 81 68 45 a7 02 03 01 00 01 30   .qdLe..hE......0
0030 : 0d 06 09 2a 86 48 86 f7 0d 01 01 02 05 00 03 81   ...*.H..........
0040 : 81 00 bb 4c 12 2b cf 2c 26 00 4f 14 13 dd a6 fb   ...L.+.,&.O.....
0050 : fc 0a 11 84 8c f3 28 1c 67 92 2f 7c b6 c5 fa df   ......(.g./|....
0060 : f0 e8 95 bc 1d 8f 6c 2c a8 51 cc 73 d8 a4 c0 53   ......l,.Q.s...S
0070 : f0 4e d6 26 c0 76 01 57 81 92 5e 21 f1 d1 b1 ff   .N.&.v.W..^!....
0080 : e7 d0 21 58 cd 69 17 e3 44 1c 9c 19 44 39 89 5c   ..!X.i..D...D9.\
0090 : dc 9c 00 0f 56 8d 02 99 ed a2 90 45 4c e4 bb 10   ....V......EL...
00a0 : a4 3d f0 32 03 0e f1 ce f8 e8 c9 51 8c e6 62 9f   .=.2.......Q..b.
00b0 : e6 9f c0 7d b7 72 9c c9 36 3a 6b 9f 4e a8 ff 64   ...}.r..6:k.N..d
00c0 : 0d 64                                             .d

    (Hello Done)



Pettersen                Expires April 19, 2007                [Page 21]


Internet-Draft            TLS interoperability              October 2006


00c0 :       0e 00 00 00                                   ....


C : Sending 139 bytes (Client Key exchange)
0000 : 16 03 01 00 86 10 00 00 82 00 80 43 4b e5 84 c9   ...........CK...
0010 : 27 e9 b3 6b 04 d4 54 a7 33 83 70 9f e1 80 c5 24   '..k..T.3.p....$
0020 : fc 3e 9d fe 3d 11 64 14 64 f9 e2 30 68 1e 4d c6   .>..=.d.d..0h.M.
0030 : 2d 16 5f a0 25 1e 6a 51 cf 32 42 00 2c 5e e9 58   -._.%.jQ.2B.,^.X
0040 : cc 33 ad 2e 9b e9 6b 12 5c 23 ac b1 37 9b 4a 2b   .3....k.\#..7.J+
0050 : 28 f9 57 d9 92 89 01 f3 6b 94 a3 18 dc f6 1f e1   (.W.....k.......
0060 : f0 68 de 54 de f0 58 e3 7a 58 09 dd 3b 07 f7 df   .h.T..X.zX..;...
0070 : 5b 62 04 73 38 7c 6c 00 81 61 e7 85 a6 32 9d 45   [b.s8|l..a...2.E
0080 : 6b f4 34 00 7d cf d7 7b d0 3e da                  k.4.}..{.>.

C : Sending 6 bytes (Cipher Change)
0000 : 14 03 01 00 01 01                                 ......

C : Plaintext 16 bytes (Finished)
0000 : 14 00 00 0c 7c cf 8d 7b 62 76 ab 9a ae b6 e5 6e   ....|..{bv.....n

C : Sending 53 bytes (Encrypted Finished)
0000 : 16 03 01 00 30 6f fd 31 80 51 a9 3d 18 7d 55 ef   ....0o.1.Q.=.}U.
0010 : 7c 6c 80 07 b2 79 6a 06 39 79 7e 15 7d e8 ee 1f   |l...yj.9y~.}...
0020 : fd be 68 6a af e2 cd db 47 f9 a6 b8 20 26 b9 03   ..hj....G... &..
0030 : 12 ec d3 c3 fd                                    .....

S : Received 6 bytes  (Cipher Change)
0000 : 14 03 01 00 01 01                                 ......

S : Received 53 bytes  (Encrypted Finished)
0000 : 16 03 01 00 30 a4 11 4c 05 28 3b cc 39 d3 aa 63   ....0..L.(;.9..c
0010 : bc 9d 74 f8 9b 8e 1c 6b 5c ee f2 4b 82 e9 ce c9   ..t....k\..K....
0020 : ce 73 b9 28 c2 2d 84 92 a3 70 5b 5b a8 8b 4f 86   .s.(.-...p[[..O.
0030 : 59 90 bf 39 9f                                    Y..9.

S : Plaintext 16 bytes (Plaintext Finished)
0000 : 14 00 00 0c 78 40 33 0f ae eb f4 e4 19 bd e8 66   ....x@3........f

C : Plaintext 109 bytes (Client Hello requesting TLS 1.0)
0000 : 01 00 00 69 03 01 44 84 9f e0 38 4e 2b 3c 01 4d   ...i..D...8N+<.M
0010 : d2 9c c0 03 fd 1f 92 f4 b7 d2 27 61 9e 68 a2 bf   ..........'a.h..
0020 : 7d fc f2 98 5d d6 20 00 00 51 c7 87 47 cd 99 56   }...]. ..Q..G..V
0030 : 93 d3 c5 1b f1 86 bb 19 88 59 e9 58 58 58 58 44   .........Y.XXXXD
0040 : 84 9f e5 00 02 9b ae 00 22 00 35 00 39 00 38 00   ........".5.9.8.
0050 : 37 00 33 00 32 00 31 00 30 00 2f 00 05 00 04 00   7.3.2.1.0./.....
0060 : 13 00 0d 00 16 00 10 00 0a 00 00 01 00            .............

C : Sending 149 bytes (Encrypted Client Hello,



Pettersen                Expires April 19, 2007                [Page 22]


Internet-Draft            TLS interoperability              October 2006


    SSL v3.0 record protocol over TLS 1.0 encrypted connection)
0000 : 16 03 00 00 90 d6 39 9d 73 59 a4 88 61 9d ea f6   ......9.sY..a...
0010 : 43 f0 96 12 86 5d 50 fb 81 8d e7 c5 7d 57 1b d5   C....]P.....}W..
0020 : a6 f7 24 a9 9d b0 a4 5c 93 60 c3 6a 8f d5 b5 1b   ..$....\.`.j....
0030 : e1 96 af 8f 2e 94 0a 69 05 0c e2 8c 0d c5 a5 31   .......i.......1
0040 : 6f 2b 41 77 8e e8 d3 8e 16 96 87 b7 3d 9d 83 1b   o+Aw........=...
0050 : 1e 04 15 27 80 8e 67 05 d3 ee 9f 82 63 13 10 a0   ...'..g.....c...
0060 : 29 70 ce c4 9e c0 22 94 15 39 d8 07 fd 88 0c bb   )p...."..9......
0070 : ff 00 26 34 1f 63 f1 fc 36 5f 30 fe 51 ef f4 78   ..&4.c..6_0.Q..x
0080 : dd df f1 7b c2 91 f9 29 e4 e2 5c 1f 10 98 b8 c8   ...{...)..\.....
0090 : ec cc 13 d9 da                                    .....

S : Received 5 bytes (SSL v2 Error message)
0000 : 80 03 00 00 01                                    .....

A.6.  Wrong version expected in RSA Client Key Exchange

   Date:  June 15, 2006

   Server:  Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 (Unix)

   Site:  https://www.gotogate.no/

   Highest supported version:  TLS 1.0

   This server negotiates a TLS 1.0 connection when TLS 1.1 is offered,
   but after receiving the RSA Client Key Exchange the server sends a
   handshake error and closes the connection, as seen in Appendix A.6.1.
   The reason for the error is that the server expects the negotiated
   version to be used in the Premaster Secret, not the version used in
   the Client Hello, as seen in Appendix A.6.2

A.6.1.  Correct Premaster - Connection Failure

   This is a normal TLS handshake requesting a TLS 1.1 connection from
   the server.  The server selects TLS 1.0, but reports a handshake
   failure after the Client Key Exchange message has been sent.

C : Sending 82 bytes (Client Hello Requesting TLS 1.1,
    in a TLS 1.0 Record)
0000 : 16 03 01 00 4d 01 00 00 49 03 02 44 90 b9 63 a2   ....M...I..D..c.
0010 : 1b bd 07 1d 01 55 3f 8a 9e c9 0a a1 99 dc 8a 1b   .....U...?.?....
0020 : d8 62 dc 07 bc 0c 58 99 0c e0 a4 00 00 22 00 39   .b....X..?...".9
0030 : 00 38 00 37 00 36 00 35 00 33 00 32 00 31 00 30   .8.7.6.5.3.2.1.0
0040 : 00 2f 00 05 00 04 00 13 00 0d 00 16 00 10 00 0a   ./..............
0050 : 01 00                                             ..

S : Received 948 bytes (Server hello)



Pettersen                Expires April 19, 2007                [Page 23]


Internet-Draft            TLS interoperability              October 2006


0000 : 16 03 01 00 4a 02 00 00 46 03 01 44 90 b8 cb 2f   ....J...F..D.??/
0010 : e2 a7 3e 22 f8 af 5d 62 ca ab c1 6a c1 16 5f 88   ?.>".?]b?.?j?._.
0020 : 64 81 5d 24 52 8b 2f 72 6d 97 c9 20 71 09 06 7d   d.]$R./rm.? q..}
0030 : 64 a4 8a ce e7 4c 4b bc 20 e5 db 5e 49 46 9d 51   d..??LK. .?^IF.Q
0040 : 01 bb f6 e1 4c e5 f6 0e bb b9 23 6f 00 05 00      ..........#o...

    (Certificate)
0040 :                                              16                  .
0050 : 03 01 03 57 0b 00 03 53 00 03 50 00 03 4d 30 82   ...W...S..P..M0.
0060 : 03 49 30 82 02 b2 a0 03 02 01 02 02 03 3f 84 41   .I0...?........A
0070 : 30 0d 06 09 2a 86 48 86 f7 0d 01 01 04 05 00 30   0...*.H.?......0
0080 : 81 ce 31 0b 30 09 06 03 55 04 06 13 02 5a 41 31   .?1.0...U....ZA1
0090 : 15 30 13 06 03 55 04 08 13 0c 57 65 73 74 65 72   .0...U....Wester
00a0 : 6e 20 43 61 70 65 31 12 30 10 06 03 55 04 07 13   n Cape1.0...U...
00b0 : 09 43 61 70 65 20 54 6f 77 6e 31 1d 30 1b 06 03   .Cape Town1.0...
00c0 : 55 04 0a 13 14 54 68 61 77 74 65 20 43 6f 6e 73   U....Thawte Cons
00d0 : 75 6c 74 69 6e 67 20 63 63 31 28 30 26 06 03 55   ulting cc1(0&..U
00e0 : 04 0b 13 1f 43 65 72 74 69 66 69 63 61 74 69 6f   ....Certificatio
00f0 : 6e 20 53 65 72 76 69 63 65 73 20 44 69 76 69 73   n Services Divis
0100 : 69 6f 6e 31 21 30 1f 06 03 55 04 03 13 18 54 68   ion1!0...U....Th
0110 : 61 77 74 65 20 50 72 65 6d 69 75 6d 20 53 65 72   awte Premium Ser
0120 : 76 65 72 20 43 41 31 28 30 26 06 09 2a 86 48 86   ver CA1(0&..*.H.
0130 : f7 0d 01 09 01 16 19 70 72 65 6d 69 75 6d 2d 73   ?......premium-s
0140 : 65 72 76 65 72 40 74 68 61 77 74 65 2e 63 6f 6d   erver@thawte.com
0150 : 30 1e 17 0d 30 35 30 36 32 31 31 31 30 37 33 39   0...050621110739
0160 : 5a 17 0d 30 36 30 36 32 31 31 31 30 37 33 39 5a   Z..060621110739Z
0170 : 30 5b 31 0b 30 09 06 03 55 04 06 13 02 4e 4f 31   0[1.0...U....NO1
0180 : 0d 30 0b 06 03 55 04 08 13 04 4f 73 6c 6f 31 0d   .0...U....Oslo1.
0190 : 30 0b 06 03 55 04 07 13 04 4f 73 6c 6f 31 14 30   0...U....Oslo1.0
01a0 : 12 06 03 55 04 0a 13 0b 47 4f 54 4f 47 41 54 45   ...U....GOTOGATE
01b0 : 20 41 53 31 18 30 16 06 03 55 04 03 13 0f 77 77    AS1.0...U....ww
01c0 : 77 2e 67 6f 74 6f 67 61 74 65 2e 6e 6f 30 81 9f   w.gotogate.no0..
01d0 : 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03   0...*.H.?.......
01e0 : 81 8d 00 30 81 89 02 81 81 00 ca e1 b4 e6 2a cb   ...0......???.*?
01f0 : 27 c0 d3 17 d0 f8 8b 91 62 f9 97 84 86 b5 9e 0b   '??.....b?......
0200 : 1d df 97 b1 ce 7e 12 25 59 f2 80 d2 bf 8e 7b 56   ....?~.%Y?.??.{V
0210 : d0 cb 3c 1a ba c9 c6 0f 50 5b 17 b6 fd 66 ed c3   .?<.??..P[..?f??
0220 : 32 29 9b cd bb fd a4 9a 5a c1 67 48 2e 61 fa a6   2).?.?..Z?gH.a??
0230 : 48 1d ef 63 3c 97 38 6e a5 48 4c d8 e1 fe ec ec   H.?c<.8n.HL.?.??
0240 : ce 49 5a 86 54 43 ff 40 f2 8e 4c 26 35 d8 a3 19   ?IZ.TC?@?.L&5...
0250 : c6 e1 b9 6e ac 45 17 1d 37 32 85 18 d0 e3 41 d8   .?.n.E..72...?A.
0260 : c3 21 7b 67 e7 4f 37 64 f8 a9 02 03 01 00 01 a3   ?!{g?O7d........
0270 : 81 a6 30 81 a3 30 1d 06 03 55 1d 25 04 16 30 14   .?0..0...U.%..0.
0280 : 06 08 2b 06 01 05 05 07 03 01 06 08 2b 06 01 05   ..+.........+...
0290 : 05 07 03 02 30 40 06 03 55 1d 1f 04 39 30 37 30   ....0@..U...9070
02a0 : 35 a0 33 a0 31 86 2f 68 74 74 70 3a 2f 2f 63 72   5?3?1./http://cr
02b0 : 6c 2e 74 68 61 77 74 65 2e 63 6f 6d 2f 54 68 61   l.thawte.com/Tha
02c0 : 77 74 65 50 72 65 6d 69 75 6d 53 65 72 76 65 72   wtePremiumServer



Pettersen                Expires April 19, 2007                [Page 24]


Internet-Draft            TLS interoperability              October 2006


02d0 : 43 41 2e 63 72 6c 30 32 06 08 2b 06 01 05 05 07   CA.crl02..+.....
02e0 : 01 01 04 26 30 24 30 22 06 08 2b 06 01 05 05 07   ...&0$0"..+.....
02f0 : 30 01 86 16 68 74 74 70 3a 2f 2f 6f 63 73 70 2e   0...http://ocsp.
0300 : 74 68 61 77 74 65 2e 63 6f 6d 30 0c 06 03 55 1d   thawte.com0...U.
0310 : 13 01 01 ff 04 02 30 00 30 0d 06 09 2a 86 48 86   ...?..0.0...*.H.
0320 : f7 0d 01 01 04 05 00 03 81 81 00 60 28 92 bc 07   ?..........`(...
0330 : 1f 96 76 d8 26 bd 10 59 8a 02 17 f3 a3 60 bc fc   ..v.&..Y...?.`..
0340 : 2a 4e b1 41 17 85 b3 b2 b0 4d db 43 d8 a4 f2 a9   *N.A....?M?C..?.
0350 : 7d 41 80 6d e7 fd ac 13 65 59 8c f3 81 6b 7c 0a   }A.m??..eY.?.k|.
0360 : b7 17 0d 00 4e 71 f4 84 f5 d2 30 b1 98 34 4b 2c   ?...Nq?.??0..4K,
0370 : b0 d0 0b 6d 85 e9 4d 6d 10 56 90 bd 36 b5 f3 5e   ?..m.?Mm.V..6.?^
0380 : ed 21 72 93 21 fc 90 d9 78 92 08 8b 6b b2 e9 0c   ?!r.!..?x...k.?.
0390 : 5a 19 54 b9 1a c9 ed c2 59 72 44 d3 13 57 08 15   Z.T..???YrD?.W..
03a0 : 1a 32 dd d9 53 23 85 76 d1 1c 0d 16 03 01 00 04   .2??S#.v?.......

    (Hello Done)
03b0 : 0e 00 00 00                                       ....

C : Plain Premaster Secret (correct version v3.2, from Client Hello)
0000 : 03 02 93 99 39 68 bc 45 f3 a0 d9 1e cd d5 bc 51   ....9h.E???.??.Q
0010 : 6b 79 b4 c5 c9 98 52 44 c0 57 ba 60 67 b3 bb dd   ky?.?.RD?W?`g..?
0020 : 05 56 e8 79 93 78 39 ba 44 27 7e 1d 07 46 6b 4d   .V?y.x9?D'~..FkM

C : Sending 139 bytes (Client Key Exchange)
0000 : 16 03 01 00 86 10 00 00 82 00 80 17 2c 16 c7 3b   ............,.?;
0010 : fc c9 29 da e1 21 37 c6 86 93 46 2c 94 1d b8 eb   .?)??!7...F,..??
0020 : 06 8a 78 05 80 af 60 5b 6b 73 fb c1 56 b4 8e 21   ..x..?`[ks??V?.!
0030 : 91 56 51 62 9d f0 b1 f6 28 45 5a 25 ab 7e 4e 1d   .VQb....(EZ%.~N.
0040 : 2c 93 e4 01 f5 3e df d3 31 5b 3e b8 41 95 21 95   ,...?>.?1[>?A.!.
0050 : e5 c4 d0 5b 6f 12 36 eb c8 44 8f 16 cf a3 9a c8   ...[o.6??D..?..?
0060 : 8a 70 bc 60 b2 ca 1d d3 1b 8b d3 49 4f 0a 72 d7   .p.`.?.?..?IO.r?
0070 : ca 87 99 1b 73 4d 1b 32 bc ed 9a 6f 85 da f3 bd   ?...sM.2.?.o.??.
0080 : c7 d5 a5 e4 e7 13 9d 9b a4 a3 27                  ??..?.....'

C : Sending 6 bytes (Cipher Change)
0000 : 14 03 01 00 01 01                                 ......

C : Plaintext 16 bytes (Finished)
0000 : 14 00 00 0c c4 be 77 0b e5 a1 c1 7c 17 e8 67 04   ......w..??|.?g.

C : Sending 41 bytes (Encrypted Finished)
0000 : 16 03 01 00 24 ee 6c e2 94 6e 17 d0 7f 86 dd a0   ....$?l?.n....??
0010 : 1b 09 18 4c 6b ed be 1e 22 38 a6 08 56 56 18 66   ...Lk?.."8?.VV.f
0020 : 31 bd 78 8d 7e c5 27 77 f0                        1.x.~.'w.

S : Received 7 bytes (Handshake Failure Alert, 20)
0000 : 15 03 01 00 02 02 14                              .......




Pettersen                Expires April 19, 2007                [Page 25]


Internet-Draft            TLS interoperability              October 2006


A.6.2.  Wrong Premaster - Connection Success

   This example uses the same handshake parameters as Appendix A.6.1,
   but (incorrectly) uses the negotiated version in the RSA Client Key
   Exchange Premaster Secret, not the Client Hello version.

C : Sending 82 bytes (Client Hello requesting TLS 1.1,
    in a TLS 1.0 Record)
0000 : 16 03 01 00 4d 01 00 00 49 03 02 44 90 ba 62 c9   ....M...I..D.?b?
0010 : 90 f9 f6 58 77 e4 47 4d 54 68 d0 34 2d 58 01 58   .?.Xw.GMTh.4-X.X
0020 : 58 75 9d 2d a9 7f 7f b0 31 79 2c 00 00 22 00 39   Xu.-...?1y,..".9
0030 : 00 38 00 37 00 36 00 35 00 33 00 32 00 31 00 30   .8.7.6.5.3.2.1.0
0040 : 00 2f 00 05 00 04 00 13 00 0d 00 16 00 10 00 0a   ./..............
0050 : 01 00                                             ..

S : Received 948 bytes (Server Hello TLS 1.0)
0000 : 16 03 01 00 4a 02 00 00 46 03 01 44 90 b9 ca c7   ....J...F..D..??
0010 : e2 39 41 9b 19 83 f1 da 9f 28 19 44 4b 1e aa 60   ?9A...??.(.DK.?`
0020 : 16 8b d4 e5 a3 76 22 44 3f 99 12 20 2a c7 7a ed   ..?..v"D... *?z?
0030 : b1 22 97 0f 50 4d ee b1 a7 78 10 8c 59 aa bf 16   ."..PM?..x..Y??.
0040 : a5 19 75 bc f8 b1 6a eb 68 f6 0f 3d 00 05 00      ..u...j?h..=...

    (Certificate)
0040 :                                              16                  .
0050 : 03 01 03 57 0b 00 03 53 00 03 50 00 03 4d 30 82   ...W...S..P..M0.
0060 : 03 49 30 82 02 b2 a0 03 02 01 02 02 03 3f 84 41   .I0...?........A
0070 : 30 0d 06 09 2a 86 48 86 f7 0d 01 01 04 05 00 30   0...*.H.?......0
0080 : 81 ce 31 0b 30 09 06 03 55 04 06 13 02 5a 41 31   .?1.0...U....ZA1
0090 : 15 30 13 06 03 55 04 08 13 0c 57 65 73 74 65 72   .0...U....Wester
00a0 : 6e 20 43 61 70 65 31 12 30 10 06 03 55 04 07 13   n Cape1.0...U...
00b0 : 09 43 61 70 65 20 54 6f 77 6e 31 1d 30 1b 06 03   .Cape Town1.0...
00c0 : 55 04 0a 13 14 54 68 61 77 74 65 20 43 6f 6e 73   U....Thawte Cons
00d0 : 75 6c 74 69 6e 67 20 63 63 31 28 30 26 06 03 55   ulting cc1(0&..U
00e0 : 04 0b 13 1f 43 65 72 74 69 66 69 63 61 74 69 6f   ....Certificatio
00f0 : 6e 20 53 65 72 76 69 63 65 73 20 44 69 76 69 73   n Services Divis
0100 : 69 6f 6e 31 21 30 1f 06 03 55 04 03 13 18 54 68   ion1!0...U....Th
0110 : 61 77 74 65 20 50 72 65 6d 69 75 6d 20 53 65 72   awte Premium Ser
0120 : 76 65 72 20 43 41 31 28 30 26 06 09 2a 86 48 86   ver CA1(0&..*.H.
0130 : f7 0d 01 09 01 16 19 70 72 65 6d 69 75 6d 2d 73   ?......premium-s
0140 : 65 72 76 65 72 40 74 68 61 77 74 65 2e 63 6f 6d   erver@thawte.com
0150 : 30 1e 17 0d 30 35 30 36 32 31 31 31 30 37 33 39   0...050621110739
0160 : 5a 17 0d 30 36 30 36 32 31 31 31 30 37 33 39 5a   Z..060621110739Z
0170 : 30 5b 31 0b 30 09 06 03 55 04 06 13 02 4e 4f 31   0[1.0...U....NO1
0180 : 0d 30 0b 06 03 55 04 08 13 04 4f 73 6c 6f 31 0d   .0...U....Oslo1.
0190 : 30 0b 06 03 55 04 07 13 04 4f 73 6c 6f 31 14 30   0...U....Oslo1.0
01a0 : 12 06 03 55 04 0a 13 0b 47 4f 54 4f 47 41 54 45   ...U....GOTOGATE
01b0 : 20 41 53 31 18 30 16 06 03 55 04 03 13 0f 77 77    AS1.0...U....ww
01c0 : 77 2e 67 6f 74 6f 67 61 74 65 2e 6e 6f 30 81 9f   w.gotogate.no0..



Pettersen                Expires April 19, 2007                [Page 26]


Internet-Draft            TLS interoperability              October 2006


01d0 : 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03   0...*.H.?.......
01e0 : 81 8d 00 30 81 89 02 81 81 00 ca e1 b4 e6 2a cb   ...0......???.*?
01f0 : 27 c0 d3 17 d0 f8 8b 91 62 f9 97 84 86 b5 9e 0b   '??.....b?......
0200 : 1d df 97 b1 ce 7e 12 25 59 f2 80 d2 bf 8e 7b 56   ....?~.%Y?.??.{V
0210 : d0 cb 3c 1a ba c9 c6 0f 50 5b 17 b6 fd 66 ed c3   .?<.??..P[..?f??
0220 : 32 29 9b cd bb fd a4 9a 5a c1 67 48 2e 61 fa a6   2).?.?..Z?gH.a??
0230 : 48 1d ef 63 3c 97 38 6e a5 48 4c d8 e1 fe ec ec   H.?c<.8n.HL.?.??
0240 : ce 49 5a 86 54 43 ff 40 f2 8e 4c 26 35 d8 a3 19   ?IZ.TC?@?.L&5...
0250 : c6 e1 b9 6e ac 45 17 1d 37 32 85 18 d0 e3 41 d8   .?.n.E..72...?A.
0260 : c3 21 7b 67 e7 4f 37 64 f8 a9 02 03 01 00 01 a3   ?!{g?O7d........
0270 : 81 a6 30 81 a3 30 1d 06 03 55 1d 25 04 16 30 14   .?0..0...U.%..0.
0280 : 06 08 2b 06 01 05 05 07 03 01 06 08 2b 06 01 05   ..+.........+...
0290 : 05 07 03 02 30 40 06 03 55 1d 1f 04 39 30 37 30   ....0@..U...9070
02a0 : 35 a0 33 a0 31 86 2f 68 74 74 70 3a 2f 2f 63 72   5?3?1./http://cr
02b0 : 6c 2e 74 68 61 77 74 65 2e 63 6f 6d 2f 54 68 61   l.thawte.com/Tha
02c0 : 77 74 65 50 72 65 6d 69 75 6d 53 65 72 76 65 72   wtePremiumServer
02d0 : 43 41 2e 63 72 6c 30 32 06 08 2b 06 01 05 05 07   CA.crl02..+.....
02e0 : 01 01 04 26 30 24 30 22 06 08 2b 06 01 05 05 07   ...&0$0"..+.....
02f0 : 30 01 86 16 68 74 74 70 3a 2f 2f 6f 63 73 70 2e   0...http://ocsp.
0300 : 74 68 61 77 74 65 2e 63 6f 6d 30 0c 06 03 55 1d   thawte.com0...U.
0310 : 13 01 01 ff 04 02 30 00 30 0d 06 09 2a 86 48 86   ...?..0.0...*.H.
0320 : f7 0d 01 01 04 05 00 03 81 81 00 60 28 92 bc 07   ?..........`(...
0330 : 1f 96 76 d8 26 bd 10 59 8a 02 17 f3 a3 60 bc fc   ..v.&..Y...?.`..
0340 : 2a 4e b1 41 17 85 b3 b2 b0 4d db 43 d8 a4 f2 a9   *N.A....?M?C..?.
0350 : 7d 41 80 6d e7 fd ac 13 65 59 8c f3 81 6b 7c 0a   }A.m??..eY.?.k|.
0360 : b7 17 0d 00 4e 71 f4 84 f5 d2 30 b1 98 34 4b 2c   ?...Nq?.??0..4K,
0370 : b0 d0 0b 6d 85 e9 4d 6d 10 56 90 bd 36 b5 f3 5e   ?..m.?Mm.V..6.?^
0380 : ed 21 72 93 21 fc 90 d9 78 92 08 8b 6b b2 e9 0c   ?!r.!..?x...k.?.
0390 : 5a 19 54 b9 1a c9 ed c2 59 72 44 d3 13 57 08 15   Z.T..???YrD?.W..
03a0 : 1a 32 dd d9 53 23 85 76 d1 1c 0d 16 03 01 00 04   .2??S#.v?.......

     (Hello Done)
03b0 : 0e 00 00 00                                       ....

C : Plain Premaster Secret (Wrong version v3.1, negotiated version)
0000 : 03 01 9d 41 00 f3 76 57 07 9b 68 f9 d2 2d 5e 49   ...A.?vW..h??-^I
0010 : 9f 09 20 02 f6 b2 bf a2 c5 cb c7 6c 0f 2f 0c e2   .. ...?..??l./.?
0020 : 95 92 27 2d a3 0b 9f 33 cc 17 5b 28 72 1b 12 42   ..'-...3?.[(r..B

C : Sending 139 bytes (Client Key Exchange)
0000 : 16 03 01 00 86 10 00 00 82 00 80 1c b1 e5 ca 77   ..............?w
0010 : 7f 30 81 80 70 1d 5f 39 26 5b d7 c4 5e db 46 73   .0..p._9&[?.^?Fs
0020 : be 48 1a eb 92 fa 95 cd dc 23 f4 2a fe 7c 25 7f   .H.?.?.?.#?*.|%.
0030 : 0d d4 22 1f 48 f6 77 c2 a2 e4 53 49 ea f8 bf c4   .?".H.w?..SI?.?.
0040 : cf 34 12 98 46 93 d9 e2 b3 bc 10 f8 f3 c0 16 6e   ?4..F.??....??.n
0050 : 18 40 f7 8d c0 27 11 1f 04 30 f5 9b cd 42 c8 e5   .@?.?'...0?.?B?.
0060 : 1a e1 de 58 90 e6 b2 90 d4 89 19 ec bc 6b 29 cb   .?.X....?..?.k)?
0070 : 4d 62 01 38 26 ae 15 1c f5 21 13 b6 99 33 86 01   Mb.8&...?!...3..



Pettersen                Expires April 19, 2007                [Page 27]


Internet-Draft            TLS interoperability              October 2006


0080 : 66 1b a3 10 e2 1d 72 c2 10 7e 64                  f...?.r?.~d

C : Sending 6 bytes (Cipher Change)
0000 : 14 03 01 00 01 01                                 ......

C : Plain Finished
0000 : 14 00 00 0c e8 e7 48 a2 d4 6e 0f a0 70 bf 3e 05   ....??H.?n.?p?>.

C : Sending 41 bytes (Encrypted Finished)
0000 : 16 03 01 00 24 6f 2f 39 d4 7d 78 84 89 15 c8 92   ....$o/9?}x...?.
0010 : bc de af 63 c9 53 2e c6 d6 27 01 5d 3c 96 00 1a   ..?c?S...'.]<...
0020 : ca e0 66 11 43 55 4e 2a ab                        ??f.CUN*.

S : Received 47 bytes (Cipher Change, Encrypted Finished)
0000 : 14 03 01 00 01 01 16 03 01 00 24 e7 6f 04 fc c8   ..........$?o..?
0010 : 9b c3 62 ae 27 bc cc 1a a0 01 f0 16 f3 7a cf cd   .?b.'.?.?...?z??
0020 : f7 8c db 16 60 4a a3 7b 3e c2 66 ad ef c6 f8      ?.?.`J.{>?f??..

S : Plaintext 16 bytes (Plaintext Finished)
0000 : 14 00 00 0c be 82 73 55 1b 12 ce 7c 25 02 4c af   ......sU..?|%.L?

<Connection established>

A.7.  Refusing to accept compression methods

   Contributed by: Pasi Eronen

   This example shows a TLS 1.0 client that requests LZS compression
   [RFC3943] (code 64) and the Null method.  The server responds with a
   Handshake Failure Alert message.

C: Sending 53 bytes: (TLS 1.0 Client hello, in TLS 1.0 Record, requesting
   LZS (code 64) and Null compression methods)
0000 : 16 03 01 00 30 01 00 00 2c 03 01 6b c6 db 2a 4c
0000 : 64 3e 05 df 2f 15 20 ab 7e e6 7a d1 eb 9c 20 59
0000 : 2a ea 83 d4 3f 37 ea 98 3b 3c 87 00 00 04 00 2f
0000 : 00 0a 02 40 00

S: Received 7 bytes: (Alert message: Handshake failure)
0000 : 15 03 01 00 02 02 28

A.8.  Copying the Client Hello Version field

   Date:  July 22, 2006







Pettersen                Expires April 19, 2007                [Page 28]


Internet-Draft            TLS interoperability              October 2006


   Server:  (As identifed in the HTTP Server Header) OfficeLine 3.5
      Webserver (2.16)

   Site:  https://ebssl.unibanka.sk

   Highest supported version:  SSL v3.0

   This example shows a specially modified client use a TLS 1.0 Client
   Hello, in a TLS 1.0 Record, to request a connection using the
   hypothetical SSL v4.0 protocol.  Even though the server only supports
   SSL v3.0 it incorrectly responds with {4.0} as the selected version.
   Similar incorrect selections have been observed for TLS 1.0 and TLS
   1.1 versions numbers, which inevitably results in Handshake Failure
   errors.

C: Sending 82 bytes (TLS 1.0 Record and TLS 1.0 Client Hello, specifying
  non-existen version {4,0} as the highest supported.
0000 : 16 03 02 00 4d 01 00 00 49 04 00 44 c1 6e 9e f8   ....M...I..D.n..
0010 : 26 c8 01 44 01 be 98 0a 04 03 92 2e 35 46 26 0f   &..D........5F&.
0020 : 4e aa c9 0d 14 da 51 f3 b0 56 6f 00 00 22 00 39   N.....Q..Vo..".9
0030 : 00 38 00 37 00 36 00 35 00 33 00 32 00 31 00 30   .8.7.6.5.3.2.1.0
0040 : 00 2f 00 05 00 04 00 13 00 0d 00 16 00 10 00 0a   ./..............
0050 : 01 00                                             ..

S : Recieved 63 bytes (Server Hello/Record specifying 4.0 as the version,
    although the server only supports SSL v3.0 as its highest version)
0000 : 16 04 00 00 3a 02 00 00 36 04 00 44 c1 8b cd 5d   ....:...6..D...]
0010 : 53 d3 c0 c8 ef ce cb bd da 0b e5 50 ef fa 21 69   S..........P..!i
0020 : 63 d5 9e 54 7b ad 1f 98 34 5c 56 10 97 d3 90 04   c..T{..4\V.....
0030 : cd 8b c1 44 97 d3 90 04 8d ac 21 00 00 04 00      ...D......!....


Author's Address

   Yngve N. Pettersen
   Opera Software ASA
   Waldemar Thranes gate 98
   N-0175 OSLO,
   Norway

   Email: yngve@opera.com










Pettersen                Expires April 19, 2007                [Page 29]


Internet-Draft            TLS interoperability              October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Pettersen                Expires April 19, 2007                [Page 30]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/