Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00

mrex@sap.com (Martin Rex) Fri, 08 August 2014 21:09 UTC

Return-Path: <mrex@sap.com>
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 EC6131A0379 for <tls@ietfa.amsl.com>; Fri, 8 Aug 2014 14:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 IsKR0h_KEYYC for <tls@ietfa.amsl.com>; Fri, 8 Aug 2014 14:09:27 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id D09D31B27A5 for <tls@ietf.org>; Fri, 8 Aug 2014 14:09:04 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s78L92gT017753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Aug 2014 23:09:02 +0200 (MEST)
In-Reply-To: <D00A7D64.189DD%uri@ll.mit.edu>
To: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
Date: Fri, 8 Aug 2014 23:09:02 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140808210902.8E0471ADFC@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EZpUVhO8R43RF30X87EuMKQ8kbU
Cc: "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
Subject: Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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: Fri, 08 Aug 2014 21:09:33 -0000

Blumenthal, Uri - 0558 - MITLL wrote:
>>...........I've also seen such
>>interop problems with Java (J2SE) client (using nio it seems),
>>that will simply not interop with 3DES-EDE (nor AES128-SHA),
>>and RC4 is the only alternative that works.
> 
> Could you please provide more information on this? What exactly did not
> interoperate? And details, please?


I know very little about Java, so I'll try to describe what happened.

A partner had writen some data aggregation tool in Java (with JBoss,
I believe) that was trying to submit that data as XML/SOAP via HTTPS
to our backend server, but they were encountering TLS handshake failures.

Our server was aborting the handshake with a fatal bad_mac(20) alert.
The error message that the partner saw when debugging his java client
was:

   javax.net.ssl.SSLException: Received fatal alert: bad record mac

I gave them a special debug build of our our SSL implementation that
had all "countermeasures" (bleichenbacher,vaudenay) disabled and
it turned out that the Java SSL client was sending bogus Finished
handshake message records (decryption resulted in random garbage,
including the padding value).  Since the Java client offered
AES128-SHA, our server would choose that (server preference).

The Java client was sending the following cipher suites in ClientHello:
(26 cipher suites, EMPTY_RENEGOTIATON_INFO_SCSV included, head only ):

  TLS_RSA_WITH_RC4_128_MD5          (0x0004)
  TLS_RSA_WITH_RC4_128_SHA          (0x0005)
  TLS_RSA_WITH_AES_128_SHA          (0x002f)
  TLS_DHE_RSA_WTIH_AES_128_CBC_SHA  (0x0033)
  TLS_DHE_DSS_WITH_AES_128_CBC_SHA  (0x0032)
  TLS_RSA_WTIH_3DES_EDE_CBC_SHA     (0x000a)
  TLS_DHE_RSA_WITH_3DES_ECE_CBC_SHA (0x0016)
  TLS_DHE_DSA_WITH_3DES_ECE_CBC_SHA (0x0013)
  TLS_RSA_WITH_DES_CBC_SHA          (0x0009)

>From that list our server will pick the 3rd in its default configuration.

So I suggested to them thre  tests with our server, limiting
our server's ciper suite to (1) AES128-SHA, (2) 3DES-EDE-SHA, (3) RC4-128,
and the test with AES128 and 3DES failed with bad-mac, whereas the test
with RC4-128 succeeded.

Then I asked them to try handshaking with an openssl s_server in similar
configurations, and the results were the same: bad_mac for the cipher
suites that were using CBC ciphers, success for RC4-128

>From what I remember, they were using J2EE 1.6


I do not know what part of the partner's software or the underlying
Java J2EE is causing these problems.  But with the RC4 ciphers first
in the Java's ClientHello and the bad habit of several TLS
implementations to yield to the clients ordering rather than using
the servers preference, the bug causing this interop problem may be
rather old have gone unnoticed for a long time.


The issue with 3DES is that it is *SLOW*.  much much slower than RC4-128.

If you look at Intels paper about improving openssl AES ciper suites
with AES-NI hardware support here:
  http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/open-ssl-performance-paper.pdf

they get merely the same throughput with AES-NI boosted AES-CBC cipher suites
as they get with plain old RC4-128.


RC4 cipher suites are a problem when applications on top use a disclosing
authentication scheme in the clear with an authentication token or password
that is valid essentially forever, and when clients can either be coerced
to send this disclosing authentication several million times (or do this
all by themselves).


-Martin