Re: Testing the gnutls support

[Ted Zlatanov]

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

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);
  gnutls_certificate_set_verify_flags(xcred, 
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT);

(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",
              hostname);
      return GNUTLS_E_CERTIFICATE_ERROR;
    }
...
}

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
baggage.

Ted