Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: exim: users

A TLS packet with unexpected length was received - maybe something new?

 

 

exim users RSS feed   Index | Next | Previous | View Threaded


jon at ts-tech

Sep 7, 2010, 3:40 AM

Post #1 of 5 (14089 views)
Permalink
A TLS packet with unexpected length was received - maybe something new?

Hi, I don't want to get into the back-story of this error, but did
want to raise an issue that I have just come across.


My customers mail server was not able to receive messages for
Microsoft's own hosted exchange service because on every connection
attempt there was a 'A TLS packet with unexpected length was received'
error. There was also 1 independently run Ex2007 server that was
causing the same problem.

After digging through bug reports and removing ca-certificates (or
dpk-reconfiguring) has completely stopped the problem


All of this may have been covered before, but as I noticed a change I
thought it may be worth reporting, I'm interested to hear if others
are having the same problems lately.


The bug must lie in gnutls or ca-certificates, yet all the Debian bugs
are in the Exim lists - but that mess is something for later.



--
Jonathan Plews


jon at syn

Sep 7, 2010, 2:03 AM

Post #2 of 5 (13975 views)
Permalink
A TLS packet with unexpected length was received - maybe something new? [In reply to]

Hi, I don't want to get into the back-story of this error, but did
want to raise an issue that I have just come across.


My customers mail server was not able to receive messages for
Microsoft's own hosted exchange service because on every connection
attempt there was a 'A TLS packet with unexpected length was received'
error. There was also 1 independently run Ex2007 server that was
causing the same problem.

After digging through bug reports and removing ca-certificates (or
dpk-reconfiguring) has completely stopped the problem


All of this may have been covered before, but as I noticed a change I
thought it may be worth reporting, I'm interested to hear if others
are having the same problems lately.


The bug must lie in gnutls or ca-certificates, yet all the Debian bugs
are in the Exim lists - but that mess is something for later ;)



--
Jonathan Plews
jon [at] syn
07971982608
01642919281


exim-users at spodhuis

Sep 8, 2010, 1:58 PM

Post #3 of 5 (13969 views)
Permalink
Re: A TLS packet with unexpected length was received - maybe something new? [In reply to]

On 2010-09-07 at 11:40 +0100, Jonathan Plews wrote:
> Hi, I don't want to get into the back-story of this error, but did
> want to raise an issue that I have just come across.
>
>
> My customers mail server was not able to receive messages for
> Microsoft's own hosted exchange service because on every connection
> attempt there was a 'A TLS packet with unexpected length was received'
> error. There was also 1 independently run Ex2007 server that was
> causing the same problem.
>
> After digging through bug reports and removing ca-certificates (or
> dpk-reconfiguring) has completely stopped the problem
>
>
> All of this may have been covered before, but as I noticed a change I
> thought it may be worth reporting, I'm interested to hear if others
> are having the same problems lately.
>
>
> The bug must lie in gnutls or ca-certificates, yet all the Debian bugs
> are in the Exim lists - but that mess is something for later.

Sounds like:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466477

reoccurring: ie, GnuTLS getting upset if there are too many certificate
authorities locally known.

GnuTLS bug.

Perhaps Exim could add an option to call
gnutls_handshake_set_max_packet_length() as Yet Another SSL Library
Tuning Option To Work Around Brokenness. But reportedly updating gnutls
fixes the problem, so why not update the broken software instead of
updating Exim to work around it? Or switch to OpenSSL.

Otherwise, if you're in a position to reproduce this and feel like
exploring, can you see what happens if you modify Exim's src/tls-gnu.c
to include a call to:
gnutls_handshake_set_max_packet_length(session, 64*1024);
in tls_session_init() around the gnutls_compat_mode area of the
function?

If you can confirm this works around the problem, I'll add knobs to Exim
to expose this setting to configuration and let people tune their way
around the bug in future.

-Phil

--
## List details at http://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/


jon at ts-tech

Sep 8, 2010, 2:36 PM

Post #4 of 5 (13978 views)
Permalink
Re: A TLS packet with unexpected length was received - maybe something new? [In reply to]

Quoting Phil Pennock <exim-users [at] spodhuis>:

> On 2010-09-07 at 11:40 +0100, Jonathan Plews wrote:
>> Hi, I don't want to get into the back-story of this error, but did
>> want to raise an issue that I have just come across.
>>
>>
>> My customers mail server was not able to receive messages for
>> Microsoft's own hosted exchange service because on every connection
>> attempt there was a 'A TLS packet with unexpected length was received'
>> error. There was also 1 independently run Ex2007 server that was
>> causing the same problem.
>>
>> After digging through bug reports and removing ca-certificates (or
>> dpk-reconfiguring) has completely stopped the problem
>>
>>
>> All of this may have been covered before, but as I noticed a change I
>> thought it may be worth reporting, I'm interested to hear if others
>> are having the same problems lately.
>>
>>
>> The bug must lie in gnutls or ca-certificates, yet all the Debian bugs
>> are in the Exim lists - but that mess is something for later.
>
> Sounds like:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466477
>
> reoccurring: ie, GnuTLS getting upset if there are too many certificate
> authorities locally known.
>
> GnuTLS bug.
>
> Perhaps Exim could add an option to call
> gnutls_handshake_set_max_packet_length() as Yet Another SSL Library
> Tuning Option To Work Around Brokenness. But reportedly updating gnutls
> fixes the problem, so why not update the broken software instead of
> updating Exim to work around it? Or switch to OpenSSL.
>
> Otherwise, if you're in a position to reproduce this and feel like
> exploring, can you see what happens if you modify Exim's src/tls-gnu.c
> to include a call to:
> gnutls_handshake_set_max_packet_length(session, 64*1024);
> in tls_session_init() around the gnutls_compat_mode area of the
> function?
>
> If you can confirm this works around the problem, I'll add knobs to Exim
> to expose this setting to configuration and let people tune their way
> around the bug in future.
>
> -Phil
>

