Re: [TLS] The risk of misconfiguration
Viktor Dukhovni <viktor1dane@dukhovni.org> Tue, 06 May 2014 22:13 UTC
Return-Path: <viktor1dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050C51A0573 for <tls@ietfa.amsl.com>; Tue, 6 May 2014 15:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level:
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, J_CHICKENPOX_74=0.6] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWxiLx17ND81 for <tls@ietfa.amsl.com>; Tue, 6 May 2014 15:13:49 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 88EB01A049F for <tls@ietf.org>; Tue, 6 May 2014 15:13:49 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1D11B2AA9FF; Tue, 6 May 2014 22:13:44 +0000 (UTC)
Date: Tue, 06 May 2014 22:13:44 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20140506221344.GB27883@mournblade.imrryr.org>
References: <CACsn0cnvV9c5aH5p8cD1fJEzF4dmNXBaEaHCfkX82AZqKOUYaQ@mail.gmail.com> <53692FC2.1060009@akr.io>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <53692FC2.1060009@akr.io>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Tam4dDVs4e_7MB9Jm9kXn90G58w
Subject: Re: [TLS] The risk of misconfiguration
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 May 2014 22:13:51 -0000
On Tue, May 06, 2014 at 07:53:54PM +0100, Alyssa Rowan wrote: > On 06/05/2014 19:48, Watson Ladd wrote: > > > I think the number of people who accidentally enabled ADH is an > > order of magnitude more than those who actually wanted it. > > +1. I never saw anyone enable ADH, NULL or EXPORT cipher suites > actually on purpose. I have definitely seen people do it by accident. The SMTP server that hosts your email runs Postfix: $ posttls-finger -lmay -c akr.io posttls-finger: Connected to entima.net[78.129.143.175]:25 posttls-finger: Anonymous TLS connection established to entima.net[78.129.143.175]:25: TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits) posttls-finger: Server is anonymous When remote Postfix systems employ unauthenticated opportunistic TLS to send you email (smtp_tls_security_level = may), they and your server will preferrentially use ADH and AECDH cipher-suites. Because any encryption at all is better than sending cleartext email, both your server and the remote SMTP clients typically leave both EXPORT and LOW cipher-grades enabled. This may change in Postfix 2.12 as I've seen no recent evidence of any systems that only support export-grade crypto. So I am inclined to disable EXPORT and LOW by default starting with 2.12 in 2015. Postfix also supports the use of NULL ciphers for client-certificate authenticated delivery to LMTP over the loopback interface, though this is not on by default (lmtp_tls_mandatory_ciphers = null). By the way, though it is nice to see your server publishing TLSA records for SMTP, the DANE WG draft for SMTP specifies that only certificate usages DANE-TA(2) and DANE-EE(3) are to be used with SMTP. You're publishing PKIX-EE(1). $ posttls-finger akr.io posttls-finger: using DANE RR: _25._tcp.entima.net IN TLSA 1 1 1 53:5B:F2:89:B0:04:2F:20:92:E7:90:2C:DF:91:DD:F9:F8:B9:62:66:81:C7:94:34:04:A4:22:78:FF:72:AF:46 posttls-finger: Connected to entima.net[78.129.143.175]:25 posttls-finger: entima.net[78.129.143.175]:25: depth=0 matched end entity public-key sha256 digest=53:5B:F2:89:B0:04:2F:20:92:E7:90:2C:DF:91:DD:F9:F8:B9:62:66:81:C7:94:34:04:A4:22:78:FF:72:AF:46 posttls-finger: Verified TLS connection established to entima.net[78.129.143.175]:25: TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) The reason posttls-finger verified this, is that Postfix implicitly maps PKIX-EE(1) to DANE-EE(3), because that's better than simply treating the TLSA RR as unusable. > The mere presence of NULL ciphersuites is dangerous: someone might > actually use them, and that's basically never a good idea. > > Take them out; keep them out; don't put them back in. Authenticated loopback IPC is a perfectly fine use-case for NULL cipher-suites. Don't confuse perfectly fine protocol capabilities with fragile user interfaces. The OpenSSL cipherlist is not an end-user interface, it is a configuration interface for developers. Applications need to expose higher-level application-specific configuration interfaces, and the better designed ones do. I, for one, am not surprised by HIGH including ADH cipher-suites. It is a good idea to read the documentation before cargo-cult cut/paste of cipherlist strings. HIGH refers only to the symmetric algorithm bit strength. It would not be a useful building-block if it did not represent an elementary property. The DEFAULT cipherlist in OpenSSL excludes aNULL and eNULL. Safe strictly stronger cipherlists that want to elicit server certificates need to start with "DEFAULT" and subtract: # High-grade authenticated ciphersuites only DEFAULT+HIGH # High-grade, sans MD5, DSS certs and RSA key exchange. DEFAULT:!LOW:!EXPORT:!MEDIUM:!MD5:!aDSS:!kRSA By the way mere use of a cipher suite that elicits certificates does not magically make authentication happen, there still needs to be some code for that too... -- Viktor.
- Re: [TLS] The risk of misconfiguration Nico Williams
- Re: [TLS] The risk of misconfiguration Watson Ladd
- Re: [TLS] The risk of misconfiguration Nico Williams
- Re: [TLS] The risk of misconfiguration Watson Ladd
- [TLS] The risk of misconfiguration Watson Ladd
- Re: [TLS] The risk of misconfiguration Alyssa Rowan
- Re: [TLS] The risk of misconfiguration James Cloos
- Re: [TLS] The risk of misconfiguration Viktor Dukhovni
- Re: [TLS] The risk of misconfiguration Nico Williams
- Re: [TLS] The risk of misconfiguration Andrei Popov
- Re: [TLS] The risk of misconfiguration Alyssa Rowan
- Re: [TLS] The risk of misconfiguration Viktor Dukhovni
- Re: [TLS] The risk of misconfiguration Viktor Dukhovni
- Re: [TLS] The risk of misconfiguration Ralph Holz
- Re: [TLS] The risk of misconfiguration Watson Ladd
- Re: [TLS] The risk of misconfiguration Viktor Dukhovni
- Re: [TLS] The risk of misconfiguration Watson Ladd
- Re: [TLS] The risk of misconfiguration Viktor Dukhovni
- Re: [TLS] The risk of misconfiguration Watson Ladd
- Re: [TLS] The risk of misconfiguration Viktor Dukhovni
- Re: [TLS] The risk of misconfiguration Fedor Brunner
- Re: [TLS] The risk of misconfiguration Nikos Mavrogiannopoulos
- Re: [TLS] The risk of misconfiguration Warren Kumari
- Re: [TLS] The risk of misconfiguration Nico Williams
- Re: [TLS] The risk of misconfiguration Michael D'Errico
- Re: [TLS] The risk of misconfiguration Nico Williams
- Re: [TLS] The risk of misconfiguration Michael D'Errico
- Re: [TLS] The risk of misconfiguration Nico Williams
- Re: [TLS] The risk of misconfiguration Alyssa Rowan
- Re: [TLS] The risk of misconfiguration Nico Williams
- Re: [TLS] The risk of misconfiguration Viktor Dukhovni
- Re: [TLS] The risk of misconfiguration Viktor Dukhovni
- Re: [TLS] Fingerprinting weaknesses (was: The ris… Alyssa Rowan
- Re: [TLS] Fingerprinting weaknesses (was: The ris… Salz, Rich
- Re: [TLS] The risk of misconfiguration Alyssa Rowan
- Re: [TLS] Fingerprinting weaknesses (was: The ris… Viktor Dukhovni
- Re: [TLS] The risk of misconfiguration Nico Williams
- Re: [TLS] Fingerprinting weaknesses (was: The ris… Nico Williams
- Re: [TLS] The risk of misconfiguration Watson Ladd
- Re: [TLS] The risk of misconfiguration Nico Williams
- Re: [TLS] The risk of misconfiguration Watson Ladd
- Re: [TLS] Fingerprinting weaknesses (was: The ris… Watson Ladd
- Re: [TLS] The risk of misconfiguration Nico Williams
- Re: [TLS] Fingerprinting weaknesses (was: The ris… Nico Williams
- Re: [TLS] The risk of misconfiguration Viktor Dukhovni
- Re: [TLS] The risk of misconfiguration Watson Ladd
- Re: [TLS] The risk of misconfiguration Salz, Rich
- Re: [TLS] The risk of misconfiguration Viktor Dukhovni
- Re: [TLS] The risk of misconfiguration Manuel Pégourié-Gonnard
- Re: [TLS] The risk of misconfiguration Yoav Nir
- Re: [TLS] The risk of misconfiguration Salz, Rich
- Re: [TLS] The risk of misconfiguration Martin Rex
- Re: [TLS] The risk of misconfiguration Viktor Dukhovni
- Re: [TLS] The risk of misconfiguration Martin Thomson
- Re: [TLS] The risk of misconfiguration Stephen Farrell
- Re: [TLS] The risk of misconfiguration Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] The risk of misconfiguration Manuel Pégourié-Gonnard
- Re: [TLS] The risk of misconfiguration Viktor Dukhovni
- Re: [TLS] The risk of misconfiguration Russ Housley
- Re: [TLS] The risk of misconfiguration Bill Frantz
- Re: [TLS] The risk of misconfiguration Michael D'Errico
- Re: [TLS] The risk of misconfiguration Daniel Kahn Gillmor
- Re: [TLS] The risk of misconfiguration Viktor Dukhovni
- Re: [TLS] The risk of misconfiguration (Muphry's … Viktor Dukhovni
- Re: [TLS] The risk of misconfiguration Watson Ladd
- Re: [TLS] The risk of misconfiguration Stephen Farrell
- Re: [TLS] The risk of misconfiguration Viktor Dukhovni