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 February 2, 2011.

Copyright Notice

Copyright (c) 2010 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Table of Contents

1.  Introduction
2.  Handshake message fragmentation
3.  Protocol Fallback
4.  More implementation mistakes
5.  Certificate Chains
6.  Insufficient Security
7.  Acknowledgements
8.  Normative References
Appendix A.  Changes
§  Author's Address

1.  Introduction

HTTP (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616] is one of the most common application level protocols transported over TLS (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246]. (This combination is commonly know 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 (Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.) [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 a version greater or equal to 0x0300 (around 3% of servers)

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

Advertising a TLS version greater than TLS 1.0 (around 2% for 1.1 or 1.2, around 3% for greater than 1.2).

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 (Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, “Transport Layer Security (TLS) Extensions,” June 2003.) [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

Appendix A.  Changes

To be removed by RFC Editor before publication

Author's Address