Quoting Phil Pennock <[email protected]>:
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 meI 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
pgp4JwhI6lqAn.pgp
Description: PGP Digital Signature
-- ## 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/
