Emacs core TLS support
tzz at lifelogs.com
Wed Sep 15 13:01:27 CEST 2010
On Mon, 13 Sep 2010 09:49:30 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
NM> I cannot look at the patch but the example you are looking for is:
NM> to do the connection, and this one to verify the certificate:
Thanks for your help. I am still a little lost though :)
Can you give a specific command line that would start gnutls-serv so the
simple client (ex-client2.c) you reference will connect to it? If
that's not possible, is there a way to augment ex-client2.c so it
connects to an invocation of gnutls-serv without building all the
gnutls-cli (cli.c, etc.) infrastructure?
I can do a test connection with gnutls-cli but that's a much more
complicated program and I'm trying to get the simple connection working,
even without verification. If I can get the bare minimum SSL and TLS
working I can drop the patch into Emacs and get more eyes on it. I'm
tempted to do so now so I can stop sending this patch out :)
It would be wonderful, incidentally, if there was a way to configure all
the file options with a single string, similar to the priority string,
and just get back a session. A config file would also work if a single
string is too hard to parse. I don't see any options that couldn't work
like this and it would make setting up a GnuTLS connection much easier.
On Tue, 14 Sep 2010 20:55:51 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
NM> GNUTLS_E_AGAIN is returned only if the transport layer function
NM> (recv/send) return -1 and EAGAIN. Usually this is normal behavior and is
NM> enough to loop around them. Do you use non-blocking IO?
Ah, thanks for the hint. All the GnuTLS source code (e.g. the
do_handshake() function in cli.c) keeps looping forever as long as
GNUTLS_E_AGAIN is returned. That seems dangerous regardless of the
underlying mechanism because we don't want to lock up Emacs waiting for
a connection, but OTOH there's no other way to know if the handshake is
done. I limited it to 25000 times (used to be 25) in my patch. Is that
a reasonable limit? Should I base it on time elapsed?
With a limit of 25K and by checking `gnutls-error-fatalp' which calls
`gnutls_error_is_fatal', the handshake succeeds after 1250 tries against
a remote SSL server. So now against that server I get:
-24 (Decryption has failed.)
and against "gnutls-serv --priority NORMAL --http" I get
-12 (A TLS fatal alert has been received.)
(the server side says "Error in handshake
Error: Could not negotiate a supported cipher suite.")
which is a lot better: at least the handshake is no longer the problem
and it tells us the transport FDs are set correctly. So we can progress
to figuring out the bare minimum I mentioned above.
Latest patch attached, as usual.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 30665 bytes
Desc: not available
More information about the Gnutls-devel