Subject: [kitten] Possible example where variable padding enctypes can break SSPI apps

From: Nico Williams <[email-masked]>
Date: Tue, 12 Nov 2013 16:07:30 -0600

See below.  Viktor and i conjecture that this is an example of an SSPI app
that breaks because of variable padding in 3DES-CBC TLS ciphersuites, and
that that applies to Kerberos SSPI apps as well.

---------- Forwarded message ----------
From: *Nico Williams*
Date: Thursday, November 7, 2013
Subject: Windows 2003 TLS 64 ciphersuite limit
To: [email-masked]

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] <javascript:;>>
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.