> From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm > Sent: Tuesday, 13 September, 2011 07:33
> On 9/13/2011 1:46 AM, Dave Thompson wrote: > >> From: owner-openssl-us...@openssl.org On Behalf Of Jakob Bohm > >> Sent: Monday, 12 September, 2011 03:52 > >> On 9/9/2011 10:13 PM, krishnamurthy santhanam wrote: > > <snip: unclear about key transport or maybe derivation> > >> 1. On the side running openssl, ... > >> If you insist on at least 256 bit AES, set options ... > >> > >> 2. On the side running Java, ... > >> If you insist on at least 256 bit AES, set options ... > > It is enough to require 'strong' cipher on one of server > > or client, whichever is more convenient. > NOT True. If there is an active attack, the attacker could assume > the role of the only end that checks, and then use a very weak > ciphersuite to falsely "authenticate" itself to the end that does > not check if the authentication part of the SSL exchange was strong. > So for a fully secure system design both ends need to reject > ciphersuites too weak for the decided security policy. > The data cipher e.g. AES has no effect on authentication. Demanding AES256 (or otherwise strong) against an impostor only ensures that your secret data is conveyed to one crook without (small) risk of exposure to a *second* crook;. Yes, if an SSL usage needs authentication you must enforce sufficiently good authentication. This means not just adequate crypto (RSA, DSA, ECDSA) but also good enough certificates, from a CA that actually *deserves* trust. The latter is often the harder problem. Plus you *should* check revocation, but OpenSSL doesn't help much here and Java (out of the box) doesn't do it at all. A good CA won't issue certs using (signed by) or for (subject key) inadequate crypto, so you shouldn't need to enforce it (although as a sanity check it doesn't hurt). > 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. > 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. > > 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. > 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. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
