[gnutls-dev]Re: exim + gnutls

[Nikos Mavroyanopoulos]

On Thu, Oct 24, 2002 at 04:51:50PM +0100, Philip Hazel wrote:

> >   I attach you, in case you are interested, a very preliminary patch
> > to exim, to use gnutls instead of openssl. I treat it as unstable
> > because I'm not familiar with exim's source code, and I didn't understand
> > many things.

> Hello Nikos,

> 1. One of the things you haven't realized is the way Exim works. It does
> not run as a continuously running process, except for the listening
> daemon. Outgoing messages arrive and are delivered in separate processes
> that do not have a common ancestor process. Thus, calling a global
> initialization function once near the start of Exim is not a good idea.
[...]

Yes I though so, but DH and RSA temporary parameters, need only to
be generated once[0]. Generating one per connection is as you've noticed
is too slow. What I can suggest here, is to store them in a file, which
should be shared by all exim proccesses.

[0]. they may be regenerated at some configurable intervals
  for security reasons

> 2. The next problem with the global initialization is that it takes a
> long time to generate the D-H parameters. I have in fact cut that out,
> because it delays starting up the daemon by quite a few seconds (on a
> SPARC Ultra 1 running Solaris 8). The RSA start-up is relatively quick,
> probably less than 1 second, which is still a while, but may be
> tolerable. When Exim is delivering a message, it doesn't know whether

This should be solved if (1) is solved.

> 3. Anyway, I tried testing the server with gnutls-cli-debug and the
> problem I have is the error NO_CERTIFICATE_FOUND from the call to
> gnutls_handshake(). I seem to be able to hand over the file names OK,

This is returned if the peer (client) did not send a certificate,
and a certificate was required[1]. 
This is set using gnutls_certificate_server_set_request().
I may not have implemented well, the previous "verify_optional" behaviour,
so now it requires a certificate to be sent by the peer if 
verify_optional==FALSE.

[1]. If you specified some certificate in gnutls-cli and the client didn't
send any, note that gnutls-cli only sends the certificate, if it's
issuer matches the CA names sent by the server. In gnutls if a server 
sets some trusted certificates, these CA names will be sent in the 
certificate request message.

To be more clear, in the handshake of TLS:
[...]
Server: Send a certificate signed by CA1 or CA2 or CA3 (the CAs I trust)
Client: I send you this one signed by CA1
[...]

If gnutls-cli doesn't have one signed by CA1, it will not send any.

> but it doesn't like what's in the file. Question: what format does the
> certificate and key have to be in? I was just using the same files that
It's the same format. If a certificate is not recognized, an error
will be returned at an earlier stage before handshake.

> 4. It is really good to have documentation with a complete list of
> functions, but it would be easier to find them for reference if they
> were in alphabetical order. A list of errors and explanations could also
> be useful - earlier I had MEMORY_ERROR, and had no idea what it meant.
> It went away when I changed something.

I'll probably add some script that sorts the function reference, and
a human readable description of the error strings returned by gnutls_strerror.
A MEMORY_ERROR though, is a bad thing. It is usually returned if a malloc
failed, or something like this.

> 5. There's a teeny buglet in gnutls-cli-debug. The command
>   gnutls-cli-debug localhost 1225
> (note: the -p is missing) doesn't complain: it tries to connect to port 443
Thank you. I've fixed this.

> Regards,
> Philip
> -- 
> Philip Hazel            University of Cambridge Computing Service,
> ph10 at cus.cam.ac.uk      Cambridge, England. Phone: +44 1223 334714.

-- 
Nikos Mavroyanopoulos
Email: nmav at gnutls org