RFR[10] 8186057: TLS interoperability testing between different Java versions

[Artem Smotrakov]

Hi John,

Thanks for starting working on this. I believe this tool is going to be 
very helpful.

Let me skip some coding comments for a while, I have a couple of 
comments about the design. The main idea is that it should cover as many 
cases as it can. Even if it might look a bit redundant, I believe it is 
actually not redundant because we basically never know what's going to 
break down.

1. At the moment, you define cases in Compatibility.java

   59     private static final String[] CASE_TYPES = new String[] {
   60             Utils.CASE_HANDSHAKE,
   61             Utils.CASE_DATA_EXCHANGE,
   62             Utils.CASE_ALPN };

I believe there are much more many case which we can implement later. 
But this approach doesn't looks flexible. For example, let's consider 
that we'd like to use a couple of extensions in the same time. Let's say 
we'd like to use SNI and ALPN. It seems like we have to create a 
separate case for that, and add it manually to the array. Would it be 
possible to generate cases automatically? For example, you can define 
parameters of TLS connection, for example:
- handshake type: full, session-resumption
- use ALPN: true, false
- use SNI: true, false
- use client auth: true, false,
etc

Then you can build a Cartesian product of all parameters. Client and 
sever should take parameters, and say if they support all of the or not 
(for example, JDK 6 might not support all features that JDK 9 does). If 
it does, client and server can configure themselves with those 
parameters, and start handshaking.

2. With the approach above, it might be possible to avoid those nested 
loops:

   93       for (String caseType : CASE_TYPES) {
   94             for (String protocol : PROTOCOLS) {
   95                 for (String cipherSuite : CIPHER_SUITES) {
   96                     for (JdkInfo serverJdk : jdkInfos) {

3. I believe we should cover all supported cipher suites. Test run is 
going to take more time, but it think it's okay. Another option is to 
introduce two modes:
- light: run the test with a couple of cipher suites
- heavy: run the test with all supported cipher suites


A couple of comments about the code:
- What's the reason of using disabled SHA1 and RSA with 1024-bit keys? 
You might use stronger algorithms and key sizes, and avoid modifying 
java.security file
- Please use try-with-resources if possible (files, sockets, etc)

Artem

On 09/07/2017 08:52 AM, sha.jiang at oracle.com wrote:
> Hi,
> Please review this test for checking the interop compatibility on JSSE 
> among different JDK releases (from 6 to 10).
> It covers the cases, like handshake, data exchange, client 
> authentication and APLN, on all TLS versions (if possible).
> And the selected TLS cipher suites are: TLS_RSA_WITH_AES_128_CBC_SHA, 
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA and 
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA.
> For more details, please look though the README.
>
> Webrev: http://cr.openjdk.java.net/~jjiang/8186057/webrev.00
> Issue: https://bugs.openjdk.java.net/browse/JDK-8186057
>
> Best regards,
> John Jiang
>