Mark, On 7/10/14, 11:01 AM, Mark Thomas wrote: > On 10/07/2014 14:27, Christopher Schultz wrote: >> Mark, >> >> On 7/9/14, 12:46 PM, Mark Thomas wrote: >>> On a related topic, it would be extremely useful if the >>> available ciphers were exposed through the native interface. >>> Anyone with C skills fancy taking a look? >>> >>> My main motivation for this is that we can write a unit test >>> that checks the mapping of OpenSSL ciphers to JSSE ciphers and >>> highlights (by a failure) when the mapping changes (e.g. one of >>> them adds support for a new cipher). >> >> So you want to: >> >> 1. Take a cipher suite string and run it through Rémy's JSSE code >> 2. Take the same cipher suite string and run it through OpenSSL 3. >> Compare the two resulting cipher suite lists to ensure they are the >> same (barring absent ciphers in each implementation) >> >> ? > > Not what I had in mind but that would be useful too. > > What I wanted to do was: > - get the list of ciphers from OpenSSL > - check that each entry was either mapped to a JSSE cipher or in a > list of known unmappable ciphers > - check that every JSSE entry we expected to be mapped as was mapped > > To put it another way, I want a unit test that fails if JSSE or > OpenSSL add or remove a cipher and/or the mapping from JSSE to OpenSSL > changes so we can investigate.
Okay, that sounds like what I was trying to express above, regardless of
the exact method of doing so.
>> While step 2 could be done via JNI, it could also be done like
>> this:
>>
>> System.exec("openssl ciphers <cipher suites>");
>>
>> Since OpenSSL and JSSE support different sets of ciphers out of the
>> box, does that mean that we'll have to maintain a complicated set
>> of allowed inconsistencies based upon the combination of JVM and
>> OpenSSL version?
>
> Nope. Just the mapping from latest OpenSSL to latest version of Java
> that that version of Tomcat builds with.
Okay.
>> For example, OpenSSL prior to 1.0.something do not have ECDHE
>> ciphers, and at some point they became available in JSSE. Unless
>> you have matching versions of both, you'll get a failure. I think
>> it would be fairly chaotic.
>
> Which is why you work with the latest of each rather than trying to
> track all possible combinations.
That seems reasonable.
Any reason not to use "openssl ciphers" rather than building a JNI
interface to the OpenSSL call? In order to get that list, you actually
have to build an SSL context, then an "SSL" object in C and set it all
up properly to get the list. To do it accurately, I think you might
have to initialize tcnative with a certificate and all that jazz. The
"ciphers" tool that OpenSSL ships already does all that stuff with dummy
certs and/or ones that you configure somewhere (I don't feel like
tracking-down all the code that loads those defaults, etc. because the
OpenSSL code is so horrible).
-chris
signature.asc
Description: OpenPGP digital signature
