Interoperability issues (Debian Bug #348046)
simon at josefsson.org
Tue Feb 26 18:09:28 CET 2008
Marc Haber <mh+gnutls-devel at zugschlus.de> 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, 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.
Generally, I am curious what the justification of re-generating the
gnutls-params are in the first place? Doesn't "gnutls-params" refer to
the diffie-hellman parameters? I recall that some people say you never
need to regenerate them at all, and I haven't seen anyone recommend that
you do regenerate them. I haven't seen any other gnutls application
servers generate diffie-hellman parameters.
>> > (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?
Yes. Each encryption of application data needs one byte of random
(urandom quality) data, for random message length padding.
>> > (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?
More information about the Gnutls-devel