Subject: [TLS] Windows 2003 TLS 64 ciphersuite limit

From: Nico Williams <[email-masked]>
Date: Thu, 7 Nov 2013 15:37:46 -0600

A non-subscriber (who doesn't want to subscribe just to send this) has
asked me to forward this to the TLS WG list.  Without further ado:

From: Viktor Dukhovni <[email-masked]>
Subject: Windows 2003 TLS 64 ciphersuite limit
Date: Thu, 7 Nov 2013 19:40:16 +0000

[ Please forward to TLS list ]

While we're removing interoperability obstacles with TLSv1.2, ... 
There is another problem with expanded client HELLO messages.

The Windows 2003 TLS stack (still used by a non-trivial number of
Microsoft Exchange SMTP servers) only looks at the first 64 elements
of the cipherlist.  If neither RC4-SHA nor RC4-MD5 are among these,
it sometimes chooses 3DES (for which it misimplements CBC padding)
and fails during data transfer, or if that is suppressed or also
too far down the list, just fails the handshake.

With TLSv1.2 in OpenSSL master (dev branch), one usually finds RC4
at position:

    $ openssl ciphers -v 'DEFAULT' | grep -n '^RC4-'
    93:RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

    $ openssl ciphers -v 'ALL:!SSLv2' | grep -n '^RC4-'
    111:RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

so TLS handshakes with these servers fail!

It is not clear what should be done here, the most practical
reordering and trimming that comes to mind is:

    $ openssl ciphers -v 'ALL:!SSLv2:-RC4:RC4-SHA:RC4:+SEED:!IDEA:!3DES:!MD5:!aDSS:!aDH:!PSK:!SRP:@STRENGTH' | grep -n '^RC4-SHA'
    51:RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

Which does not leave much room for more ciphers.  I've never seen
DSS or DH certificates in the wild, but presumably they are needed
in some quarters, so this is likely not a generally applicable
solution.

I don't know how much longer such servers are likely to remain
active.  Postfix users are working around this with custom cipher
exclusions in the per-destination TLS policy table on a case-by-case
basis. :-(

The best outcome would be if they all got upgraded!  This will take
some time I imagine.

-- 
	Viktor.

---

From: Wan-Teh Chang <[email-masked]>
Date: Mon, 11 Nov 2013 10:18:17 -0800

> too far down the list, just fails the handshake.

Thank you for forwarding this message. This is useful information.

This seems to imply we must include RC4-SHA or RC4-MD5 in the cipher
suite list to prevent the Windows Server 2003 from selecting 3DES.

>     51:RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1

Yes, trimming weak, export, and rarely used ciphers is a good solution.

Wan-Teh

---

From: Watson Ladd <[email-masked]>
Date: Mon, 11 Nov 2013 10:28:24 -0800

> suite list to prevent the Windows Server 2003 from selecting 3DES.
What is so bad about 3DES? Last I checked it was stronger than RC4.
The misimplementation is a bigger problem.
>>     51:RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
This reordering enables DES with 56 bit keys. Yes it is at the bottom,
but it should never be allowed to happen.
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: [email-masked] (Martin Rex)
Date: Mon, 11 Nov 2013 19:47:48 +0100 (CET)

> too far down the list, just fails the handshake.

Is there any further information available of what exactly does not
work with Windows 2003 3DES-CBC cipher suite?

I see other TLS implementations interoperate just fine with 
Windows 2003 using the DES3-CBC-SHA TLS cipher suite.

I do have installed the AES cipher suites update for schannel
on my Windows 2003 machine, but there is no mentioning that
it would change (or fix a formerly broken) DES3-CBC-SHA behaviour.

  http://support.microsoft.com/kb/948963

-Martin

---

From: [email-masked] (Martin Rex)
Date: Mon, 11 Nov 2013 19:53:27 +0100 (CET)

>   http://support.microsoft.com/kb/948963

Well, that KB-Article talks about fixing interop problems between
Exchange & Sendmail/Postfix in the "More Information" section.
It doesn't mention 3DES anywhere, though.

-Martin

---

From: Wan-Teh Chang <[email-masked]>
Date: Mon, 11 Nov 2013 11:08:10 -0800

> The misimplementation is a bigger problem.

I was referring to the misimplementation of CBC padding that Viktor
Dukhovni mentioned.

Wan-Teh Chang

---

From: Dr Stephen Henson <[email-masked]>
Date: Mon, 11 Nov 2013 19:18:35 +0000

>   http://support.microsoft.com/kb/948963

That KB does seem a little bit confused...

"This update adds support for the following Advanced Encryption Standard (AES)
cipher suites in the Schannel.dll module for Windows Server 2003:

    TLS_RSA_WITH_AES_128_CBC_SHA AES128-SHA
    TLS_RSA_WITH_AES_256_CBC_SHA AES256-SHA

Note These cipher suites are based on the RC4 algorithm."

and later...

"For example, OpenSSL is used in Sendmail, Postfix, Firefox, and Thunderbird."

quite a few other strange statements follow too.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: [email-masked] (Martin Rex)
Date: Mon, 11 Nov 2013 20:39:00 +0100 (CET)

Martin Rex wrote:
> > > The Windows 2003 TLS stack
> > > ... sometimes chooses 3DES (for which it misimplements CBC padding)

I just installed a Web-Server certificate on another Windows2003 server
that doesn't have the AES ciphersuites Hotfix installed.

Seems to interop fine on the DES3-CBC-SHA (0x00, 0x0a) cipher suite.
(using my own client, openssl-1.0.1c and Firefox 25)

-Martin

---

From: Nico Williams <[email-masked]>
Date: Tue, 12 Nov 2013 15:06:24 -0600

>   http://support.microsoft.com/kb/948963

<http://support.microsoft.com/kb/948963>

Viktor and I conjecture that this is an example of an SSPI application that
doesn't handle variable padding cipher suites.  I.e., this is an example of
an SSPI app that would break (were it using GSS instead of TLS) if we add a
Kerberos enctype with variable padding.  Moreover, Microsoft could now
produce up some sample code demonstrating this so we know what to look for
when auditing apps, but anyways, if our conjecture is correct then MSFT
engineers are quite right to be uncomfortable about adding a variable
padding enctype.

For those of you not up on Kerberos, there is a proposal to add a new
"enctype" (cipher suite) with variable padding, and Microsoft engineers
have objected that this would break unspecified apps.  Since TLS, GSS,
NTLM, and SASL share roughly the same API in WIN32, the same API usage
pattern defect may well be at work in both, the Kerberos case and the TLS
case that Viktor noted in the note I forwarded to this list.  This may
constrain what new cipher suites are safe to use in Windows apps, but
because the negotiation is not dependent on a third party, it's mostly a
non-issue for TLS as long as there's a sufficiently strong ciphersuite with
desired properties and no variable padding for SSPI apps to pick.  For TLS
going forward this is a non-issue: all new ciphersuites will almost
certainly be stream ciphers or AEAD counter modes.

Forwarding this to KITTEN WG shortly.

Nico
--