From: Ted Zlatanov <tzz@lifelogs.com>
To: emacs-devel@gnu.org
Subject: Re: Testing the gnutls support
Date: Mon, 11 Oct 2010 09:02:20 -0500 [thread overview]
Message-ID: <87zkuk96ab.fsf@lifelogs.com> (raw)
In-Reply-To: m3d3rivzk6.fsf@quimbies.gnus.org
On Sun, 10 Oct 2010 17:26:49 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
LMI> Ted Zlatanov <tzz@lifelogs.com> 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
next prev parent reply other threads:[~2010-10-11 14:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-07 21:42 Testing the gnutls support Lars Magne Ingebrigtsen
2010-10-08 13:45 ` Ted Zlatanov
2010-10-09 13:18 ` Lars Magne Ingebrigtsen
2010-10-09 13:37 ` Eli Zaretskii
2010-10-09 13:56 ` Lars Magne Ingebrigtsen
2010-10-10 4:50 ` Ted Zlatanov
2010-10-10 15:26 ` Lars Magne Ingebrigtsen
2010-10-11 14:02 ` Ted Zlatanov [this message]
2010-10-11 16:25 ` Lars Magne Ingebrigtsen
2010-10-11 17:25 ` Ted Zlatanov
2010-10-14 21:37 ` Lars Magne Ingebrigtsen
2011-03-28 18:52 ` Ted Zlatanov
2011-03-28 19:08 ` Ted Zlatanov
2011-03-29 20:29 ` Lars Magne Ingebrigtsen
2011-04-01 14:35 ` Ted Zlatanov
2011-04-01 15:39 ` Lars Magne Ingebrigtsen
2011-04-01 20:11 ` Ted Zlatanov
2011-04-02 20:26 ` Lars Magne Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zkuk96ab.fsf@lifelogs.com \
--to=tzz@lifelogs.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.