[gnutls-devel] 3.2.2 breaks TLS sockets
Tim Kosse
tim.kosse at filezilla-project.org
Fri Jul 26 18:24:44 CEST 2013
Hi,
I've also encountered this issue, I'm seeing it triggered in
gnutls_cipher.c:748
On 2013-07-26 15:29, Nikos Mavrogiannopoulos wrote:
> If I am correct on the interpretation
> of the issue, it seems that these particular servers exceed the
> maximum allowed number of bytes. The %COMPAT keyword should have
> allowed them nevertheless, and that is what the patch do.
I don't think this is the case.
The ciphertext includes the following: compressed data (no bigger than
plaintext length + 2048), padding, iv, mac.
As per TLS1.2 RFC:
> The encrypted data length (TLSCiphertext.length) is one more than the
> sum of SecurityParameters.block_length, TLSCompressed.length,
> SecurityParameters.mac_length, and padding_length.
In gnutls_cipher.c:747, we're comparing the ciphertext size against the
size of the output buffer. At this point, the ciphertext size still
contains mac, padding, some tags (iv size has been subtracted before).
Building on your patch, I think the correct approach is to use the
following:
t.size = _gnutls_get_max_decrypted_data(session) + MAX_PAD_SIZE +
MAX_HASH_SIZE;
I'm not quite sure if there's still some +1 or something else hiding
there though.
Sidenode: I'm not sure the check for allow_large_records in
_gnutls_get_max_decrypted_data is working as intended in this case.
Intuitively I would simply make the output buffer as large as the
ciphertext if I were to allow over-sized records.
Regards,
Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20130726/ec8a36b8/attachment.sig>
More information about the Gnutls-devel
mailing list