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>
The normal way to do this is:
1. On the side running openssl, just let openssl handle the
entire process,
including any AES (or other negotiated algorithm) encryption in both
directions with all the required precautions about key reuse etc.
If you insist on at least 256 bit AES, set options in openssl
parameters to
only accept ciphersuites with strong enough ciphers.
2. On the side running Java, just let the standard SSL
classes in Java (I
forgot their names, see the JDK docs) handle the entire
process in the same
way. If you insist on at least 256 bit AES, set options in
java SSL class
parameters to only accept ciphersuites with strong enough
ciphers, or if that
is not possible, check the ciphersuite chosen after handshake
and abort if
not strong enough for your purpose.
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.
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.
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.
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 ?
If it is, that installation procedure is pretty tricky manual work,
as Sun never got around to automating the task for users.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
