joe at manyfish.co.uk
Mon Mar 31 15:01:13 CEST 2008
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!
More information about the Gnutls-devel