Unfortunate current practices for HTTP over TLS
Adam Langley <agl <at> google.com>
2011-01-18 22:21:11 GMT
The following is presented mostly for the member's enjoyment:
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.
RSS Feed