Re: [TLS] Renego Indication RI patch interaction with TLS major version interop

[Simon Josefsson <[e-mail]>]

Adam Langley <[e-mail]> writes:

F> On Tue, Jun 15, 2010 at 5:16 PM, Simon Josefsson <[e-mail]> wrote:
>> jas@mocca:~$ gnutls-cli -p 443 www.paypal.com
>> Resolving 'www.paypal.com'...
>> Connecting to '64.4.241.49:443'...
>> *** Fatal error: A TLS packet with unexpected length was received.
>> *** Handshake has failed
>> GNUTLS ERROR: A TLS packet with unexpected length was received.
>> jas@mocca:~$
>
> Although I can confirm the brain damage exhibited by www.microsoft.com
> and www.ibm.com, www.paypal.com doesn't have an issue with a
> ClientHello advertising TLS version 1.2. It might have other problems,
> but see the attached handshake.

After some debugging, I can confirm that TLS 1.1/1.2 is not the problem.
The aspect causing problems with www.paypal.com is record padding,
because this works:

gnutls-cli -p 443 www.paypal.com --priority NORMAL:%COMPAT

Random record padding has been part of TLS since a long time.  Alas,
GnuTLS appears to be the only implementation making use of this.  It has
to be supported, though, even RFC 2246 contained this wording:

   padding
       Padding that is added to force the length of the plaintext to be
       an integral multiple of the block cipher's block length. The
       padding may be any length up to 255 bytes long, as long as it
       results in the TLSCiphertext.length being an integral multiple of
       the block length. Lengths longer than necessary might be
       desirable to frustrate attacks on a protocol based on analysis of
       the lengths of exchanged messages. Each uint8 in the padding data
       vector must be filled with the padding length value.

We've seen many implementations that barf on random record padding.

/Simon