On 9/15/2011 5:21 AM, Dave Thompson wrote:
In the past, this fact has caused common SSL clients (browsers etc.)
to regularly turn off older ciphersuites to protect against false
servers that deliberately downgrade to weak protocol versions and
ciphersuites, whenever such an attack became too easy for typical
criminals. For high security systems, it may be prudent or even
required to do this for protocol versions and ciphersuites that
look weak or old bye modern standards even if they are not
officially broken yet.
v2 had downgrade risks. And of course with the passage of time
algorithms fixed at too few bits (like 1DES) must be dropped.
v3 doesn't have newer features one might want, but I don't
know of any actual vulnerabilities given that a minimum part
of renegotiation-sequence (the fake suite) was jammed in.
Yes, but does every implementation in the wild include that workaround?
And do note that I define this as a check of the SSL/TLS
"ciphersuite", not of individual algorithms. Individual algorithm
strengths and key lengths may still need to be checked for the
certificates presented (do they use 300 bit RSA where 3000 is
required by policy) and for any aspect of an allowed the SSL/TLS
ciphersuite that may use different key strengths under the same
enum value.
The data cipher keysize, and MAC hash, are encoded in the suite.
The public-key size(s) used by authentication and keyexchange
are (mostly) not. As above, if a CA issues certs with/for keys
that are shorter than policy, I wouldn't trust them AT ALL.
Nor if their policy actually allows too-short keys.
The key word here is "mostly". A few old ciphersuites, and possibly
some future ones use suite selected algorithms for key exchange and
only use the certificates for authentication.
Additionally, the key derivation that actually produces the key for the
strong cipher is partially chosen by the suite and SSL/TLS version.
There is not much point in using a 256 bit AES key created by a 40
bit algorithm (to exagerate, I think the worst ones are old 128 bit
hash functions).
Hence the need to check the full cipher suite ID against requirements,
not just one component of the suite.
On Java to use AES 256 at all (optional or required)
you must install the JCE 'unlimited' policy from the
Sun-now-Oracle website. At least on the Suncle JVM;
other JVMs may work differently. This may apply to
other 'high' suites also; I haven't checked all.
Are you sure this still applies to Java 6 or Java 7 ?
Definitely 6 through 6u27; I doubt they'll change now.
We aren't using 7 yet, but the javase download page has
a 'JCE unlimited 7' download, separate from the one for 6,
and I doubt they would do that if it wasn't needed.
OK, I'll take your word for it.
If it is, that installation procedure is pretty tricky manual work,
as Sun never got around to automating the task for users.
It's no problem for me, because the systems I work on need
several changes to vanilla JRE and this is among the easier.
But for ordinary users, especially if you are deploying to
large populations (maybe all employees of a business)
I agree it would be a pain. I might settle for AES128 and
require rekeying (either renegotiation, or disconnect and
full reconnect) every 24 hours or 1TB or somesuch.
I was thinking of difficulty for the OP, not you.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
