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]
