[gnutls-dev]Re: exim + gnutls

[Philip Hazel]

On Wed, 9 Oct 2002, Nikos Mavroyanopoulos 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,

I have now managed to find time to look at your patch, but I'm having a
problem making it work. I had to re-organize it so that I could
conditionally compile Exim either for OpenSSL or for GnuTLS, but I don't
think I actually changed any of your code significantly. I have a number
of comments:

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.
Also, there are calls to Exim that don't send or receive messages; it's
a waste of time for them. I changed the code so that the daemon does
make the call - that makes sense for incoming messages via the daemon,
and then I had to put it also in the server/client start-up code for the
individual cases.

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
it's going to be using TLS in many cases until it has actually connected
to the remote host. Thus, you don't want to spend resources on expensive
initialization until you know that TLS is going to be used.

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,
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
I had successfully used with OpenSSL. Can the key and the certificate be
in the same file, as they can for OpenSSL? (I tried both ways, but still
got the error.) I'll copy the certificate file below, for your
information. It's just a self-signed certificate for testing. If you can
suggest a good way for me to find out what's going wrong here, I'd be
grateful.

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.

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.

6. Your previous comment about waiting for the client to close after a
startup failure is deliberate. I think I must have based it on these
words from RFC 2487:

   If the SMTP server decides that the level of authentication or
   privacy is not high enough for it to continue, it SHOULD reply to
   every SMTP command from the client (other than a QUIT command) with
   the 554 reply code (with a possible text string such as "Command
   refused due to lack of security").

This isn't quite the case of a failed handshake, of course.

7. The problem with HELP was a bug I knew about, and have now fixed.

Regards,
Philip

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



-----BEGIN CERTIFICATE-----
MIIDNjCCAp+gAwIBAgIBADANBgkqhkiG9w0BAQQFADB2MQswCQYDVQQGEwJVSzES
MBAGA1UEBxMJQ2FtYnJpZGdlMSAwHgYDVQQKExdVbml2ZXJzaXR5IG9mIENhbWJy
aWRnZTEaMBgGA1UECxMRQ29tcHV0aW5nIFNlcnZpY2UxFTATBgNVBAMTDFBoaWxp
cCBIYXplbDAeFw0wMjA0MTUwODA0MThaFw0yOTA4MzAwODA0MThaMHYxCzAJBgNV
BAYTAlVLMRIwEAYDVQQHEwlDYW1icmlkZ2UxIDAeBgNVBAoTF1VuaXZlcnNpdHkg
b2YgQ2FtYnJpZGdlMRowGAYDVQQLExFDb21wdXRpbmcgU2VydmljZTEVMBMGA1UE
AxMMUGhpbGlwIEhhemVsMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4eIDt
pcY7ff5P3yCnXXdLWNcewKgUBj6GuNqHAFrfbZq6tDlSZ3FXVvOwU4Rgn6ciGP5R
EYuR4TB26/PY+bJEVUMyAb8OmcE+l6aeG0kQlM3Wa0UUfo3GNt9U7+VU7puS3SwL
jKYSI6ny17xyFcukBkiRTOo3H6z0yM742wPFeQIDAQABo4HTMIHQMB0GA1UdDgQW
BBTEcwEd5VFb4YlzEKcvHKP/s4gpVDCBoAYDVR0jBIGYMIGVgBTEcwEd5VFb4Ylz
EKcvHKP/s4gpVKF6pHgwdjELMAkGA1UEBhMCVUsxEjAQBgNVBAcTCUNhbWJyaWRn
ZTEgMB4GA1UEChMXVW5pdmVyc2l0eSBvZiBDYW1icmlkZ2UxGjAYBgNVBAsTEUNv
bXB1dGluZyBTZXJ2aWNlMRUwEwYDVQQDEwxQaGlsaXAgSGF6ZWyCAQAwDAYDVR0T
BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQBpuWb36BAO+aDbCWVSnt8C2rAz3Ii7
05kmrTugCiDj4VLHk6DL126Q6AuBWs9HKM/ynOOTcYTz20WkgpXaYf6Cdq/Z538d
tqD1gAAL2M04O6K41RLcIicVFeXWjjwp5tfQc+AMI7rD0FCHSbhY67+UHUFyoyFK
x8LiaV5jYIFfbg==
-----END CERTIFICATE-----