Interoperability issues (Debian Bug #348046)

Marc Haber mh+gnutls-devel at zugschlus.de
Sat Feb 23 22:37:36 CET 2008


On Fri, Jan 04, 2008 at 01:06:41PM +0100, Simon Josefsson wrote:
> Marc Haber <mh+gnutls-devel at zugschlus.de> writes:
> > Debian Bug #348046, http://bugs.debian.org/348046
> > =================================================

This bug report has been dissected into different bug reports, a few
of the issues are solved in the mean time. The submitters of the still
open issues have been pinged whether they can still reproduce the
issues at hand with current software. This dissection has been a major
effort, phew, done.

There is no need for the GnuTLS developers to take any more action,
Debian will now wait for the submitters to reply.

> > To me, after cursory inspection, this looks like:
> > (A) Original bug submitter complaining about "A TLS packet with
> >     unexpected length was received" when the local Exim is a _client_
> >     (Message 5).

This is now #467137, http://bugs.debian.org/467137, submitter pinged

> > (B) jarek saying "me too", but saying that his local Exim says
> >     "A TLS packet with unexpected length was received" while his Exim
> >     is a _server_ (Message 45)

This is now #467151, http://bugs.debian.org/467151, submitter pinged

> > (C) Ian Zimmerman trying to debug issue (B) but having trouble with
> >     gnutls-cli (Message 58)

That is actually OpenSSL bug #221689, http://bugs.debian.org/221689.
Now issue 467138, http://bugs.debian.org/467138, submitter pinged.

> > (E) Marc F .Clemente saying "me too" to (B) (Message 110)

#467152, http://bugs.debian.org/467152. Closed.

> (EE) Vincent Lefevre says (Message 120) that the first message each
>      morning fails with this error message too.
> 
> One theory here could be some firewall acting up the first time every
> morning, what do you think?  As Andreas Metzler says in message 125,
> there is nothing in the entropy code that could explain this.  The error
> message is also not entropy related.

This is #467158, http://bugs.debian.org/467158

This is interesting since it is the only issue in this report where
the exim giving the error message is the _client_. My guess is that
the gnutls-params file was just removed and the first sending exim
tried to re-generate the gnutls-params, which is a blocking operation.

This has been mitigrated in a later Debian exim package by (a)
disabling the RSAEXPORT ciphers and (b) doing the recalculation of the
gnutls-params asynchronously and only replacing the old file with the
new after the params were fully calculated. Submitter pined.

> > (F) Vincent Lefevre saying (Message 130), that outgoign messages also
> >     reduce entropy.
> 
> Which may be true.

Which _is_ true. Is that also addressed by saving the random seed?

> I'd add another item here too:
> 
> (FF) Ronny Adsetts reports a problem with a different error message 'A
>   record packet with illegal version was received.' and
>   '(gnutls_handshake): timed out'.
> 
> To me this looks like a connection problem.  The first error typically
> happens on data corruption (possibly caused by incorrect STARTTLS
> negotiation) or implementation problems.

Ronny Adsett's issue is #467136, http://bugs.debian.org/467136. He is
reporting this against the ancient version in Debian sarge. I have
pinged him and asked him whether this still happens with any more
current version.

> > (G) Andrew McGlashan finding it impossible to connect to gnutls-serv
> >     with incredimail (giving debug output in Message 224).

Incredimail issue, it cannot handle a client certificate request. Can
be remedied by disabling client certificates in exim. Same issue
happens of course when exim is compiled against OpenSSL, definetely
not a GnuTLS issue.

> First, Andrews' configuration seems confusing.  He's using
> tls_on_connect_ports on ports 587?  No wonder OE doesn't work.  I don't
> really understand what's not working and what he wants to do.

Incredimail cannot do STARTTLS and would be better configured to use
port 467. His setup of having 587 as tls_on_connect_port is likely to
break conforming clients, but incredimail doesn't care. Not our issue
here.

> Without more help from the IM community, I'd be inclined to sign this is
> off as a IM problem.

It definetely is.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190





More information about the Gnutls-devel mailing list