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

[[e-mail] (Martin Rex)]

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