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, [email protected] 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
