Debian Bug report logs - #482279
libgnutls26: mutt is unable to talk with gmail with "A TLS packet with unexpected length was received." message

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Sergey Lapin <slapin@ossfans.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: libgnutls26: mutt is unable to talk with gmail with "A TLS packet with unexpected length was received." message

Date: Wed, 21 May 2008 19:17:38 +0400

Package: libgnutls26
Version: 2.2.3~rc-1
Severity: normal


When running mutt with gmeil in folder of about 16000 messages
w/o cache, it starts fetching headers then fails with message
"A TLS packet with unexpected length was received."
.muttdebug0:
...
5< )
parse_parameters: `charset="us-ascii"'
parse_parameter: `charset' = `us-ascii'
5< * 15955 FETCH (UID 15956 RFC822.SIZE 7191 INTERNALDATE "30-Apr-2008 15:27:27 +0000" 
FLAGS () 
BODY[HEADER.FIELDS (DATE FROM SUBJECT TO CC MESSAGE-ID REFERENCES CONTENT-TYPE 
CONTENT-DESCRIPTI
ON IN-REPLY-TO REPLY-TO LINES LIST-POST X-LABEL)] {372}
Handling FETCH
FETCH response ignored for this message
imap_read_literal: reading 372 bytes
From: Wolfgang Denk <wd@denx.de>
To: u-boot-users@lists.sourceforge.net
Date: Wed, 30 Apr 2008 17:26:49 +0200
Message-Id: <1209569209-10099-1-git-send-email-wd@denx.de>
Cc: Wolfgang Denk <wd@denx.de>
Subject: [U-Boot-Users] [PATCH] Makefile: fix parallel builds
List-Post: <mailto:u-boot-users@lists.sourceforge.net>
Content-Type: text/plain; charset="us-ascii"

5< )
parse_parameters: `charset="us-ascii"'
parse_parameter: `charset' = `us-ascii'
5< * 15956 FETCH (UID 15957 RFC822.SIZE 5102 INTERNALDATE "30-Apr-2008 15:35:18 +0000" 
FLAGS () BODY[HEADER.FIELDS (DATE FROM SUBJECT TO CC MESSAGE-ID REFERENCES CONTENT-TYPE 
CONTENT-DESCRIPTION IN-REPLY-TO REPLY-TO LINES LIST-POST X-LABEL)] {408}
Handling FETCH
FETCH response ignored for this message
imap_read_literal: reading 408 bytes
Date: Wed, 30 Apr 2008 21:04:33 +0530
Message-ID: <47230CE166B64744B0120173E4C2161E04D531CF@BLR-EC-MBX01.wipro.com>
From: <vivek.trivedi@wipro.com>
To: <u-boot-users@lists.sourceforge.net>
Cc: kim.phillips@freescale.com
Subject: [U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode
List-Post: <mailto:u-boot-users@lists.sourceforge.net>
Content-Type: text/plain; charset="us-ascii"

5< )
parse_parameters: `charset="us-ascii"'
parse_parameter: `charset' = `us-ascii'
tls_socket_read (A TLS packet with unexpected length was received.)
imap_cmd_step: Error reading server response.



-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-ovz028stab039.1-smp (SMP w/2 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libgnutls26 depends on:
ii  libc6                  2.7-10            GNU C Library: Shared libraries
ii  libgcrypt11            1.4.1-1           LGPL Crypto library - runtime libr
ii  libgpg-error0          1.4-2             library for common error values an
ii  libopencdk10           0.6.6-1           Open Crypto Development Kit (OpenC
ii  libtasn1-3             1.4-1             Manage ASN.1 structures (runtime)
ii  zlib1g                 1:1.2.3.3.dfsg-12 compression library - runtime

libgnutls26 recommends no packages.

-- no debconf information

Message #10 received at 482279@bugs.debian.org (full text, mbox, reply):

From: Simon Josefsson <simon@josefsson.org>

To: Sergey Lapin <slapin@ossfans.org>

Cc: 482279@bugs.debian.org

Subject: Re: [Pkg-gnutls-maint] Bug#482279: libgnutls26: mutt is unable to talk with gmail with "A TLS packet with unexpected length was received." message

Date: Tue, 14 Oct 2008 13:14:12 +0200

Sergey Lapin <slapin@ossfans.org> writes:

> When running mutt with gmeil in folder of about 16000 messages
> w/o cache, it starts fetching headers then fails with message
> "A TLS packet with unexpected length was received."

Thanks for the report.  How reproducible is this?  Can you try
libgnutls26 from testing?

If it is reproducible with the latest version, please try 'gnutls-cli -d
4711' against the server and send the same IMAP commands that mutt did,
and post the final part of the debug output.

It could be a server disconnecting you, or a firewall messing with the
traffic.  Possibly the server could be trying to re-handshake as well,
and there is some bug.

/Simon

Message #19 received at 482279@bugs.debian.org (full text, mbox, reply):

From: Mike <stuff@mikepalmer.net>

To: 482279@bugs.debian.org

Subject: Same thing happens with python-pycurl

Date: Sat, 23 May 2009 21:29:21 -0700

For me it always happens when I was on a network with a Cisco ASA/ADSM 
dynamically routing traffic using lenny's packages. As I saw it, anytime 
you ping something and get Redirect() you will always get this message 
and not be able to connect from a binary built against libgnutls. In the 
case of python-pycurl, I just rebuilt against openssl to get me around 
the error since I needed a solution immediately. Unfortunately, none of 
those networks I saw it on are available to me for testing past fixing 
the problem for the appliance-like debian image we give to customers.

Anyways, just thought I would drop in and hopefully give you guys a clue 
into reproducing this bug. Seems like a rather nasty one considering it 
can't handshake at all and ~170 packages in stable depend on this 
library. Sorry I can't be of more use.

Message #24 received at 482279@bugs.debian.org (full text, mbox, reply):

From: Simon Josefsson <simon@josefsson.org>

To: Mike <stuff@mikepalmer.net>

Cc: 482279@bugs.debian.org

Subject: Re: Bug#482279: Same thing happens with python-pycurl

Date: Mon, 25 May 2009 12:14:40 +0200

Mike <stuff@mikepalmer.net> writes:

> For me it always happens when I was on a network with a Cisco ASA/ADSM
> dynamically routing traffic using lenny's packages. As I saw it,
> anytime you ping something and get Redirect() you will always get this
> message and not be able to connect from a binary built against
> libgnutls.

Can you reproduce it with gnutls-cli?  As suggested earlier in this bug,
please run 'gnutls-cli -d 4711 some.https.host' and quote the output.

What kind of configuration is there on the Cisco box?  Does it modify or
filter traffic depending on some patterns?  Perhaps it doesn't recognize
TLS 1.1?

> In the case of python-pycurl, I just rebuilt against openssl to get me
> around the error since I needed a solution immediately. Unfortunately,
> none of those networks I saw it on are available to me for testing
> past fixing the problem for the appliance-like debian image we give to
> customers.
>
> Anyways, just thought I would drop in and hopefully give you guys a
> clue into reproducing this bug. Seems like a rather nasty one
> considering it can't handshake at all and ~170 packages in stable
> depend on this library. Sorry I can't be of more use.

Hm, what you are describing here does not seem to match the original
report for this bug.  In the original report, the handshake was
successful, only later (when entering a large mailbox) does it fail.

I suspect the causes for your problem and the problem of the original
reporter are different.

/Simon

Message #29 received at 482279@bugs.debian.org (full text, mbox, reply):

From: Simon Josefsson <simon@josefsson.org>

To: 482279@bugs.debian.org

Cc: Mike <stuff@mikepalmer.net>

Subject: Re: Bug#482279: Same thing happens with python-pycurl

Date: Mon, 25 May 2009 13:39:48 +0200

I just realized I wasn't clear what the likely cause of your problem is.
The problem may be caused by the server you are talking to.  Can you
access the servers that your clients use from your location?  Then
running 'gnutls-cli -d 4711' against that host may give enough details
to resolve it.

Earlier bug reports of this kind suggests that the server is buggy
(which can be worked around), but it may also be that the Cisco box is
filtering out the traffic if you are only seeing the problem behind
those boxes.

/Simon

Message #34 received at 482279@bugs.debian.org (full text, mbox, reply):

From: Mike <stuff@mikepalmer.net>

To: Simon Josefsson <simon@josefsson.org>

Cc: 482279@bugs.debian.org

Subject: Re: Bug#482279: Same thing happens with python-pycurl

Date: Mon, 25 May 2009 13:48:51 -0700

Simon Josefsson wrote:
> I just realized I wasn't clear what the likely cause of your problem is.
> The problem may be caused by the server you are talking to.  Can you
> access the servers that your clients use from your location?  Then
> running 'gnutls-cli -d 4711' against that host may give enough details
> to resolve it.
>
> Earlier bug reports of this kind suggests that the server is buggy
> (which can be worked around), but it may also be that the Cisco box is
> filtering out the traffic if you are only seeing the problem behind
> those boxes.
>
> /Simon
>   

Hi Simon,

I'm not really supposed to be doing this but this is the from the Cisco 
ASA network. I have no admin on anything outside of this box so I won't 
understand the configuration past seeing it dynamically redirect packets 
down different routes:

# gnutls-cli -d 4711 <our_host_here>
Resolving '<our_host_here_which_is_correct>'...
Connecting to '<our_ip_here>:443'...
|<3>| HSK[9e385a0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[9e385a0]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[9e385a0]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
|<3>| HSK[9e385a0]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[9e385a0]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[9e385a0]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
|<3>| HSK[9e385a0]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[9e385a0]: Keeping ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[9e385a0]: Keeping ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[9e385a0]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[9e385a0]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
|<3>| HSK[9e385a0]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<2>| EXT[9e385a0]: Sending extension CERT_TYPE
|<2>| EXT[9e385a0]: Sending extension SERVER_NAME
|<3>| HSK[9e385a0]: CLIENT HELLO was send [119 bytes]
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[9e385a0]: Sending Packet[0] Handshake(22) with length: 119
|<2>| ASSERT: gnutls_cipher.c:205
|<7>| WRITE: Will write 124 bytes to 4.
|<7>| WRITE: wrote 124 bytes to 4. Left 0 bytes. Total 124 bytes.
|<7>| 0000 - 16 03 02 00 77 01 00 00 73 03 02 4a 1a fa dc 32
|<7>| 0001 - c4 53 e3 da a8 9e e2 9b 3a dc ed 5a ec 60 33 b9
|<7>| 0002 - 59 5e 47 a5 cc 3d 92 95 2c ad 27 00 00 34 00 33
|<7>| 0003 - 00 45 00 39 00 88 00 16 00 32 00 44 00 38 00 87
|<7>| 0004 - 00 13 00 66 00 90 00 91 00 8f 00 8e 00 2f 00 41
|<7>| 0005 - 00 35 00 84 00 0a 00 05 00 04 00 8c 00 8d 00 8b
|<7>| 0006 - 00 8a 01 00 00 16 00 09 00 03 02 00 01 00 00 00
|<7>| 0007 - 0b 00 09 00 00 06 70 6f 72 74 61 6c
|<4>| REC[9e385a0]: Sent Packet[1] Handshake(22) with length: 124
|<7>| READ: -1 returned from 4, errno=104 gerrno=0
|<2>| ASSERT: gnutls_buffers.c:368
|<2>| ASSERT: gnutls_buffers.c:623
|<2>| ASSERT: gnutls_record.c:909
|<2>| ASSERT: gnutls_buffers.c:1152
|<2>| ASSERT: gnutls_handshake.c:1032
|<2>| ASSERT: gnutls_handshake.c:2331
|<6>| BUF[HSK]: Cleared Data from buffer
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GNUTLS ERROR: A TLS packet with unexpected length was received.


But lets try a known example like www.yahoo.com from the same network:

gnutls-cli -d 4711 www.yahoo.com
Resolving 'www.yahoo.com'...
Connecting to '69.147.76.15:443'...
|<3>| HSK[9c56ca8]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[9c56ca8]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[9c56ca8]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
|<3>| HSK[9c56ca8]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[9c56ca8]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[9c56ca8]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
|<3>| HSK[9c56ca8]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[9c56ca8]: Keeping ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[9c56ca8]: Keeping ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[9c56ca8]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[9c56ca8]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
|<3>| HSK[9c56ca8]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<2>| EXT[9c56ca8]: Sending extension CERT_TYPE
|<2>| EXT[9c56ca8]: Sending extension SERVER_NAME
|<3>| HSK[9c56ca8]: CLIENT HELLO was send [126 bytes]
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[9c56ca8]: Sending Packet[0] Handshake(22) with length: 126
|<2>| ASSERT: gnutls_cipher.c:205
|<7>| WRITE: Will write 131 bytes to 4.
|<7>| WRITE: wrote 131 bytes to 4. Left 0 bytes. Total 131 bytes.
|<7>| 0000 - 16 03 02 00 7e 01 00 00 7a 03 02 4a 1a fc 87 5d
|<7>| 0001 - 47 20 db 55 1f c9 a3 bc af 22 aa 32 af f7 1a fa
|<7>| 0002 - d8 6c 13 c1 06 4f e8 2d 12 ec 87 00 00 34 00 33
|<7>| 0003 - 00 45 00 39 00 88 00 16 00 32 00 44 00 38 00 87
|<7>| 0004 - 00 13 00 66 00 90 00 91 00 8f 00 8e 00 2f 00 41
|<7>| 0005 - 00 35 00 84 00 0a 00 05 00 04 00 8c 00 8d 00 8b
|<7>| 0006 - 00 8a 01 00 00 1d 00 09 00 03 02 00 01 00 00 00
|<7>| 0007 - 12 00 10 00 00 0d 77 77 77 2e 79 61 68 6f 6f 2e
|<7>| 0008 - 63 6f 6d
|<4>| REC[9c56ca8]: Sent Packet[1] Handshake(22) with length: 131
|<7>| READ: -1 returned from 4, errno=104 gerrno=0
|<2>| ASSERT: gnutls_buffers.c:368
|<2>| ASSERT: gnutls_buffers.c:623
|<2>| ASSERT: gnutls_record.c:909
|<2>| ASSERT: gnutls_buffers.c:1152
|<2>| ASSERT: gnutls_handshake.c:1032
|<2>| ASSERT: gnutls_handshake.c:2331
|<6>| BUF[HSK]: Cleared Data from buffer
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GNUTLS ERROR: A TLS packet with unexpected length was received.



Now for outside verification with an example you can try yourself (this 
one is on my home network and should work for you too):


# gnutls-cli -d 4711 www1.banking.first-direct.com
Resolving 'www1.banking.first-direct.com'...
Connecting to '193.108.74.220:443'...
|<3>| HSK[8e92ca8]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: DHE_PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: DHE_PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: DHE_PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: DHE_PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[8e92ca8]: Removing ciphersuite: SRP_SHA_RSA_AES_128_CBC_SHA1
|<3>| HSK[8e92ca8]: Removing ciphersuite: SRP_SHA_RSA_AES_256_CBC_SHA1
|<3>| HSK[8e92ca8]: Removing ciphersuite: SRP_SHA_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8e92ca8]: Removing ciphersuite: SRP_SHA_DSS_AES_128_CBC_SHA1
|<3>| HSK[8e92ca8]: Removing ciphersuite: SRP_SHA_DSS_AES_256_CBC_SHA1
|<3>| HSK[8e92ca8]: Removing ciphersuite: SRP_SHA_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[8e92ca8]: Keeping ciphersuite: PSK_SHA_AES_128_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: PSK_SHA_AES_256_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: PSK_SHA_3DES_EDE_CBC_SHA1
|<3>| HSK[8e92ca8]: Keeping ciphersuite: PSK_SHA_ARCFOUR_SHA1
|<3>| HSK[8e92ca8]: Removing ciphersuite: SRP_SHA_AES_128_CBC_SHA1
|<3>| HSK[8e92ca8]: Removing ciphersuite: SRP_SHA_AES_256_CBC_SHA1
|<3>| HSK[8e92ca8]: Removing ciphersuite: SRP_SHA_3DES_EDE_CBC_SHA1
|<2>| EXT[8e92ca8]: Sending extension CERT_TYPE
|<2>| EXT[8e92ca8]: Sending extension SERVER_NAME
|<3>| HSK[8e92ca8]: CLIENT HELLO was send [142 bytes]
|<6>| BUF[HSK]: Peeked 0 bytes of Data
|<6>| BUF[HSK]: Emptied buffer
|<4>| REC[8e92ca8]: Sending Packet[0] Handshake(22) with length: 142
|<2>| ASSERT: gnutls_cipher.c:205
|<7>| WRITE: Will write 147 bytes to 4.
|<7>| WRITE: wrote 147 bytes to 4. Left 0 bytes. Total 147 bytes.
|<7>| 0000 - 16 03 02 00 8e 01 00 00 8a 03 02 4a 1a fc 5b 64
|<7>| 0001 - 52 4e 81 87 2e 4d ac 2a cc e1 19 12 c7 36 4e e7
|<7>| 0002 - 3f bd 17 35 6a 65 5f 22 07 7b 12 00 00 34 00 33
|<7>| 0003 - 00 45 00 39 00 88 00 16 00 32 00 44 00 38 00 87
|<7>| 0004 - 00 13 00 66 00 90 00 91 00 8f 00 8e 00 2f 00 41
|<7>| 0005 - 00 35 00 84 00 0a 00 05 00 04 00 8c 00 8d 00 8b
|<7>| 0006 - 00 8a 01 00 00 2d 00 09 00 03 02 00 01 00 00 00
|<7>| 0007 - 22 00 20 00 00 1d 77 77 77 31 2e 62 61 6e 6b 69
|<7>| 0008 - 6e 67 2e 66 69 72 73 74 2d 64 69 72 65 63 74 2e
|<7>| 0009 - 63 6f 6d
|<4>| REC[8e92ca8]: Sent Packet[1] Handshake(22) with length: 147
|<7>| READ: Got 0 bytes from 4
|<7>| READ: read 0 bytes from 4
|<7>| 0000 -
|<2>| ASSERT: gnutls_buffers.c:638
|<2>| ASSERT: gnutls_record.c:909
|<2>| ASSERT: gnutls_buffers.c:1152
|<2>| ASSERT: gnutls_handshake.c:1032
|<2>| ASSERT: gnutls_handshake.c:2331
|<6>| BUF[HSK]: Cleared Data from buffer
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GNUTLS ERROR: A TLS packet with unexpected length was received.


All of these handshake correctly without problems under openssl on the 
same systems in the same networks against the same targets. Let me know 
if I can do anything else I can do to help identify anything with gnutls.

Message #39 received at 482279@bugs.debian.org (full text, mbox, reply):

From: Simon Josefsson <simon@josefsson.org>

To: Mike <stuff@mikepalmer.net>

Cc: 482279@bugs.debian.org

Subject: Re: Bug#482279: Same thing happens with python-pycurl

Date: Thu, 11 Jun 2009 11:54:16 +0200

clone 482279 -1
retitle -1 firewall causing TLS problems
tags -1 wontfix
tags -1 -moreinfo
thanks

Thanks for feedback!

The problem you see is different from the original report.  I am cloning
the report into two different numbers so we can separate the
discussions.  As far as I can tell, your problem is actually caused by
the firewall and not by GnuTLS, so I am tentatively tagging your problem
as wontfix because there is nothing we can do about it (at least not
without breaking things like TLS 1.1 that we want to support).

I'll respond with more details once a new bug number has been assigned.

/Simon

Message #46 received at 482279@bugs.debian.org (full text, mbox, reply):

From: Simon Josefsson <simon@josefsson.org>

To: 482279@bugs.debian.org

Cc: Sergey Lapin <slapin@ossfans.org>

Subject: Re: Bug#482279: [Pkg-gnutls-maint] Bug#482279: libgnutls26: mutt is unable to talk with gmail with "A TLS packet with unexpected length was received." message

Date: Thu, 11 Jun 2009 13:47:10 +0200

Simon Josefsson <simon@josefsson.org> writes:

> Sergey Lapin <slapin@ossfans.org> writes:
>
>> When running mutt with gmeil in folder of about 16000 messages
>> w/o cache, it starts fetching headers then fails with message
>> "A TLS packet with unexpected length was received."
>
> Thanks for the report.  How reproducible is this?  Can you try
> libgnutls26 from testing?
>
> If it is reproducible with the latest version, please try 'gnutls-cli -d
> 4711' against the server and send the same IMAP commands that mutt did,
> and post the final part of the debug output.
>
> It could be a server disconnecting you, or a firewall messing with the
> traffic.  Possibly the server could be trying to re-handshake as well,
> and there is some bug.

Sergey, do you still see this problem?

/Simon

Message #51 received at 482279@bugs.debian.org (full text, mbox, reply):

From: Sergey Lapin <slapin@ossfans.org>

To: Simon Josefsson <simon@josefsson.org>

Cc: 482279@bugs.debian.org

Subject: Re: Bug#482279: [Pkg-gnutls-maint] Bug#482279: libgnutls26: mutt is unable to talk with gmail with "A TLS packet with unexpected length was received." message

Date: Fri, 12 Jun 2009 12:22:58 +0400

On Thu, Jun 11, 2009 at 01:47:10PM +0200, Simon Josefsson wrote:
> Simon Josefsson <simon@josefsson.org> writes:
> 
> > Sergey Lapin <slapin@ossfans.org> writes:
> >
> >> When running mutt with gmeil in folder of about 16000 messages
> >> w/o cache, it starts fetching headers then fails with message
> >> "A TLS packet with unexpected length was received."
> >
> > Thanks for the report.  How reproducible is this?  Can you try
> > libgnutls26 from testing?
> >
> > If it is reproducible with the latest version, please try 'gnutls-cli -d
> > 4711' against the server and send the same IMAP commands that mutt did,
> > and post the final part of the debug output.
> >
> > It could be a server disconnecting you, or a firewall messing with the
> > traffic.  Possibly the server could be trying to re-handshake as well,
> > and there is some bug.
> 
> Sergey, do you still see this problem?
No, fixed in newer packages. Thanks!

Message #56 received at 482279-done@bugs.debian.org (full text, mbox, reply):

From: Simon Josefsson <simon@josefsson.org>

To: Sergey Lapin <slapin@ossfans.org>

Cc: 482279-done@bugs.debian.org

Subject: Re: Bug#482279: [Pkg-gnutls-maint] Bug#482279: libgnutls26: mutt is unable to talk with gmail with "A TLS packet with unexpected length was received." message

Date: Fri, 12 Jun 2009 10:31:44 +0200

Sergey Lapin <slapin@ossfans.org> writes:

> On Thu, Jun 11, 2009 at 01:47:10PM +0200, Simon Josefsson wrote:
>> Simon Josefsson <simon@josefsson.org> writes:
>> 
>> > Sergey Lapin <slapin@ossfans.org> writes:
>> >
>> >> When running mutt with gmeil in folder of about 16000 messages
>> >> w/o cache, it starts fetching headers then fails with message
>> >> "A TLS packet with unexpected length was received."
>> >
>> > Thanks for the report.  How reproducible is this?  Can you try
>> > libgnutls26 from testing?
>> >
>> > If it is reproducible with the latest version, please try 'gnutls-cli -d
>> > 4711' against the server and send the same IMAP commands that mutt did,
>> > and post the final part of the debug output.
>> >
>> > It could be a server disconnecting you, or a firewall messing with the
>> > traffic.  Possibly the server could be trying to re-handshake as well,
>> > and there is some bug.
>> 
>> Sergey, do you still see this problem?
> No, fixed in newer packages. Thanks!

Great, thanks for confirming.  I am closing this bug.

/Simon

Send a report that this bug log contains spam.