GNUTLS_E_UNEXPECTED_PACKET_LENGTH

[Joe Orton]

On Mon, Mar 31, 2008 at 12:46:10PM +0200, Simon Josefsson wrote:
> Maiku <cmaiku at gmail.com> writes:
> 
> > I discovered that if you try to connect to login.live.com with GNU TLS (I
> > used gnutls-cli) and send any data to it, after a successful connection,
> > when it gets to the end of receiving a response to that data, it throws a
> > GNUTLS_E_UNEXPECTED_PACKET_LENGTH error. I tried the same test on another
> > SSL server (addons.mozilla.org) and it worked fine, so I imagine it's
> > something that login.live.com is doing specifically. I tested it with the
> > version of GNU TLS that comes with Ubuntu 7.10, 8.04 beta, and the
> > 2.3.4source package from the GNU TLS site, and all of them had the
> > same results.
> 
> Thanks for the report.  I believe the server is buggy, it disconnects
> instead of sending a CLOSE alert after the HTTP command has completed.
> GnuTLS expects a TLS header at that point, but gets no data at all,
> hence the unexpected length error.
> 
> I'm not sure what the proper behaviour should be.  I don't think
> ignoring this error condition is a good idea, it makes the
> implementation vulnerable to the same problem that SSLv2 were vulnerable
> to.  (I.e., faking TCP FIN makes recipient believe the TLS channel is
> terminated successfully.)
> 
> The error message isn't particularly helpful.  We could add another
> error code, such as GNUTLS_E_PREMATURE_CLOSE or similar instead.  What
> do you think?

Adding a new error code for this would be really useful, yes.  An HTTP 
client can safely ignore a premature FIN in cases where it knows the 
application data has been completely transferred (e.g. using the 
Content-Length); being able to distinguish that specific case from other 
failure cases is useful.

In neon at the moment I treat GNUTLS_E_UNEXPECTED_PACKET_LENGTH as 
premature EOF, and even have a note in the code about it being a hack!

joe