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.