(For amusement value.)
Network Working Group A. Langley Internet-Draft Google Inc Expires: July 5, 2011 Jan 2011 Unfortunate current practices for HTTP over TLS draft-agl-tls-oppractices-00 Abstract This document describes some of the unfortunate current practices which are needed in order to transport HTTP over TLS on the public Internet. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 July 5, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Handshake message fragmentation . . . . . . . . . . . . . . . 4 3. Protocol Fallback . . . . . . . . . . . . . . . . . . . . . . 5 4. More implementation mistakes . . . . . . . . . . . . . . . . . 6 5. Certificate Chains . . . . . . . . . . . . . . . . . . . . . . 7 6. Insufficient Security . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction HTTP [RFC2616] is one of the most common application level protocols transported over TLS [RFC5246]. (This combination is commonly known as HTTPS based on the URL scheme used to indicate it.) HTTPS clients have to function with a huge range of TLS implementations, some of higher quality than others. This text aims to document some of the behaviours of existing HTTPS clients that are designed to ensure maximum interoperability. This text should not be taken as a recommendation that future HTTPS clients adopt these behaviours. The security implications of each need to be carefully considered by each implementation. However, these behaviours are common and the authors consider it better to document the state of practice than to simply wish it were otherwise. 2. Handshake message fragmentation Many servers will fail to process a handshake message that spans more than one record. These servers will close the connection when they encounter such a handshake message. HTTPS clients will commonly ensure against that by either packing all handshake messages in a flow into a single record, or by creating a single record for each handshake message. 3. Protocol Fallback Despite it being nearly twelve years since the publication of TLS 1.0 [RFC2246], around 3% of HTTPS servers will reject a valid TLS "ClientHello". These rejections can take the form of immediately closing the connection or a fatal alert. Intolerance to the following has been observed: Advertising version TLS 1.0. Advertising a TLS version greater than TLS 1.0 (around 2% for 1.1 or 1.2, around 3% for greater than 1.2). Advertising a version greater than 0x03ff (around 65% of servers) The presence of any extensions (around 7% of servers) The presence of specific extensions ("server_name" and "status_request" intolerance has been observed, although in very low numbers). The presence of any advertised compression algorithms Next, some servers will misbehave after processing the "ClientHello" message. Negotiating the use of "DEFLATE" compression can result in fatal "bad_record_mac", "decompression_failure" or "decryption_failed" alerts. Notably, OpenSSL prior to version 0.9.8c will intermittently fail to process compressed finished messages due to a work around of a previous padding bug. Lastly, some servers will negotiate the use of SSLv3 but select a TLS-only cipher suite. In all these cases, HTTPS clients will often enter a fallback mode. The connection is retried using only SSLv3 and without advertising any compression algorithms. (This is obviously an easy downgrade attack.) Also, the fallback can be triggered by transient network problems, which often manifest as an abruptly closed connection. Since SSLv3 does not provide any means of Server Name Indication [RFC3546], the fallback connection can use the wrong certificate chain, resulting in a very surprising certificate error. 4. More implementation mistakes Non-fatal errors in version negotiation also occur. Some 0.2% of servers use the version from the record header. Around 0.6% of servers require that the version in the "ClientHello" and record header match in order to respect the version in the "ClientHello". A very low number of servers echo whatever version the client advertises. In the event that the client supports a higher protocol version than the server, about 0.4% of servers require that the RSA "ClientKeyExchange" message include the server's protocol version. Some 30% of servers don't check the version in an RSA "ClientKeyExchange" at all. 5. Certificate Chains Certificate chains presented by servers will commonly be missing intermediate certificates, have certificates in the wrong order and will include unrelated, superfluous certificates. Servers have been observed presenting more than ten certificates in what we assume is a drive-by shooting approach to including the correct intermediate certificate. In order to validate chains which are missing certificates, some HTTPS clients will collect intermediate certificates from other servers. Clients will commonly put all the presented certificates into a set and try to validate a chain assuming only that the first certificate is the leaf. 6. Insufficient Security Some 65% of servers support SSLv2 (beyond just supporting the handshake in order to upgrade to SSLv3 or TLS). HTTPS clients will typically not support SSLv2, nor send SSLv2 handshakes by default. Of those servers, 80% support the export ciphersuites. (Although about 3% of those servers negotiate weak ciphersuites only to show a warning.) Some servers will choose very small multiplicative group sizes for their ephemeral Diffie-Hellman exchange (for example, 256-bits). Some HTTPS clients will reject all multiplicative group sizes smaller than 512-bits while others will retry after demoting DHE ciphersuites in their "ClientHello". 7. Acknowledgements Yngve Pettersen made significant contributions and many of the numbers in this document come from his scanning work. Other numbers were taken from Ivan Ristic's SSL Survey. Thanks to Wan Teh Chang for reviewing early drafts. 8. Normative References [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.