TLS Padding: A Transport Layer Security (TLS) ClientHello Padding Extension
A TLS extension that pads the ClientHello to a size that avoids buggy server implementations.
Langley, A., "A Transport Layer Security (TLS) ClientHello Padding Extension", RFC 7685, DOI 10.17487/RFC7685, October 2015, <https://www.rfc-editor.org/info/rfc7685>.
@misc{rfc7685,
series = {Request for Comments},
number = 7685,
howpublished = {RFC 7685},
publisher = {RFC Editor},
doi = {10.17487/RFC7685},
url = {https://www.rfc-editor.org/info/rfc7685},
author = {A. Langley},
title = {{A Transport Layer Security (TLS) ClientHello Padding Extension}},
pagetotal = 4,
year = 2015,
month = oct,
} RFC text
Contents
Internet Engineering Task Force (IETF) A. Langley
Request for Comments: 7685 Google Inc
Updates: 5246 October 2015
Category: Standards Track
ISSN: 2070-1721
A Transport Layer Security (TLS) ClientHello Padding Extension
Abstract
This memo describes a Transport Layer Security (TLS) extension that
can be used to pad ClientHello messages to a desired size.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7685.
Copyright Notice
Copyright (c) 2015 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 Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
3. Padding Extension . . . . . . . . . . . . . . . . . . . . . . 2
4. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 3
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Normative References . . . . . . . . . . . . . . . . . . . . 4
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction
Successive TLS [RFC5246] versions have added support for more cipher
suites and, over time, more TLS extensions have been defined. This
has caused the size of the TLS ClientHello to grow, and the
additional size has caused some implementation bugs to come to light.
At least one of these implementation bugs can be ameliorated by
making the ClientHello even larger. This is desirable given that
fully comprehensive patching of affected implementations is difficult
to achieve.
This memo describes a TLS extension that can be used to pad a
ClientHello to a desired size in order to avoid implementation bugs
caused by certain ClientHello sizes.
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Padding Extension
A new extension type ("padding(21)") is defined and MAY be included
by the client in its ClientHello message.
enum {
padding(21), (65535)
} ExtensionType;
The "extension_data" for the extension consists of an arbitrary
number of zero bytes. For example, the smallest "padding" extension
is four bytes long and is encoded as 0x00 0x15 0x00 0x00. A ten-byte
extension would include six bytes of "extension_data" and would be
encoded as:
00 15 00 06 00 00 00 00 00 00
|---| |---| |---------------|
| | |
| | \- extension_data: 6 zero bytes
| |
| \------------- 16-bit, extension_data length
|
\------------------- extension_type for padding extension
The client MUST fill the padding extension completely with zero
bytes, although the padding extension_data field may be empty.
The server MUST NOT echo the extension.
4. Example Usage
As an example, consider a client that wishes to avoid sending a
ClientHello with a TLSCiphertext.length between 256 and 511 bytes
(inclusive). This case is considered because at least one TLS
implementation is known to hang the connection when such a
ClientHello record is received.
After building a ClientHello as normal, the client can add four bytes
to the length (to account for the "msg_type" and "length" fields of
the handshake protocol) and test whether the resulting length falls
into that range. If it does, a padding extension can be added in
order to push the length to (at least) 512 bytes.
Note that if the original ClientHello size was between 505 and 507
bytes, then, with the handshake protocol overhead, the record payload
would be between 509 and 511 bytes long. Since it's not possible for
an extension to take less than four bytes of space, the additional
padding would have to expand the ClientHello record payload beyond
512 bytes in these cases.
5. Security Considerations
The contents of the padding extension could be used as a covert
channel. In order to prevent this, the contents are required to be
all zeros, although the length of the extension can still be used as
a much smaller covert channel.
6. IANA Considerations
IANA has permanently registered value 21 (padding) in the
"ExtensionType Values" registry.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
Acknowledgements
The author gratefully acknowledges the contributions of Wan-Teh Chang
and the suggestions of Eric Rescorla.
Author's Address
Adam Langley
Google Inc
Email: agl@google.com
AI ELI5
On this page
§1Why Pad a ClientHello
Successive TLS versions (see RFC 5246) added support for more cipher suites, and more extensions were defined over time. This made the TLS ClientHello larger, and the extra size brought some implementation bugs to light.
At least one of these bugs can be eased by making the ClientHello even bigger. Since fully patching affected implementations is difficult, this memo defines an extension to pad a ClientHello to a desired size.
Some old machines choke on messages of certain sizes. Adding blank filler can push the message to a size that they handle fine.
§3The Padding Extension
The new extension type is padding(21), and a client MAY include it in its ClientHello. Its extension_data is an arbitrary number of zero bytes. The smallest padding extension is four bytes long and is encoded as 0x00 0x15 0x00 0x00. A ten-byte extension has six zero bytes of data and is encoded as 00 15 00 06 00 00 00 00 00 00.
The client MUST fill the extension completely with zero bytes, although the data may be empty. The server MUST NOT echo the extension.
The filler is just a label saying how much blank there is, followed by that many zeros. The server never repeats it back.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
EXT-TYPE | extension_type | 2 bytes | 0x0015 | Identifies the padding extension. |
EXT-LEN | extension_data length | 2 bytes | 6 | Number of data bytes that follow. |
EXT-DATA | extension_data | 6 bytes | 00 00 00 00 00 00 | Zero bytes only. |
§4Example Usage
Consider a client that wants to avoid a ClientHello whose TLSCiphertext.length is between 256 and 511 bytes inclusive, because at least one TLS implementation is known to hang the connection on such a record. After building the ClientHello, the client adds four bytes for the msg_type and length fields of the handshake protocol and tests whether the result falls in that range. If so, it adds a padding extension to push the length to at least 512 bytes.
One edge case: if the original size was between 505 and 507 bytes, the record payload would be 509 to 511 bytes. An extension cannot take fewer than four bytes, so the padding pushes the payload beyond 512 bytes.
If your message is a bit too thin, add blank pages until it is thick enough. If it is almost thick enough, the smallest blank page still makes it a little thicker than needed.
§5Security and IANA
The padding contents could be used as a covert channel, so they are required to be all zeros. The length of the extension can still be used as a much smaller covert channel.
IANA permanently registered value 21 (padding) in the ExtensionType Values registry.
Filler must be blank so nobody can hide secret notes in it, though the amount of filler could still send a tiny hint.