From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Network security manager Date: Wed, 19 Nov 2014 06:09:15 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87vbmbe9b8.fsf@lifelogs.com> References: <85a93pj1n5.fsf@stephe-leake.org> <87sihg7r73.fsf@alrua-karlstad.karlstad.toke.dk> <87a93oilxl.fsf@lifelogs.com> <8761ebg6b5.fsf@lifelogs.com> <8761eb68z8.fsf@alrua-karlstad.karlstad.toke.dk> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1416395369 29795 80.91.229.3 (19 Nov 2014 11:09:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Nov 2014 11:09:29 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 19 12:09:24 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xr38V-0001ld-SU for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 12:09:24 +0100 Original-Received: from localhost ([::1]:57516 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr38V-0002UF-DQ for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 06:09:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr38C-0002U6-8q for emacs-devel@gnu.org; Wed, 19 Nov 2014 06:09:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr386-0006Ba-Rp for emacs-devel@gnu.org; Wed, 19 Nov 2014 06:09:04 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:60740) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr386-0006BV-HZ for emacs-devel@gnu.org; Wed, 19 Nov 2014 06:08:58 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xr383-0001eH-SX for emacs-devel@gnu.org; Wed, 19 Nov 2014 12:08:55 +0100 Original-Received: from c-98-229-61-72.hsd1.ma.comcast.net ([98.229.61.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Nov 2014 12:08:55 +0100 Original-Received: from tzz by c-98-229-61-72.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Nov 2014 12:08:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 117 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-61-72.hsd1.ma.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:Ism4QK0QryBaIdc5zqw8tHZG1ls= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:177730 Archived-At: On Wed, 19 Nov 2014 06:43:39 +0100 Toke Høiland-Jørgensen wrote: TH> Ted Zlatanov writes: >> * uses SSH-style gnutls_store_pubkey() and gnutls_verify_stored_pubkey() >> to DTRT and pins the public key rather than the certificate >> fingerprint. The pub keys are stored by default in a way that lets the >> user look them up by hostname, but we can customize that. And it's >> mostly handled by GnuTLS internals as far as pubkey extraction and >> verification. TH> AFAICT this is functionally equivalent to what is currently in NSM; TH> except it stores the public key rather than the fingerprint. I am not TH> sure if there area any security implications to storing just the TH> fingerprint... See https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning#What_Should_Be_Pinned.3F Briefly, they say pinning the public key is better in most cases but is not subject to expiration like a certificate. Furthermore, see https://www.imperialviolet.org/2011/05/04/pinning.html section "Why public key hashes, not certificate hashes?" on Google's implementation and a stronger opinion. Excerpt: "In general, hashing certificates is the obvious solution, but the wrong one. The problem is that CA certificates are often reissued: there are multiple certificates with the same public key, subject name etc but different extensions or expiry dates. Browsers build certificates chains from a pool of certificates, bottom up, and an alternative version of a certificate might be substituted for the one that you expect. ... Conversely, public key hashes must be correct: Browsers assume that the leaf certificate is fixed: it's always the starting point of the chain. The leaf certificate contains a signature which must be a valid signature, from its parent, for that certificate. That implies that the public key of the parent is fixed by the leaf certificate. So, inductively, the chain of public keys is fixed, modulo truncation. The only sharp edge is that you mustn't pin to a cross-certifying root. For example, GoDaddy's root is signed by Valicert so that older clients, which don't recognise GoDaddy as a root, still trust those certificates. However, you wouldn't want to pin to Valicert because newer clients will stop their chain at GoDaddy. Also, we're hashing the SubjectPublicKeyInfo not the public key bit string. The SPKI includes the type of the public key and some parameters along with the public key itself. This is important because just hashing the public key leaves one open to misinterpretation attacks. Consider a Diffie-Hellman public key: if one only hashes the public key, not the full SPKI, then an attacker can use the same public key but make the client interpret it in a different group. Likewise one could force an RSA key to be interpreted as a DSA key etc." I am not a cryptographer so I hope some of those step in and suggest what's best. To me from what I know and based on the cited references, it seems it could be a choice but pinning the public key is better for most people. They won't have to accept again every time the certificate is reissued. >> * does DANE auth (although I don't know the details on DANE, the >> client implementation looks reasonable and Toke suggested it) TH> I think the right thing to do would probably be to check DANE and use TH> that as an additional input to the NSM dialog. I'd suggest the TH> following: TH> - Supply the DANE status as part of the 'certificate information' blurb TH> when popping up a prompt. For many (most?) setups this will be TH> 'unknown' either because no DANE info is published in DNS or DNSSEC TH> validation fails (or both). TH> - If valid DANE info is available *and* this doesn't match the shown TH> certificate, treat it as a reason to consider the certificate TH> insecure. TH> I.e. treat a positive DANE verification as information to present to the TH> user, and a verified failure as a cause for alarm. This corresponds to TH> the current DANE RFC recommendations AFAICT... Works for me. If we implement it in ELisp as Lars suggested it might even be easy. Could you please open the feature request in the bug tracker with your plan of action so we can keep it in mind? >> * checks OCSP for revocations using cert_verify_ocsp() in the same >> cli.c TH> This would probably be a good idea to implement in any case. I think Lars agrees, also with the "in ELisp if possible" caveat. Can you create a separate feature in the bug tracker? On Wed, 19 Nov 2014 09:44:49 +0100 Lars Magne Ingebrigtsen wrote: LMI> DANE and especially revocation checking is kinda slow though? Which is LMI> why Chrome doesn't do it. It's definitely in the high-to-paranoid level, but if the level can be enabled per site or per subnet, it would be ideal. On Wed, 19 Nov 2014 09:55:00 +0100 Lars Magne Ingebrigtsen wrote: LMI> Unfortunately, this seems to have been introduced in a later version of LMI> the library than what I have on my development machine, so I haven't LMI> been able to test. We can make such GnuTLS features optional or explicitly require the latest if the feature is very appealing. This one isn't to me :) I hate the "random art" and always disable it with SSH. Ted