IETF Logo Mail Archive

Re: [TLS] weird ECDSA interop problem with cloudflare/nginx

Benjamin Kaduk <bkaduk@akamai.com> Mon, 25 July 2016 21:19 UTC

Return-Path: <bkaduk@akamai.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE5F12DA43 for <tls@ietfa.amsl.com>; Mon, 25 Jul 2016 14:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.987
X-Spam-Level:
X-Spam-Status: No, score=-3.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com
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 wtDPyGRAVO8d for <tls@ietfa.amsl.com>; Mon, 25 Jul 2016 14:19:39 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id C3D5D12D0CA for <tls@ietf.org>; Mon, 25 Jul 2016 14:19:38 -0700 (PDT)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 62BF4423709 for <tls@ietf.org>; Mon, 25 Jul 2016 21:19:38 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 4214D423701 for <tls@ietf.org>; Mon, 25 Jul 2016 21:19:38 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1469481578; bh=PsaJ2B0AdMo03KG7AVtQyFxiuN/epAOabx8CNe2Ial0=; l=4262; h=To:References:From:Date:In-Reply-To:From; b=OsxOwZASyntM/6+Qp80PeF26h6ADcFBesTfVncZZ1HMBM5tVxWa29FVJ8WQKyfwvm /+pHrxplG2mE9StlmtXXNLz8ItHR6CurR+Lmar8apQV5YCSXbTRYTZ4ANcFbKSZrXo paZnlW5ALUUzDa0PRN5fNr6ZZiSn+BD5hIenWl0Q=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 2437E1FCB3 for <tls@ietf.org>; Mon, 25 Jul 2016 21:19:38 +0000 (GMT)
To: tls@ietf.org
References: <20160725190849.728521A508@ld9781.wdf.sap.corp> <05880081-C790-4D4C-9FF0-BA29F47C010A@dukhovni.org> <20160725210021.GA17403@LK-Perkele-V2.elisa-laajakaista.fi>
From: Benjamin Kaduk <bkaduk@akamai.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <4867e313-bc0f-43c9-f573-1ee2083211f9@akamai.com>
Date: Mon, 25 Jul 2016 16:19:37 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160725210021.GA17403@LK-Perkele-V2.elisa-laajakaista.fi>
Content-Type: multipart/alternative; boundary="------------C90C97F885227CECC1E19D49"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/n2KRqnAJU4dbC-PbrRVLDSKTi6Y>
Subject: Re: [TLS] weird ECDSA interop problem with cloudflare/nginx
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 25 Jul 2016 21:19:40 -0000

If I remember/understand correctly, the cloudflare patch for chacha/poly
would (when server preference is in use) only attempt to use it when it
appeared first in the client's preference list, and would ignore it
elsewhere.  This could potentially lead to negotiation failures if,
e.g., the server only supported chacha/poly but the client did not put
it first in the list.  That doesn't seem to match up with what is being
described here, but could provide some insight into where to look.

-Ben

On 07/25/2016 04:00 PM, Ilari Liusvaara wrote:
> On Mon, Jul 25, 2016 at 04:36:27PM -0400, Viktor Dukhovni wrote:
>>> On Jul 25, 2016, at 3:08 PM, Martin Rex <mrex@sap.com> wrote:
>>>
>>> specifically, after the FF update, this new TLS ciphersuite:
>>>
>>>   security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256  (0xcc, 0xa9)
>>>
>>> was the only ECDSA cipher suite enabled in my Firefox 47.0.1, and this
>>> kills connectivity (TLS handshake_failure alert) with regmedia.co.uk.
>> OpenSSL lists "CC, A9" as:
>>
>> 0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
> I wonder what is happening is that having ECDSA ciphersuite enabled
> causes Firefox to include the ECDSA signatures in signature_algorithms
> and the server end sees ECDSA supported, tries to choose that, but
> then blows up when it does not find any enabled ciphersuites it knows
> that support ECDSA...
>
>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email