Hi,

I can't directly reproduce the error but I have a number of servers
that have occurrences, so I can make changes and check the logs after
a day or so.

Error reporting of GNUTLS could be better, but in this case I think
its Exchange that is having a problem, see the patch at the end from
gnutls-help which seems to have removed the error. Since applying this
and enabling all the certs again no errors have come up in ~24 hrs
(5-10 per day before that)

2.10.1 did not fix the problem for me


I have never had any problems when sending from my Exim server to
theirs, but maybe Exim does not ask for all the certs?

Or is GNUTLS not dealing with the other end giving it an error message
rather than the next part of the handshake? I suppose the packet in
question needs to be captured to know that.

I will try your suggestion also and see if that fixes things too, I
suspect it will and just don't know enough to say which is the better
approach

Its ongoing and I should have time to do some testing and hopefully
get some useful data, more as I know it

Thanks and Regards

Jon

diff -ur exim4-4.71.bak/src/tls-gnu.c exim4-4.71/src/tls-gnu.c
--- exim4-4.71.bak/src/tls-gnu.c 2010-09-07 18:30:19.000000000 +0200
+++ exim4-4.71/src/tls-gnu.c 2010-09-07 18:32:25.000000000 +0200
@@ -539,6 +539,10 @@
GNUTLS_X509_FMT_PEM);
if (rc < 0) return tls_error(US"setup_certs", host, gnutls_strerror(rc));

+ /* Do not advertize the trusted CAs to the peer.
+ * FIXME: make it configurable */
+ gnutls_certificate_free_ca_names(x509_cred);
+
if (crl != NULL && *crl != 0)
{
if (!expand_check(crl, US"tls_crl", &crl_expanded))



--
Jonathan Plews


jon at syn

Oct 7, 2010, 5:13 AM

Post #5 of 5 (13818 views)
Permalink
Re: A TLS packet with unexpected length was received - maybe something new? [In reply to]

Quoting Phil Pennock <exim-users [at] spodhuis>:

> On 2010-09-07 at 11:40 +0100, Jonathan Plews wrote:
>> Hi, I don't want to get into the back-story of this error, but did
>> want to raise an issue that I have just come across.
>>
>>
>> My customers mail server was not able to receive messages for
>> Microsoft's own hosted exchange service because on every connection
>> attempt there was a 'A TLS packet with unexpected length was received'
>> error. There was also 1 independently run Ex2007 server that was
>> causing the same problem.
>>
>> After digging through bug reports and removing ca-certificates (or
>> dpk-reconfiguring) has completely stopped the problem
>>
>>
>> All of this may have been covered before, but as I noticed a change I
>> thought it may be worth reporting, I'm interested to hear if others
>> are having the same problems lately.
>>
>>
>> The bug must lie in gnutls or ca-certificates, yet all the Debian bugs
>> are in the Exim lists - but that mess is something for later.
>
> Sounds like:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466477
>
> reoccurring: ie, GnuTLS getting upset if there are too many certificate
> authorities locally known.
>
> GnuTLS bug.
>
> Perhaps Exim could add an option to call
> gnutls_handshake_set_max_packet_length() as Yet Another SSL Library
> Tuning Option To Work Around Brokenness. But reportedly updating gnutls
> fixes the problem, so why not update the broken software instead of
> updating Exim to work around it? Or switch to OpenSSL.
>
> Otherwise, if you're in a position to reproduce this and feel like
> exploring, can you see what happens if you modify Exim's src/tls-gnu.c
> to include a call to:
> gnutls_handshake_set_max_packet_length(session, 64*1024);
> in tls_session_init() around the gnutls_compat_mode area of the
> function?
>
> If you can confirm this works around the problem, I'll add knobs to Exim
> to expose this setting to configuration and let people tune their way
> around the bug in future.
>
> -Phil
>
> --
> ## List details at http://lists.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/
>

Hi,

It's been a while since I started this thread but I thought I should
update it, even though my conclusion is not very helpful.

I have 2 servers that are having the problem, one was modified as
above, the other to not offer any ca certs at all - both have not had
any further problems (but I have checked that messages have been
delivered from the problem senders)

The problem now is that I cannot force these errors without
potentially disrupting my clients emails. To test further I'd need to
set up a server at home to receive for an unused domain, and sign up
for a trial of MS Hosted exchange. Before this I'd want to revert one
of the patched servers just to be sure the problem still exists.

I would do this if asked, but I'm not sure if it's worth the effort.
The core issue seems to be error handling in both GNUTLS and Exchange.

I'm going to send a message to the GNUTLS list because I think the
errors its giving could be more helpful, normally I'd jump at the
chance to generate a load of debug info, but for the days when
searching based on an error in standard logs is all you have time for
it would be good to have less dead ends. That's my conclusion from
this experience anyway :)

Regards

Jonathan Plews

exim users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.