From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= Newsgroups: gmane.emacs.devel Subject: Re: Network security manager Date: Tue, 18 Nov 2014 11:12:32 +0100 Message-ID: <87sihg7r73.fsf@alrua-karlstad.karlstad.toke.dk> References: <85a93pj1n5.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1416305585 384 80.91.229.3 (18 Nov 2014 10:13:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Nov 2014 10:13:05 +0000 (UTC) Cc: Stephen Leake , Kelvin White , Emacs development discussions To: Lars Magne Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 18 11:13:00 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 1XqfmN-0003uV-Hy for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2014 11:12:59 +0100 Original-Received: from localhost ([::1]:52176 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqfmM-0002YT-HO for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2014 05:12:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqfmF-0002Su-7w for emacs-devel@gnu.org; Tue, 18 Nov 2014 05:12:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XqfmA-00056g-28 for emacs-devel@gnu.org; Tue, 18 Nov 2014 05:12:51 -0500 Original-Received: from mail2.tohojo.dk ([77.235.48.147]:60283) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xqfm9-000569-M5; Tue, 18 Nov 2014 05:12:45 -0500 X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310; t=1416305179; bh=DEvRIkiLn4/gkBfl0h3yn49ND4ana5nZV2f7LKneF3g=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=DsziW4ylrv6xBvlLsiAt5eagPQIIn6pdgTSn6Kfd1coHCrzjd8dAg+OpzPkc8A+70 Q62Vw8KIqHMJQ/bXCRkQu/wBpHWvKKcmQ1FNoe1VoOQQ1dnp6A/swg0cb6t7srnp2X YxqHllxrqrTA7qjh9iIs3xv+xAzAUNVnbZsLaPrM= Original-Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id C25691E1BF1; Tue, 18 Nov 2014 11:12:32 +0100 (CET) In-Reply-To: (Lars Magne Ingebrigtsen's message of "Mon, 17 Nov 2014 23:53:10 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 77.235.48.147 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:177534 Archived-At: Lars Magne Ingebrigtsen writes: > But here's the feedback I need: Haven't tested the code, but feel like I can weigh in on some of this: > if (verification & GNUTLS_CERT_INVALID) > warnings = Fcons (list2 (intern (":invalid"), As far as I can tell from the GnuTLS example code, this is a flag that GnuTLS sets when a cert is not trusted, rather than when it's malformed (as I would have guessed from the name)? I.e. it doesn't ever appear on its own? > if (verification & GNUTLS_CERT_REVOKED) > warnings = Fcons (list2 (intern (":revoked"), This should probably be treated as fairly suspicious; since if the cert has been explicitly revoked, there's probably a reason (not sure how GnuTLS determines this second one; does it do OCSP revocation checks?). SO carrying on would probably be... ill-advised. Perhaps by default fail this completely (rather than ask), and optionally have a variable option to override it? > if (verification & GNUTLS_CERT_SIGNER_NOT_FOUND) > warnings = Fcons (list2 (intern (":signer-not-found"), > if (verification & GNUTLS_CERT_SIGNER_NOT_CA) > warnings = Fcons (list2 (intern (":self-signed"), Not sure which of these would indicate the common self-signed case? Could probably be both... > if (verification & GNUTLS_CERT_INSECURE_ALGORITHM) > warnings = Fcons (list2 (intern (":insecure"), I'd default to failing here as well; incidentally, does Emacs check the cipher mode of the connection itself (I'm assuming this warning pertains to the certificate itself, not the connection encryption). I have (setq gnutls-algorithm-priority "PFS") in my .emacs, but AFAIK that is not the default (and it does fail in some cases). For instance, in light of POODLE, turning off SSLv3 completely would probably be a good idea, at least as a default? > if (verification & GNUTLS_CERT_NOT_ACTIVATED) > warnings = Fcons (list2 (intern (":not-activated"), This would probably be an issue with the clock? > if (verification & GNUTLS_CERT_EXPIRED) > warnings = Fcons (list2 (intern (":expired"), I would expect this to be mostly benign (someone forgot to replace a cert), but can also indicate someone stole an old cert and is using it to MITM... > Which one is the real "self-signed" message? It's an important > distinction between a self-signed certificate and a forged > certificate... An important distinction, yes, but not one that can be made in general. The main indicator of a forged certificate is if the presented certificate does not match the one that is stored for the connection. If it does, it's a possible forgery, if not, it's (probably) fine. In the presence of rogue CAs, there's not really a better distinction to be made, in the worst case. However, in terms of UI we might be able to do a bit better. I'd advise taking a look at the Certificate Patrol firefox extension (http://patrol.psyced.org/), which does some heuristics to determine if a changed certificate is benign or not. The main thing it does is to look at the expiration date of the stored certificate; if that is expired (or close to being), and the new certificate has the same CA as the old one, it pops up a notice and continues. Otherwise, it interrupts the connection and pops up a warning dialog with the changes highlighted (including certificate fingerprint, CA chain etc). The common case should be that an expired certificate is simply renewed with the same CA, and this probably shouldn't be cause for alarm. The trouble is that some popular sites use multiple certificates simultaneously (corresponding to different endpoints in a server farm, I assume), which can give some spurious popups from this algorithm. Distinguishing these types of errors requires storing more than just the certificate fingerprint, of course, so don't know if it's worth it. If not, I'd treat any deviation from the stored value as suspicious. There's also the issue of ports and addresses: If I connect to a mail server on port 993 and get a certificate, there's a chance the same certificate is also used for submitting mail on port 587. If so, warning again could be avoided. On the other hand, folding the stored certificate into just being stored per hostname would fail if it is *not* the same certificate being used. So maybe treating ports as completely separate (as I think you're doing now?) is best. Finally, doing DANE verification (and trusting that more than the CA) would be nice; but not sure how viably it is presently. Sorry if that got a bit long; there seems to be quite a lot of cases to consider here. Will give the code a spin when I have chance :) -Toke