From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/83886 Path: news.gmane.org!not-for-mail From: Vincent Bernat Newsgroups: gmane.emacs.gnus.general Subject: Re: Builtin GnuTLS support and certificate verification Date: Sat, 16 Nov 2013 12:18:52 +0100 Message-ID: References: <87iowbt5dq.fsf@guybrush.luffy.cx> <878ux782na.fsf@dex.adm.naquadah.org> <874n7uu2gg.fsf@guybrush.luffy.cx> <87txftsnub.fsf@flea.lifelogs.com> <87li13q3dy.fsf@flea.lifelogs.com> <87a9hjaj2d.fsf@guybrush.luffy.cx> <87r4anhrh3.fsf@flea.lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1384600823 12528 80.91.229.3 (16 Nov 2013 11:20:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 Nov 2013 11:20:23 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M32142@lists.math.uh.edu Sat Nov 16 12:20:24 2013 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VhdvL-0001PA-9R for ding-account@gmane.org; Sat, 16 Nov 2013 12:20:23 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1Vhdu1-0007od-SX; Sat, 16 Nov 2013 05:19:01 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Vhdty-0007oP-HK for ding@lists.math.uh.edu; Sat, 16 Nov 2013 05:18:58 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Vhdtw-0004pH-OQ for ding@lists.math.uh.edu; Sat, 16 Nov 2013 05:18:58 -0600 Original-Received: from bart.luffy.cx ([78.47.78.131]) by quimby.gnus.org with esmtp (Exim 4.80) (envelope-from ) id 1Vhdtu-00057O-BR for ding@gnus.org; Sat, 16 Nov 2013 12:18:54 +0100 Original-Received: from bart.luffy.cx (localhost [127.0.0.1]) by bart.luffy.cx (Postfix) with ESMTP id BD5431423D for ; Sat, 16 Nov 2013 12:18:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=luffy.cx; h=from:to:subject :references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=postfix; bh=MKXTboRgc qHI37eSCuhBf4lanBg=; b=Kfeo9jH74kdK0ecVqIeI7/9LaidOt5gskSXxTGFKY Gpy+m+dfMASuiN73lPFG8cSkUyj931JyO1sGqDVy8JhvId/EKSkwaK2NDVRuVz40 C20ltTJqUsizgiFnrxbTMc9+87EyUvgN7UGnerwmMXQDxatMDK/M2eO3XmQ0GXjd 1o= DomainKey-Signature: a=rsa-sha1; c=simple; d=luffy.cx; h=from:to:subject :references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; q=dns; s=postfix; b=LPf EY81Rs7uexpP0E5vUoDFfZbq/8v+fkWIoiIaIl3UbHwN1mvfAZ0PwBp57gP9m/uX V780o54SMaGt16k1a41ZO3O3rKtHJeKgYUBxAHw5bHxGhZ3DeP7ARMAmf67ubjGU tvJu+fYhNv1WvBgEuHXP6zLEBTsekjY33eZFTpuA= Original-Received: from neo.luffy.cx (unknown [78.198.208.113]) by bart.luffy.cx (Postfix) with ESMTPS id 8F4CD14140 for ; Sat, 16 Nov 2013 12:18:53 +0100 (CET) Original-Received: by neo.luffy.cx (Postfix, from userid 500) id 799B62E7; Sat, 16 Nov 2013 12:18:52 +0100 (CET) In-Reply-To: <87r4anhrh3.fsf@flea.lifelogs.com> (Ted Zlatanov's message of "Mon, 11 Nov 2013 10:45:44 -0500") User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) X-Spam-Score: -2.0 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:83886 Archived-At: =E2=9D=A6 11 novembre 2013 16:45 CET, Ted Zlatanov =C2= =A0: > VB> But I suppose you would have to implement a "confirm on error" > VB> option. I cannot propose myself to implement that since I have > VB> absolutely no clue on how Emacs Lisp interface with C. > > I'm interested in your opinion. How would you expect Emacs (on the > GnuTLS C level or on the Gnus level) to handle these cases, and how > would you control them with customizable variables? > > - expired cert > - hostname mismatch > - self-signed cert, first time seen > - cert mismatch > > In general we have the problem of asking questions in the middle of > establishing a network connection. This is not easy with Emacs, whose > interactive ELisp layer is too complicated to be reliably called from > the C layer. So all of the above have to work without user > interaction. Not being able to interact with the user is not a big problem I think: we can still output messages to tell her what to do, right? By default, I would see that all checks are enabled by default: the certificate has not expired, the hostname matches and the certificate is signed by a known authority (certificates in `gnutls-trustfiles`). When something goes wrong, we get a buffer with the certificate in "clear text" (like openssl x509 -in ... -noout -text). If needed, this is something that I can dig and provide C code for GNU TLS. This output contains the certificate fingerprint. A user has the possibility to whitelist the fingerprint and bypass any test. We should have both `gnutls-whitelist-certificates` variable and an option to override this whitelist when using gnutls-negotiate. The rationale is that we can't expect all gnutls-negotiate users to implement whitelisting. I think that whitelisting by fingerprint is an improvement over what is currently done by browsers which whitelist a whole domain without pinning the certificate. In the same way as for whitelisting, default verification options should be a variable with possibility to override it by using the appropriate option of `gnutls-negotiate`. Verification options could be: - `expired-certificate` - `revoked-certificate` - `untrusted-certificate` - `hostname-mismatch` --=20 Let the machine do the dirty work. - The Elements of Programming Style (Kernighan & Plauger)