[Top][All Lists]

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

Re: Testing the gnutls support

From: Ted Zlatanov
Subject: Re: Testing the gnutls support
Date: Mon, 11 Oct 2010 09:02:20 -0500
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)

On Sun, 10 Oct 2010 17:26:49 +0200 Lars Magne Ingebrigtsen <address@hidden> 

LMI> Ted Zlatanov <address@hidden> writes:
>> 1) we should be verifying the host name matches the certificate--but
>> should this be done in gnutls.el or gnutls.c?

LMI> The negotiation is done in emacs_gnutls_read now, sort of, isn't it?
LMI> I'm not quite sure how to pass that info back to Elisp land -- it'd have
LMI> to be a callback of some sort, wouldn't it?

Yes.  From GnuTLS doc/examples/ex-rfc2818.c:

(in main)

  gnutls_certificate_set_verify_function (xcred, verify_certificate_callback);

(and then)

/* This function will try to verify the peer's certificate, and
 * also check if the hostname matches, and the activation, expiration dates.
static int verify_certificate_callback (gnutls_session_t session)
  hostname = gnutls_session_get_ptr(session);
  ret = gnutls_certificate_verify_peers2 (session, &status);
  if (!gnutls_x509_crt_check_hostname (cert, hostname))
      printf ("The certificate's owner does not match hostname '%s'\n",

There's a lot more in that function but the basic idea is to make sure
the presented certificate matches the host name.

>> 2) we should set up a verification callback (but this is not available
>> in mainstream Debian/Ubuntu yet, since it's new in 2.10).  In the
>> callback we should let the user accept an invalid certificate.  I'd like
>> to defer this until 2.10 is in the Debian mainstream.

LMI> Sounds OK to me.

I can make an autoconf check to look for
gnutls_certificate_set_verify_function() and do the above.  I don't have
the tuits and 2.10 is not widely installed, though, so I would rather
not work on this right now.

>> 3) We should give users a way to accept certificates.  Right now they
>> can pass a list of trust file names themselves but I think this should
>> be a more general facility.

LMI> Yes.

My only concern is that someone can deposit a certificate in your
directory and fool you.  I think this should be a file of certificates
instead, which users can encrypt with EPA, or maybe store with the
Secrets API.  But that leads me back to auth-source.el since it already
has this kind of logic in it.  WDYT about depending on auth-source.el
for GnuTLS interactions?  I'm divided because OTOH gnutls.el is a
low-level wrapper and a dependency on auth-source.el will bring in other


reply via email to

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