mainGnuTLS - Support: sr #106987, Frequent "TLS packet with...

 
 

sr #106987: Frequent "TLS packet with unexpected length" errors

Submitter:  Jeremy Nickurak <atrus>
Submitted:  Wed 19 Aug 2009 05:29:20 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  4 - Important Status:  Need Info
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 05 Feb 2010 02:14:05 PM UTC, comment #12: 

When a server terminates a connection abnormally (TCP termination), TLS (and thus gnutls) cannot distinguish that from a prematurely terminated connection due to attack. This is the reason the error "A TLS packet with unexpected length was received.". If we decided to silence this error, as other implementations or applications might do, we would be vulnerable to premature termination attacks (i.e. someone terminates your connection after the first 10kb of your message were downloaded to prevent you downloading an attachment). That is worse, thus we stay on the safe side of warning of servers that do that.

Nikos Mavrogiannopoulos <nmav>
Group administrator
Tue 01 Sep 2009 02:08:50 PM UTC, comment #11: 

Do you have access to server logs to look for error messages? 

Maybe you can run wireshark to record the session.  The first thing to establish is if it is the server that disconnects without sending a close_alert, then it is a server problem and needs to be debugged further on the server side.

/Simon

Simon Josefsson <jas>
Group administrator
Mon 31 Aug 2009 09:36:54 PM UTC, comment #10: 

I get it with mutt connecting to mailserver, spunky.mail.dreamhost.com occasionally. Unfortunately it appears to occur largely randomly.

Jeremy Nickurak <atrus>
Mon 31 Aug 2009 08:25:52 PM UTC, comment #9: 

A reproducible example is needed to solve the problem.  If there is justification for the bug being in GnuTLS, describing it shouldn't be too hard.  The pop.gmail.com example is not helping since it appears to be a server bug.

/Simon

Simon Josefsson <jas>
Group administrator
Mon 31 Aug 2009 08:10:18 PM UTC, comment #8: 

It seems the application authors (with some justification) are seeing their applications work correctly when compiled with openssl, and incorrectly when compiled with gnutls, and then saying it's a bug in gnutls, not their individual applications.

Jeremy Nickurak <atrus>
Mon 31 Aug 2009 08:00:18 PM UTC, comment #7: 

To debug further, and ultimately come up with a patch, we need to be able to reproduce something that illustrate a problem in GnuTLS.  I believe the pop.gmail.com example just illustrate a server bug.  We can't fix that in GnuTLS (unless Google is using GnuTLS and shows us code to reproduce it from the server side).

We could continue the pop.gmail.com example with the goal of making GnuTLS and applications handle the server error better, but as far as I understand, gnutls-cli does the right thing here: it prints an error message and quits.  Other applications may want to re-start the connection when a fatal error happens, though, but then this problem becomes an application problem since GnuTLS cannot restart connections.  I can help application writers use GnuTLS appropriately here, but it is really up to each application to address the problem.

We could change the error message to something else, but it looks to me that it would not make anything better.  It is still a fatal error.

/Simon

Simon Josefsson <jas>
Group administrator
Mon 31 Aug 2009 07:47:30 PM UTC, comment #6: 

The bug report is chiefly about applications that work reliably when compiled against openssl frequently failing when compiled with gnutls instead.


The messages and error reporting issues are, as far as I can tell, only symptoms of the fact that a disconnection is occuring. While it's probably important to fix these, the more important issue for users is the fact that gnutls fails so frequently, whether that's a disconnection or protocol error or simple bug.

Jeremy Nickurak <atrus>
Mon 31 Aug 2009 07:43:14 PM UTC, comment #5: 

If my last message wasn't clear: users having problem with pop.gmail.com in this way should report the problem to Google. As far as I understand it is clearly violating the TLS standard here.

/Simon

Simon Josefsson <jas>
Group administrator
Mon 31 Aug 2009 07:36:44 PM UTC, comment #4: 

Disconnecting without sending a close_alert IS a gross violation of the TLS protocol.

SSL 2 did not support close_alert, that was one of the security problems with SSL that prompted TLS.  By ignoring this error condition, applications become vulnerable to attackers shortening the data transferred without clients/servers being able to detect it.  So it is gross violation from a security perspective as well.

It is not clear to me whether this bug report is about the particular error message used, or if there is a request to behave differently here (and if so, behave how?).  Would you please clarify?

Note that OpenSSL also fails with an error message:

jas@mocca:~$ openssl s_client -connect pop.gmail.com:995
...
---
+OK Gpop ready for requests from 80.216.24.211 i34pf9727689gve.5
asd
-ERR bad command i34pf9727689gve.5
read:errno=0
jas@mocca:~$

