RFR: 8280494: (D)TLS signature schemes

Bernd duke at openjdk.java.net
Fri Jan 28 01:19:12 UTC 2022


On Thu, 27 Jan 2022 22:06:21 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> This update is to support signature schemes customization for individual (D)TLS connection.  Please review the CSR as well:
> CSR: https://bugs.openjdk.java.net/browse/JDK-8280495
> RFE: https://bugs.openjdk.java.net/browse/JDK-8280494

I like the per-parameters configuration and we really should get it for more Systeme properties in the future. But I wonder if the additional allocations (some while doing handshakes?) can be avoided by doing more parsing/analysing in the parameter object already. It could even do the analysis of the system property at that time. Also the toggle semantic seems to be a bit different then you would expect, a extra flag to keep track of customized settings would probably fix that and avoid the array compares.

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 92:

> 90:     private int maximumPacketSize = 0;
> 91:     private String[] applicationProtocols = new String[0];
> 92:     private String[] signatureSchemes = new String[0];

There are some places in here which could use a local or global static EMPTY = new String[0]` value. That would be safe to share and reduces allocations (they surely escape).

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 745:

> 743:      * This method will make a copy of the {@code signatureSchemes} array.
> 744:      *
> 745:      * @param signatureSchemes an ordered array of signature scheme names,

Should it mention that unknown schemes are ignored and not trigger a exception?

src/java.base/share/classes/javax/net/ssl/SSLParameters.java line 763:

> 761: 
> 762:         String[] tempSchemes = signatureSchemes.clone();
> 763:         for (String scheme : tempSchemes) {

In addition to this loop we could also parse/decompose the strings. This would do the work only once (if the parameter is reused)

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 66:

> 64:     // The configured signature schemes for "signature_algorithms" and
> 65:     // "signature_algorithms_cert" extensions
> 66:     String[]                   signatureSchemes;

I would keep the typed list (get it from the parameters or system property cache).

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 262:

> 260:         }   // otherwise, use the default values
> 261: 
> 262:         String[] ss = params.getSignatureSchemes();

If we don’t use the cloning getter here (and use the pre-parsed list) it would be more efficient.

src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java line 410:

> 408: 
> 409:         // Reset the signature schemes, if it was configured with SSLParameters.
> 410:         if (Arrays.equals(signatureSchemes,

The duals here does not mean it was configure with parameters, it only means it is currently the same configuration as the parameters, but it still could be a different source?

src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 439:

> 437:                     (config.signatureSchemes == null ||
> 438:                         config.signatureSchemes.length == 0 ||
> 439:                         Arrays.asList(config.signatureSchemes)

Is that a allocation per handshake*availablesize?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7252



More information about the security-dev mailing list