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.
> 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.
> 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