If the request is for a different error message, would the following patch make any difference?  The error code isn't the best, since it is used for other purposes too.  To really address this, we could add a separate error code.

/Simon

diff --git a/lib/gnutls_record.c b/lib/gnutls_record.c
index 62df871..3025d75 100644
--- a/lib/gnutls_record.c
+++ b/lib/gnutls_record.c
@@ -913,6 +913,9 @@ begin:
  }
       session_unresumable (session);
       gnutls_assert ();
+      if (ret == 0)
+ /* Give more appropriate error message if peer disconnects. */
+ return GNUTLS_E_INVALID_SESSION;
       return GNUTLS_E_UNEXPECTED_PACKET_LENGTH;
     }
 

Simon Josefsson <jas>
Group administrator
Fri 28 Aug 2009 01:10:56 AM UTC, comment #3: 

You might be able to use ssldump to see whether the server is actually sending an odd-length packet or something else. Or to compare openssl's connection setup with gnutls's.

I don't have a gmail account, but I tried connecting to their server using gnutls-cli (transcript below). I gave it a bogus username and password, after which gmail booted me off without a final ALERT. Possibly the error code returned by gnutls when this happens is seen by mutt et al. as being more severe than the one that's returned by openssl when this happens?


$ gnutls-cli -d 10 -p 995 pop.gmail.com
[...]
|<4>| REC[0x1801c00]: Decrypted Packet[3] Application Data(23) with length: 49
|<6>| BUF[REC]: Inserted 49 bytes of Data(23)
|<6>| BUFFER[REC][AD]: Read 49 bytes of Data(23)
|<7>| READ: Got 1 bytes from 0x4
|<7>| READ: read 1 bytes from 0x4
|<7>| 0000 - 2c
-ERR [AUTH] Username and password not accepted.
|<7>| READ: Got 0 bytes from 0x4
|<7>| READ: read 0 bytes from 0x4
|<7>| 0000 -
|<2>| ASSERT: gnutls_buffers.c:599
|<2>| ASSERT: gnutls_record.c:909
*** Fatal error: A TLS packet with unexpected length was received.
*** Server has terminated the connection abnormally.



Wim Lewis <wiml>
Thu 27 Aug 2009 10:35:43 PM UTC, comment #2: 

Assuming your analysis is correct, and given that these applications, compiled against openssl, don't have this issue, it seems there's two possibilities:

- openssl is magically restoring connections (unlikely)
- gnutls on the client is doing something that causes the remote servers in these applications to drop connection where openssl clients do not

Jeremy Nickurak <atrus>
Thu 27 Aug 2009 10:27:51 PM UTC, comment #1: 

While doing some testing with gnutls I found that gnutls will emit this error if the server drops the connection. I think it would be useful if gnutls emitted a different message for a dropped connection than "packet with unexpected length", which suggests some kind of gross protocol violation.

(In my case it was that a particular openssl-based server, if presented with a CLIENT_HELLO advertising the DEFLATE compression method but not the NULL method, will drop the connection immediately without even sending an ALERT back.)

Wim Lewis <wiml>
Wed 19 Aug 2009 05:29:20 PM UTC, original submission:  

Forwarding from https://bugs.launchpad.net/ubuntu/+source/gnutls13/+bug/105736 :



> http://www.mail-archive.com/mutt-users@mutt.org/msg32520.html
>
> I use mutt on Feisty (ubuntu). When connecting to gmail using pops, mutt connects to the server and asks my password. After I enter it, I see the following error message:
>
> tls_socket_read (A TLS packet with unexpected length was received.)
>
> I googled a bit and saw that it is GNUTLS which causes the problem and rebuilding mutt with openssl solves the problem. Is there any way other than building mutt from source?
>
> I have replicated this in the most current fiesty version of mutt (1.5.13-1ubuntu1).


A quick search shows
- A number of unanswered support requests on the gnutls mailing list
- Bugs filed against mutt, pidgin, filezilla, and other projects
- The general solution, for lack of other options, is that affected applications are recompiled against openssl, suggesting this is a gnutls-specific bug. This is obviously an issue, due to openssl licensing problems (the reason the gnutls project exists).

To reiterate, recompiling against openssl solves these issues.

Jeremy Nickurak <atrus>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nmav (Posted a comment)
  • -email is unavailable- added by jas (Posted a comment)
  • -email is unavailable- added by wiml (Posted a comment)
  • -email is unavailable- added by atrus (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-02-05 nmav Open/ClosedOpen Closed
    2009-09-01 jas StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code