From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jens Lechtenboerger Newsgroups: gmane.emacs.bugs Subject: bug#16978: 24.3; SSL/TLS with multiple man-in-the-middle vulnerabilities Date: Mon, 10 Mar 2014 07:52:43 +0100 Message-ID: <86siqqv938.fsf@informationelle-selbstbestimmung-im-internet.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1394434816 29987 80.91.229.3 (10 Mar 2014 07:00:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Mar 2014 07:00:16 +0000 (UTC) To: 16978@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 10 08:00:24 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1WMuCE-0000JY-OY for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Mar 2014 08:00:22 +0100 Original-Received: from localhost ([::1]:46971 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMuCE-0004qi-Dg for geb-bug-gnu-emacs@m.gmane.org; Mon, 10 Mar 2014 03:00:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36681) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMuC4-0004aG-3Q for bug-gnu-emacs@gnu.org; Mon, 10 Mar 2014 03:00:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WMuBx-0007wm-7L for bug-gnu-emacs@gnu.org; Mon, 10 Mar 2014 03:00:12 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57467) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMuBx-0007wS-4d for bug-gnu-emacs@gnu.org; Mon, 10 Mar 2014 03:00:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WMuBv-0008Fa-Hn for bug-gnu-emacs@gnu.org; Mon, 10 Mar 2014 03:00:04 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jens Lechtenboerger Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Mar 2014 07:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 16978 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.139443479131655 (code B ref -1); Mon, 10 Mar 2014 07:00:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 10 Mar 2014 06:59:51 +0000 Original-Received: from localhost ([127.0.0.1]:58649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WMuBi-0008EU-In for submit@debbugs.gnu.org; Mon, 10 Mar 2014 02:59:51 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33844) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WMu5D-00082t-4u for submit@debbugs.gnu.org; Mon, 10 Mar 2014 02:53:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WMu55-0005bx-RB for submit@debbugs.gnu.org; Mon, 10 Mar 2014 02:53:06 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:35880) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMu55-0005bs-O9 for submit@debbugs.gnu.org; Mon, 10 Mar 2014 02:52:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35514) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMu4z-0001wA-Mc for bug-gnu-emacs@gnu.org; Mon, 10 Mar 2014 02:52:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WMu4s-0005YY-TC for bug-gnu-emacs@gnu.org; Mon, 10 Mar 2014 02:52:53 -0400 Original-Received: from moutng.kundenserver.de ([212.227.17.24]:51049) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WMu4s-0005YG-J3 for bug-gnu-emacs@gnu.org; Mon, 10 Mar 2014 02:52:46 -0400 Original-Received: from PC (mnsr-4db0a03e.pool.mediaWays.net [77.176.160.62]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0LnBO9-1WoIGf1XTR-00hROA; Mon, 10 Mar 2014 07:52:44 +0100 OpenPGP: id=0xA142FD84; url=http://www.informationelle-selbstbestimmung-im-internet.de/A142FD84.asc User-Agent: Gnus/5.130009 (Ma Gnus v0.9) Emacs/24.3 (gnu/linux) X-Provags-ID: V02:K0:4rQQkwE5RiRyvRvbLdoxNxjGapYSKBukbcgnt1cVcK7 jL1cBkABSWOHo8dC5TwEotXuDBSFYY5cdhVSgExDw5ayYmzROX Eqi6qJ5tLoCvVlemJrdHi8Okf0+XJV01z/82pRHgX08qpm3i87 LN7qDuh8U405ocXFAo5/wapVzcWyoZbEcfb+u3hYuwS10DoKaw 3Hnl0yHz8YWMtSbrGNmx32LnM5rmNEapvqyy8e+/mTqisSwYZZ 4fBpJXJ6mwFb+CYUGKQOpF91PECAWEZe3yRBtnLeYBn8BCx+e6 WOleGBA126bchVrksWXaih1sMQ6EzEFiKMIZCG1MkIlzUFrVUR /Xxn8zPjBeceip6HhdyEaq4kRCrhsRTVHpWLW0THq5N0AoMuc2 8/wcrElbCC2+g== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Mailman-Approved-At: Mon, 10 Mar 2014 02:59:49 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:86708 Archived-At: I'm using GNU Emacs 24.3.1. This affects Gnus v5.13 as well as Ma Gnus v0.9. I'm using Emacs to send e-mail via smtpmail.el with smtpmail-stream-type set to starttls, read e-mail via imap with :port 993 and :stream ssl, and send/read news via port 563 with nntp-open-tls-stream for nntp-open-connection-function. In all these cases, SSL/TLS "secured" connections are used that accept any certificate without checking the CA. Thus, man-in-the-middle (MITM) attacks will be successful and will go unnoticed. I don't find that acceptable. I vote to ship Emacs with certificate checking by default. That way, we would be protected from Mallory with self-signed, forged keys. I even vote for certificate pinning by default, which can protect us from Mallory with "trusted" keys (Mallory who pays, bribes, tricks, compels, forces, or operates an official CA). This can be accomplished via gnutls-cli with trust-on-first-use: gnutls-cli --tofu opens a TLS connection and asks whether the certificate can be trusted. If so, it is added to ~/.gnutls/known_hosts. On subsequent connections, the presented certificate is compared against the stored one; in case of mismatches, the user is asked whether to trust the new one. To prevent the process from hanging while waiting for the user's reply, option --strict-tofu (introduced in GnuTLS 3.2.12) can be used. I'm describing my view on certificate pinning in general and some details on TOFU with GnuTLS in more detail in my blog: https://blogs.fsfe.org/jens.lechtenboerger/?p=208 For Emacs, here is my personal workaround (a real fix would probably require a unified, secure-by-default treatment of TLS throughout all libraries): Smtpmail uses network-stream-open-starttls, which calls gnutls-negotiate (from gnutls.el) later on. The function gnutls-negotiate has parameters VERIFY-HOSTNAME-ERROR and VERIFY-ERROR, which might be useful to detect MITM attacks, yet they are not used. Also nntp-open-connection calls gnutls-negotiate without checking certificates. Thus, I disable gnutls.el entirely: (if (fboundp 'gnutls-available-p) (fmakunbound 'gnutls-available-p)) However, the problem is not restricted to gnutls.el. Once I disable that library, different fallbacks are used in different libraries. Smtpmail falls back to starttls-open-stream from starttls.el. In my case, that library uses gnutls-cli, and --strict-tofu can be added to starttls-extra-arguments: (setq starttls-extra-arguments '("--strict-tofu")) NNTP does not fall back to starttls.el but to open-tls-stream from tls.el. That library makes use of tls-program, which defaults to gnutls-cli with the switch --insecure. That switch is called "insecure" for a good reason and should be removed, IMO. Better yet, enable certificate pinning: (setq tls-program '("gnutls-cli --strict-tofu -p %p %h")) The library imap.el makes use of openssl's s_client via imap-ssl-program. While s_client is great to debug SSL/TLS connections, it is useless for everyday encryption as it prints an error message if certificates cannot be verified, but it opens the connection anyways. And, those errors are not shown in Emacs. So, switch to gnutls-cli with certificate pinning: (setq imap-ssl-program '("gnutls-cli --strict-tofu -p %p %s")) (Note that tls-program expects %h where imap-ssl-program uses %s.) Best wishes Jens