Quoting Phil Pennock <exim-users@???>:
> 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
