From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/67546 Path: news.gmane.org!not-for-mail From: Matthias Andree Newsgroups: gmane.emacs.gnus.general Subject: Re: Bug#499774: starttls is a joke Date: Wed, 08 Oct 2008 12:45:17 +0200 Message-ID: <48EC8F3D.1080908@gmx.de> References: <871vzca7gp.fsf@natisbad.org> <87y71kpmq7.fsf@bubble.risko.hu> <87od2g31hf.fsf@natisbad.org> <87tzc8upgf.fsf@marauder.physik.uni-ulm.de> <87fxnsjfu3.fsf@mocca.josefsson.org> <87wsh4gjgi.fsf@natisbad.org> <87prmjjosn.fsf@mocca.josefsson.org> <87abdgt4dm.fsf@mocca.josefsson.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1223462854 19832 80.91.229.12 (8 Oct 2008 10:47:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Oct 2008 10:47:34 +0000 (UTC) Cc: Daiki Ueno , RISKO Gergely , ding@gnus.org, Arnaud Ebalard To: Simon Josefsson Original-X-From: ding-owner+M15997@lists.math.uh.edu Wed Oct 08 12:48:30 2008 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.50) id 1KnWa9-00065h-8D for ding-account@gmane.org; Wed, 08 Oct 2008 12:47:53 +0200 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 1KnWYH-00034D-M4; Wed, 08 Oct 2008 05:45:57 -0500 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 1KnWYG-000340-4E for ding@lists.math.uh.edu; Wed, 08 Oct 2008 05:45:56 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.69) (envelope-from ) id 1KnWYB-00063n-95 for ding@lists.math.uh.edu; Wed, 08 Oct 2008 05:45:56 -0500 Original-Received: from mail.gmx.net ([213.165.64.20]) by quimby.gnus.org with smtp (Exim 3.36 #1 (Debian)) id 1KnWYG-0005G7-00 for ; Wed, 08 Oct 2008 12:45:56 +0200 Original-Received: (qmail invoked by alias); 08 Oct 2008 10:45:18 -0000 Original-Received: from balu.cs.uni-paderborn.de (EHLO [131.234.21.37]) [131.234.21.37] by mail.gmx.net (mp061) with SMTP; 08 Oct 2008 12:45:18 +0200 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX1+8KCEFtfa84KdzPzCs9tZ/57aFPdIXBRudhzFcNF 75Lor5rbVo0wn4 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.17) Gecko/20080914 Lightning/0.9 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666 In-Reply-To: <87abdgt4dm.fsf@mocca.josefsson.org> X-Enigmail-Version: 0.95.7 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.46 X-Spam-Score: -2.6 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:67546 Archived-At: Simon Josefsson schrieb: > Matthias Andree writes: > >> [Stripping Debian BTS bug from Cc: list] >> >> Simon Josefsson writes: >> >>> arno@natisbad.org (Arnaud Ebalard) writes: >>> >>>>>>> "This software does not have any authentication capabilities: it does >>>>>>> not allow you to authenticate your peer, which is a basic requirement >>>>>>> for TLS/SSL to be used securely. You should only use it for testing >>>>>>> purposes and not relaying important information. Be aware that you are >>>>>>> vulnerable to MITM when using it" >>>>> That seems correct to me. >>>>> >>>>> Note that even if you use gnutls-cli, you need to configure it to use >>>>> appropriate trust anchors to get full security. >>>> ^^^^^^^^^^^^^ >>>> >>>> I hope you mean "a working setup". If you do not provide it any (set of) >>>> trust anchor, it should not be able to verify server's certificate and >>>> should fail, shouldn't it? >>> Right, and that's what I meant with "you need to configure it to use >>> appropriate trust anchors". If you do that, you should get full >>> security (whatever that means). >> Please change that for gnutls-cli 2.8.0 - preferably, the tool should >> get a new name then to make the change of paradigm obvious to consumers >> such as Gnus. > > You've lost me, exactly what change are you talking about? And what is > wrong today? > > /Simon Sorry for not wording carefully enough. Two issues: 1. gnutls-cli 2. gnus's use of starttls, gnutls-cli, and thereabouts. 1. GNUTLS-CLI ------------- Problem: gnutls-cli will happily establish a connection without any "trust anchors", even though it knows the connection is untrusted. This behaviour is NOT clearly documented. See below (Goals). Example: (below, I masked hostname and IP, and I numbered lines, but the rest is verbatim from a connection to a production machine somewhere in Germany.) This is Cygwin BTW. Comments below the transcript. 1 $ gnutls-cli -v 2 gnutls-cli (GnuTLS) 2.4.1 3 $ gnutls-cli -p 993 host.example.org 4 Resolving 'host.example.org'... 5 Connecting to '10.9.8.7:993'... 6 - Certificate type: X.509 7 - Got a certificate list of 4 certificates. [certificate info snipped] 8 - Peer's certificate issuer is unknown 9 - Peer's certificate is NOT trusted 10 - Version: TLS1.0 11 - Key Exchange: RSA 12 - Cipher: AES-128-CBC 13 - MAC: SHA1 14 - Compression: NULL 15 - Handshake was completed 16 - Simple Client Mode: 17 * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID AUTH=GSSAPI AUTH=LOGIN AUTH=PLAIN SASL-IR] host.example.org Cyrus IMAP4 v2.3.11-Debian-2.3.11-3 server ready Comments: - the command line (l. 3) does not define trust anchors. Particularly, there is no "--x509cafile /path/to/file.pem" option. - gnutls-cli v2.4.1 figures that it doesn't trust the issuer, ll. 8 & 9. - at that point in time, gnutls-cli should drop the connection. Instead, it continues. Desired behaviour/Goals: - gnutls-cli should drop the connect somewhen between lines 9 and 16, and should NOT enter forwarding/simple client state. - if clients want unsafe behaviour, they should be made to specify that in some way, and the program defaults should be "safest possible" mode - it may make sense that gnutls-cli doesn't even try to connect/handshake if it has * neither "trust anchors" such as the --x509cafile * nor some --unsafely-skip-cert-validation command line option. - man page, help output and manual should be consistent, example (2.4.1 manpage of gnutls-cli): --x509cafile FILE Certificate file to use. --x509certfile FILE X.509 Certificate file to use. --x509fmtder Use DER format for certificates --x509keyfile FILE X.509 key file to use. This is pure crap^W^Wutterly unintelligible. What's the difference between --x509cafile and --x509certfile? It should read something like "--x509cafile: file that lists all Certification Authority (CA) certificates that gnutls-cli is allowed to trust. If this option is omitted, gnutls-cli will accept unsafe connections and trust any CA certificate. For secure operation, be sure to specify this option." If the observed behaviour is deliberate, there should be notes in the man page, in the --help output, in the manual, just about everywhere that clearly states two things: 1. not specifying --x509cafile disables certificate verification and allows undetected man-in-the-middle attacks - see above 2. for safe operation, you must specify --x509cafile foo, which see. (and possibly other options) Further consideration: - if the defaults are changed to "safe" mode, it may be sensible to rename the tool to gnutls-safe-client or something better. 2. GNUS ------- I suggest that the example configuration uses trust anchors in gnutls-cli along with step-by-step how-to instructions so that end users easily see what needs to be done to use gnutls-cli in a secure way - because gnutls-cli defaults to unsafe operation, at least 2.2.2 and 2.4.1 did, and starttls apparently is the acronym for Standard Tool Aiming aT Totally Lying about Security (in that it creates a false sense of "security"). -- Matthias Andree