Big CA certificate bundle causes problems with GnuTLS 3.0.11

[Michal Suchanek]

On 29 May 2012 17:31, Phil Pennock <help-gnutls-phil at spodhuis.org> wrote:
> On 2012-05-29 at 21:46 +0700, Janne Snabb wrote:
>> I am experiencing a TLS handshake problem when GnuTLS 3.0.11 server has
>> a big pile of CA certificates to verify against. I can not reproduce the
>> problem with GnuTLS 2.12.14.
>
> It appears to be commit 67f4dba6 from March 20th:
> "Avoided waiting for peer's retransmission to ensure receipt of finished
>  messages, and used a 'timer'-like to retransmit packets."
>
> -  data_size = _mbuffer_get_udata_size(bufel) - handshake_header_size;
> +  if (hsk->length > 0 &&
> +        (hsk->end_offset-hsk->start_offset >=  data_size))
>
>> |<3>| HSK[0x24e4120]: CERTIFICATE REQUEST was received. Length
>> 17025[16380], frag offset 0, frag length: 17025, sequence: 0
>> |<2>| ASSERT: gnutls_buffers.c:819
>> |<2>| ASSERT: gnutls_buffers.c:1031
>> |<2>| ASSERT: gnutls_handshake.c:1269
>> |<2>| ASSERT: gnutls_handshake.c:2515
>> *** Fatal error: A TLS packet with unexpected length was received.
>
> The "was received" code is:
> ----------------------------8< cut here >8------------------------------
>  _gnutls_handshake_log ("HSK[%p]: %s was received. Length %d[%d], frag offset %d, frag length: %d, sequence: %d\n",
>                         session, _gnutls_handshake2str (hsk->htype),
>                         (int) hsk->length, (int)data_size, hsk->start_offset, hsk->end_offset-hsk->start_offset+1, (int)hsk->sequen
> ce);
> ----------------------------8< cut here >8------------------------------
>
> hsk->length is read from the Handshake->length (uint24); data_size is
> the size of the CertificateRequest (received buffer size less 4 for the
> handshake header (type 1 octet, length 3 octets).
>
> hsk->start_offset is always 0.
> hsk->end_offset is always (hsk->length - 1) [because this isn't DTLS].
>
> So the check added in 67f4dba6 is going to always reject a fragmented
> handshake packet.
>

Now what I do not get is how a pile of CA certificates is fragmenting
the packets.

Sounds like a security hole. CA cert piles should be local to either
side, only one CA cert relevant for the session. Technically there can
be more than one cert in the trust chain but not pile of them.

Thanks

Michal