GNUTLS_E_UNEXPECTED_PACKET_LENGTH

[Simon Josefsson]

Maiku <cmaiku at gmail.com> writes:

> I wanted to clarify a few things I think I missed in my original post. In
> the line I posted, when this error happens:
>
> if (ret < 0 && gnutls_error_is_fatal (ret) == 0)
>
> ret is 0. In the _gnutls_io_read_buffered function, it returns on line 639
> in gnutls_buffers.c (according to 2.3.4) in this block:
>
>     if (ret == 0)
>     {                /* EOF */
>       gnutls_assert ();
>       return 0;
>     }
>
> Also, the gnutls_error_is_fatal returns false (0) for values above zero, and
> returns a non-fatal error (0 again) for zero. So to me it appeared that zero
> was a case that wasn't being caught properly when checking for less than 0.
> My thoughts were that if it was zero it should return as normal (without an
> error), the client can then check and see if enough was read, read more if
> it needs more, or handle the packet if it's done. This way it doesn't
> terminate the session on a return of zero and the client can handle a recv
> of zero and the client can handle it however it wishes. It's a sort of case
> in itself, I don't believe that would be ignoring it.

I believe again that the problem is that it makes it possible for an
attacker to terminate a TLS session (just inject a TCP FIN).  The TLS
peers could not tell the difference between that and when one of the TLS
peers terminated the session properly.  SSLv2 was vulnerable to this
attack.

It is impossible to tell the difference between if an attacker injects
TCP FIN or when the server is buggy and just tears down the TLS session
without sending a close alert.  I believe we need to assume the former.

However, a specific error code to signal this situation seems like a
good idea.  Some applications may want to ignore this error condition.

/Simon