Successive TLS versions added cipher suites and extensions, causing ClientHello messages to grow. At least one implementation bug is triggered by certain ClientHello sizes and can be worked around by making the ClientHello larger, which is preferable to comprehensively patching affected implementations.

tls, security

At least one TLS implementation is known to hang when it receives a ClientHello with a TLSCiphertext.length between 256 and 511 bytes inclusive. The padding extension can be used to push the record payload to at least 512 bytes to avoid this bug.

tls

If the original ClientHello payload is between 505 and 507 bytes, the handshake protocol overhead places the record payload between 509 and 511 bytes. Since an extension requires at least four bytes, the padding must expand the payload beyond 512 bytes in these cases.

tls

The client MUST fill the padding extension completely with zero bytes, although the extension_data field may be empty.

tls, security

The padding extension MAY be included by the client in its ClientHello message.

tls

The server MUST NOT echo the padding extension back to the client.

tls

A new extension type 'padding' with value 21 is defined for TLS ClientHello messages. The extension_data consists of an arbitrary number of zero bytes, and the extension may have an empty extension_data field.

tls

IANA has permanently registered value 21 (padding) in the 'ExtensionType Values' registry for TLS extensions.

tls, registry

The contents of the padding extension could be used as a covert channel. To prevent this, the extension data is required to be all zeros, though the length of the extension itself can still serve as a much smaller covert channel.

tls, security, privacy

The padding extension is encoded as a 2-byte extension_type (0x00 0x15 for value 21), a 2-byte extension_data length field, followed by zero or more zero bytes. The smallest valid encoding is four bytes (0x00 0x15 0x00 0x00 with zero-length extension_data).

tls