[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interoperability issues (Debian Bug #348046)

From: Marc Haber
Subject: Re: Interoperability issues (Debian Bug #348046)
Date: Tue, 26 Feb 2008 23:33:21 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

On Tue, Feb 26, 2008 at 06:09:28PM +0100, Simon Josefsson wrote:
> Marc Haber <address@hidden> writes:
> >> (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,
> >
> > 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.
> Generally, I am curious what the justification of re-generating the
> gnutls-params are in the first place?

Exim upstream recommends this, and since Philip often claims that he
knows little about TLS, he must have read this in some docs.

This is documented in exim's spec.txt chapter 39.3.

>   Doesn't "gnutls-params" refer to the diffie-hellman parameters?

The gnutls-params file used to contain diffie-hellman parameters and
some parameters necessary for RSAEXPORT, the latter having been
removed by Florian Weimer's patch a few months ago.

> >> > (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.
> Btw, how do you disable client certificate requests in exim?  Is it
> possible without recompilation?

Yes, that's a run-time configuration.

The global tls_try_verify_hosts option (which is by default unset) has
a host list, and if a connecting host is listed in this host list,
exim requests a certificate, checks it against the CA certificates
configured, logs the result, but does not abort the connection if the
presented certificate is "invalid". Debian's exim4 packages set this
to "*", enabling the certificate request globally, but offer an easy
method to override this.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]