RFR[10] 8186057: TLS interoperability testing between different Java versions (original) (raw)
Artem Smotrakov artem.smotrakov at oracle.com
Thu Sep 7 06:32:23 UTC 2017
- Previous message (by thread): RFR[10] 8186057: TLS interoperability testing between different Java versions
- Next message (by thread): RFR[10] 8186057: TLS interoperability testing between different Java versions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
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.
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) {
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: TLSRSAWITHAES128CBCSHA, TLSDHEDSSWITHAES128CBCSHA and TLSECDHEECDSAWITHAES128CBCSHA. 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
- Previous message (by thread): RFR[10] 8186057: TLS interoperability testing between different Java versions
- Next message (by thread): RFR[10] 8186057: TLS interoperability testing between different Java versions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]