From: Ted Zlatanov <tzz@lifelogs.com>
To: ding@gnus.org
Subject: Re: Builtin GnuTLS support and certificate verification
Date: Sun, 03 Nov 2013 06:53:48 -0500 [thread overview]
Message-ID: <87txftsnub.fsf@flea.lifelogs.com> (raw)
In-Reply-To: <874n7uu2gg.fsf@guybrush.luffy.cx>
On Sat, 02 Nov 2013 18:40:31 +0100 Vincent Bernat <bernat@luffy.cx> wrote:
VB> ❦ 2 novembre 2013 12:27 CET, Julien Danjou <julien@danjou.info> :
>>> Is there a way to enable certificate verification for Gnus? If not, is
>>> there a way to force the old way to do TLS (by using an external
>>> program)?
>>
>> This has been on my TODO list a year. There was a thread I launched on
>> emacs-devel about that a year ago with Ted:
>>
>> http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00154.html
>> http://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00575.html
>>
>> I didn't have time to dig since then, but I'd appreciate any hint on
>> this subject. :)
VB> OK, I have just tested myself with:
VB> #v+
VB> (gnutls-negotiate
VB> :process (open-network-stream "test" nil "www.dailymotion.com" 443)
VB> :hostname "www.dailymotion.com"
VB> :verify-hostname-error t
VB> :verify-error t)
VB> #v-
VB> I don't know what "verify-error" is for since verify-hostname-error
VB> seems to handle any error like certificate expired, mismatched name or
VB> unknown root certificate.
According to gnutls.el:gnutls-negotiate:
When VERIFY-HOSTNAME-ERROR is not nil, an error will be raised
when the hostname does not match the presented certificate's host
name. The exact verification algorithm is a basic implementation
of the matching described in RFC2818 (HTTPS), which takes into
account wildcards, and the DNSName/IPAddress subject alternative
name PKIX extension. See GnuTLS' gnutls_x509_crt_check_hostname
for details. When VERIFY-HOSTNAME-ERROR is nil, only a warning
will be issued.
When VERIFY-ERROR is not nil, an error will be raised when the
peer certificate verification fails as per GnuTLS'
gnutls_certificate_verify_peers2. Otherwise, only warnings will
be shown about the verification failure.
`verify-error', however, is missing from the docstring of
gnutls.c:gnutls-boot and there's just a commented-out line in the
function:
/* Lisp_Object verify_error; */
and the verification code, as you observed, does all the peer
verification based on `verify-hostname-error'. I think this is my
error; this code:
if (peer_verification != 0)
{
if (NILP (verify_hostname_error))
GNUTLS_LOG2 (1, max_log_level, "certificate validation failed:",
c_hostname);
else
{
emacs_gnutls_deinit (proc);
error ("Certificate validation failed %s, verification code %d",
c_hostname, peer_verification);
}
}
should have been using `verify_error' instead.
Could you double-check my investigation and confirm? If you agree, I
will make the change and update the bug report.
VB> It works for me. Now, if I understand correctly, you are also trying to
VB> use `:trustfiles`.
VB> #v+
VB> (gnutls-negotiate
VB> :process (open-network-stream "test" nil "awesome.naquadah.org" 443)
VB> :hostname "awesome.naquadah.org"
VB> :verify-hostname-error t
VB> :verify-error t)
VB> #v-
VB> I get an error. Now, I extract the certificate and specify it with
VB> trustfiles option:
VB> #v+
VB> (gnutls-negotiate
VB> :process (open-network-stream "test" nil "awesome.naquadah.org" 443)
VB> :hostname "awesome.naquadah.org"
VB> :trustfiles '("/home/bernat/tmp/root.crt")
VB> :verify-hostname-error t
VB> :verify-error t)
VB> #v-
VB> And it works.
There is a default list of trustfiles in `gnutls-trustfiles'. It will
be used in the first case you show.
Ted
next prev parent reply other threads:[~2013-11-03 11:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-02 11:22 Vincent Bernat
2013-11-02 11:27 ` Julien Danjou
2013-11-02 17:40 ` Vincent Bernat
2013-11-02 21:09 ` Vincent Bernat
2013-11-03 11:53 ` Ted Zlatanov [this message]
2013-11-04 19:54 ` Vincent Bernat
2013-11-04 21:10 ` Ted Zlatanov
2013-11-04 22:38 ` Vincent Bernat
2013-11-11 15:45 ` Ted Zlatanov
2013-11-16 11:18 ` Vincent Bernat
2013-11-16 13:11 ` Julien Danjou
2013-12-08 4:22 ` Ted Zlatanov
2013-12-08 8:39 ` Vincent Bernat
2013-12-08 16:08 ` Ted Zlatanov
2013-12-14 18:06 ` Ted Zlatanov
2013-12-16 1:39 ` Katsumi Yamaoka
2013-12-16 6:31 ` Herbert J. Skuhra
2013-12-16 13:51 ` Tassilo Horn
2013-12-16 15:25 ` Ted Zlatanov
2013-12-16 15:24 ` Ted Zlatanov
2013-12-16 15:27 ` Ted Zlatanov
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=87txftsnub.fsf@flea.lifelogs.com \
--to=tzz@lifelogs.com \
--cc=ding@gnus.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).