Bug ID: JDK-8280495 (D)TLS signature schemes

JDK-8280495 : (D)TLS signature schemes

Type: CSR
Component: security-libs
Sub-Component: javax.net.ssl

Priority: P3
Status: Closed
Resolution: Approved
Fix Versions: 19

Submitted: 2022-01-22
Updated: 2022-11-14
Resolved: 2022-03-04

Related Reports

CSR :

Description

Summary
-------
Add new APIs to support signature schemes customization for individual (D)TLS connection.

Problem
-------
In a (D)TLS connection, the client and server may support different signature algorithms. (D)TLS specifications (see RFC 8446 and RFC 5246) define the procedure to negotiate the signature algorithms that could be used in digital signatures during the negotiation of (D)TLS connections.

JDK implemented the procedure and essential signature schemes, and applications could configure the JDK default signature schemes.  Rather than using the provider default signature schemes, applications may want to customize the signature schemes for individual connections, for fine control of the security properties.  There is no such APIs in Java SE.


Solution
--------
New Java SE public APIs will be defined to customize the signature schemes for individual connections.

Specification
-------------

1. Add a get method to access the signature schemes customization in the javax.net.ssl.SSLParameters class.

        +    /**
        +     * Returns a prioritized array of signature scheme names that can be used
        +     * over the SSL/TLS/DTLS protocols.
        +     * <p>
        +     * Note that the standard list of signature scheme names are defined in
        +     * the <a href=
        +     * "{@docRoot}/../specs/security/standard-names.html#signature-schemes">
        +     * Signature Schemes</a> section of the Java Security Standard Algorithm
        +     * Names Specification.  Providers may support signature schemes not
        +     * defined in this list or may not use the recommended name for a certain
        +     * signature scheme.
        +     * <p>
        +     * The set of signature schemes that will be used over the SSL/TLS/DTLS
        +     * connections is determined by the returned array of this method and the
        +     * underlying provider-specific default signature schemes.
        +     * <p>
        +     * If the returned array is {@code null}, then the underlying
        +     * provider-specific default signature schemes will be used over the
        +     * SSL/TLS/DTLS connections.
        +     * <p>
        +     * If the returned array is empty (zero-length), then the signature scheme
        +     * negotiation mechanism is turned off for SSL/TLS/DTLS protocols, and
        +     * the connections may not be able to be established if the negotiation
        +     * mechanism is required by a certain SSL/TLS/DTLS protocol.  This
        +     * parameter will override the underlying provider-specific default
        +     * signature schemes.
        +     * <p>
        +     * If the returned array is not {@code null} or empty (zero-length),
        +     * then the signature schemes in the returned array will be used over
        +     * the SSL/TLS/DTLS connections.  This parameter will override the
        +     * underlying provider-specific default signature schemes.
        +     * <p>
        +     * This method returns the most recent value passed to
        +     * {@link #setSignatureSchemes} if that method has been called and
        +     * otherwise returns the default signature schemes for connection
        +     * populated objects, or {@code null} for pre-populated objects.
        +     *
        +     * @apiNote
        +     * Note that a provider may not have been updated to support this method
        +     * and in that case may return {@code null} instead of the default
        +     * signature schemes for connection populated objects.
        +     *
        +     * @implNote
        +     * The SunJSSE provider supports this method.
        +     *
        +     * @implNote
        +     * Note that applications may use the
        +     * {@systemProperty jdk.tls.client.SignatureSchemes} and/or
        +     * {@systemProperty jdk.tls.server.SignatureSchemes} system properties
        +     * with the SunJSSE provider to override the provider-specific default
        +     * signature schemes.
        +     *
        +     * @return an array of signature scheme {@code Strings} or {@code null} if
        +     *         none have been set.  For non-null returns, this method will
        +     *         return a new array each time it is invoked.  The array is
        +     *         ordered based on signature scheme preference, with the first
        +     *         entry being the most preferred.  Providers should ignore unknown
        +     *         signature scheme names while establishing the SSL/TLS/DTLS
        +     *         connections.
        +     * @see #setSignatureSchemes
        +     *
        +     * @since 19
        +     */
        +    public String[] getSignatureSchemes();

2. Add a set method to customize the signature schemes in the javax.net.ssl.SSLParameters class.

        +    /**
        +     * Sets the prioritized array of signature scheme names that
        +     * can be used over the SSL/TLS/DTLS protocols.
        +     * <p>
        +     * Note that the standard list of signature scheme names are defined in
        +     * the <a href=
        +     * "{@docRoot}/../specs/security/standard-names.html#signature-schemes">
        +     * Signature Schemes</a> section of the Java Security Standard Algorithm
        +     * Names Specification.  Providers may support signature schemes not
        +     *  defined in this list or may not use the recommended name for a certain
        +     * signature scheme.
        +     * <p>
        +     * The set of signature schemes that will be used over the SSL/TLS/DTLS
        +     * connections is determined by the input parameter {@code signatureSchemes}
        +     * array and the underlying provider-specific default signature schemes.
        +     * See {@link #getSignatureSchemes} for specific details on how the
        +     * parameters are used in SSL/TLS/DTLS connections.
        +     *
        +     * @apiNote
        +     * Note that a provider may not have been updated to support this method
        +     * and in that case may ignore the schemes that are set.
        +     *
        +     * @implNote
        +     * The SunJSSE provider supports this method.
        +     *
        +     * @param signatureSchemes an ordered array of signature scheme names with
        +     *        the first entry being the most preferred, or {@code null}.  This
        +     *        method will make a copy of this array.  Providers should ignore
        +     *        unknown signature scheme names while establishing the
        +     *        SSL/TLS/DTLS connections.
        +     * @throws IllegalArgumentException if any element in the
        +     *        {@code signatureSchemes} array is {@code null} or
        +     *        {@linkplain String#isBlank() blank}.
        +     *
        +     * @see #getSignatureSchemes
        +     *
        +     * @since 19
        +     */
        +    public void setSignatureSchemes(String[] signatureSchemes);

3. Added two new terms, connection populated and pre-populated objects, in the javax.net.ssl.SSLParameters class description.

             /**
              * Encapsulates parameters for an SSL/TLS/DTLS connection. The parameters
              * are the list of ciphersuites to be accepted in an SSL/TLS/DTLS handshake,
              * the list of protocols to be allowed, the endpoint identification
              * algorithm during SSL/TLS/DTLS handshaking, the Server Name Indication (SNI),
              * the maximum network packet size, the algorithm constraints, the signature
              * schemes and whether SSL/TLS/DTLS servers should request or require client
              * authentication, etc.
              * <p>
        -     * SSLParameters can be created via the constructors in this class.
        -     * Objects can also be obtained using the {@code getSSLParameters()}
        -     * methods in
        +     * {@code SSLParameter} objects can be created via the constructors in this
        +     * class, and can be described as pre-populated objects. {@code SSLParameter}
        +     * objects can also be obtained using the {@code getSSLParameters()} methods in
              * {@link SSLSocket#getSSLParameters SSLSocket} and
              * {@link SSLServerSocket#getSSLParameters SSLServerSocket} and
              * {@link SSLEngine#getSSLParameters SSLEngine} or the
              * {@link SSLContext#getDefaultSSLParameters getDefaultSSLParameters()} and
              * {@link SSLContext#getSupportedSSLParameters getSupportedSSLParameters()}
        -     * methods in {@code SSLContext}.
        +     * methods in {@code SSLContext}, and can be described as connection populated
        +     * objects.
              * <p>
              * SSLParameters can be applied to a connection via the methods
              * {@link SSLSocket#setSSLParameters SSLSocket.setSSLParameters()} and
              * {@link SSLServerSocket#setSSLParameters SSLServerSocket.setSSLParameters()}
              * and {@link SSLEngine#setSSLParameters SSLEngine.setSSLParameters()}.
              * ...snipped as the sections cannot be displayed properly in the CSR request...
              */
             public class SSLParameters {


4. Support the new added methods in the JDK Reference Implementation.

Comments

Adding new methods in this way is a bit atypical, but I'll defer to [~xuelei] and [~mullan]'s expertise that similar changes haven't been a problem in practice. I see a release note is already planned; moving to approved.
04-03-2022
[~xuelei], I'll take another pass over this request later in the week.
28-02-2022
Hi [~darcy], did my last two comments address your concerns? I would like to finalize this CSR if you have no further questions.
28-02-2022
@Joe Darcy > I assume that the user intent of calling setSignatureSchemes is something more than using affecting future result of calling getSignatureSchemes. If that is the case, then JoesOwnSSLParameters would mislead its users in terms of properly implementing the JDK 19 version of SSLParameters. If JoesOwnSSLParameters does not override the two new methods, the behavior is the same as SSLParameters as JoesOwnSSLParameters inherit from the SSLParameters implementation. If JoesOwnSSLParameters want to override the two new methods, it may need to follow the spec. But you are right if a JSSE provider do not support the two new method properly, the behavior could be misleading. The cases are covered by the apiNote spec in the s/get method. + * @apiNote + * Note that a provider may not have been updated to support this method + * and in that case may ignore the schemes that are set. + * @apiNote + * Note that a provider may not have been updated to support this method + * and in that case may return {@code null} instead of the default + * signature schemes for connection populated objects. Note the "provider" in the spec above means JSSE provider, not the subclasses of SSLParameters.
23-02-2022
@Joe Darcy, I think I had a better sense of you concerns. Your concern may come from the "usage of the signature schemes inside the (JoesOwn)SSLParameters". It is not the case, the signature schemes are not used by methods other than the s/getSignatureSchemes() methods. > Xuelei Fan, here is a hypothetical case. I've written JoesOwnSSLParameters class which overrides all the non-final methods of SSLParameters and otherwise implements the specification of SSLParameters. > > Now, with the implementations of the new methods in SSLParameters, will JoesOwnSSLParameters do the right thing? Sure, if setSignatureSchemes is called, getSignatureSchemes would return the right thing but any usage of the signatures schemes inside of JoesOwnSSLParameters would (I presume) not work as intended. I think we can divid the problem into two parts. One is about the SSLParameters and its subclasses, and the other one is about the JSSE provider implementation. For the 1st, we assume there is a subclass named JoesOwnSSLParameters, and for the 2nd case we assume there is a JSSE provider name XueleiJSSE. So we would need to consider two SSLParameters classes (SSLParameters and JoesOwnSSLParameters), and two providers (The SunJSSE provider in JDK, and XueleiJSSE). For the existing JoesOwnSSLParameters, which extends SSLParameters, it does not know the adding of setSignatureSchemes and getSignatureSchemes. So JoesOwnSSLParameters will not override the s/getSignatureSchemes() methods. Then the call to JoesOwnSSLParameters.s/getSignatureSchemes() will be directed to use the SSLParameters' implementation. It means the behaviors of JoesOwnSSLParameters.s/getSignatureSchemes() are exactly the same as SSLParameters.s/getSignatureSchemes(), as they use the same implementation. There may be still a chance of compatibility impact if other methods in SSLParameters use the result of s/getSignatureSchemes(). For example, if the SSLParameters.getApplicationProtocols() implementation uses signatures schemes in the SSLParameters implementation, but the JoesOwnSSLParameters does not use the signatures schemes in the overriden getApplicationProtocols(). But it is not the case the SSLParameters implementation for now. The SSLParameters is most like a container, and the parameters are independent from each other. It means that methods other than s/getSignatureSchemes(), including SSLParameters.s/getApplicationProtocols() do not use the signature schemes. So with the implementations of the new methods in SSLParameters, I think JoesOwnSSLParameters will continue work without modification. No impact on it is expected. So what about the providers, like SunJSSE provider and. XueleiJSSE. The SunJSSE provider will be updated to support signature algorithms with SSLParameters.s/getSignatureSchemes() method. The SunJSSE provider should be fine, we may not worry about it. What about the XueleiJSSE? The existing XueleiJSSE knows nothing about the SSLParameters.s/getSignatureSchemes() method, so it will not able to use these methods. In the setter spec, it is mentioned that: + * @apiNote + * Note that a provider may not have been updated to support this method + * and in that case may ignore the schemes that are set. and in the getter spec, it is mentioned that: + * @apiNote + * Note that a provider may not have been updated to support this method + * and in that case may return {@code null} instead of the default + * signature schemes for connection populated objects. If an application want to use the two methods, it may have to check if the underlying provider supports them or not. I think it may be sufficient with the apiNote above.
23-02-2022
[~xuelei], here is a hypothetical case. I've written JoesOwnSSLParameters class which overrides all the non-final methods of SSLParameters and otherwise implements the specification of SSLParameters. Now, with the implementations of the new methods in SSLParameters, will JoesOwnSSLParameters do the right thing? Sure, if setSignatureSchemes is called, getSignatureSchemes would return the right thing but any usage of the signatures schemes inside of JoesOwnSSLParameters would (I presume) not work as intended. This is likely an instance of the "fragile base class problem." I assume that the user intent of calling setSignatureSchemes is something more than using affecting future result of calling getSignatureSchemes. If that is the case, then JoesOwnSSLParameters would mislead its users in terms of properly implementing the JDK 19 version of SSLParameters. HTH
23-02-2022
> It may be acceptable for AbstractDelegatingSSLParameters and other subclasses of SSLParameters already in use to have to be updated to accommodate this change. Could I have more information about how the AbstractDelegatingSSLParameters or other subclasses could be impacted? I did not get the point. As far as I can see, for AbstractDelegatingSSLParameters, as it extends the SSLParameters, so it will work without needing any modification. In the SSLParameters class, there are implementation code added for the new s/getSignatureSchemes() methods. As AbstractDelegatingSSLParameters is extending SSLParameters, the new methods will be applied to AbstractDelegatingSSLParameters as well for JDK 19. It means, the application can call AbstractDelegatingSSLParameters.s/getSignatureSchemes(), and the implementation in SSLParameters will be used instead. If an application does not call the two methods, there is no impact obviously. Is there anything I missed?
23-02-2022
Marking the request as pended for compatibility concerns. It is not being considered to make the SSLParameters class as final at this point. It may be acceptable for AbstractDelegatingSSLParameters and other subclasses of SSLParameters already in use to have to be updated to accommodate this change. However, this is more than "minimal" compatibility impact and I'd prefer an approach where existing subclasses still "worked", even if "worked" meant that the new-in-19 functionality has to be opted into to be functional.
23-02-2022
> PS After a corpus search, several subclasses of SSLParameters were found including: > > https://github.com/wildfly-security/wildfly-elytron/blob/1.x/ssl/src/main/java/org/wildfly/security/ssl/AbstractDelegatingSSLParameters.java > > From a quick read, this kind of subclass would need to be updated to correctly work with the proposed changes to SSLParameters . For the Wildfly project, as the AbstractDelegatingSSLParameters.java is extending the SSLParameters, the new methods will be inherited from the SSLParameters implementation. So it should work on JDK 19 or later without any modification. It looks like that AbstractDelegatingSSLParameters.java is designed to work with multiple JDK releases. It should be fine as well to work with multiple releases, like JDK 17 or JDK 11, without modification. However, if Wildfly want to use the new feature in JDK 17, it may need to update the AbstractDelegatingSSLParameters.java, and add those new methods added in JDK 18 or later. So, generally I think the Wildfly should be fine to work with JDK and the JDK implementation of TLS protocols, even we added new methods in SSLParameters.
23-02-2022
> Joe Darcy has raised some concerns about derived SSLParameters classes in the field that may break given the current proposed changes. I added an implSpec section for this concerns. Meanwhile, Sean had a comment that the compatibility risk section of the CSR and the release notes should be sufficient to document this potential risks. So I removed the section later. I will update the compatibility risk section of the CSR. Joe Darcy made a good research and suggestions. Hopefully, his concerns could be addressed in the compatibility risk section and release notes. But please let me know if you want me add an implSpec in SSLParameters class.
23-02-2022
[~darcy] has raised some concerns about derived SSLParameters classes in the field that may break given the current proposed changes. Have these been evaluated and that's why things moved to the finalize state? Or do we need to consider these derived SSLParameters implementations still?
23-02-2022
I would like finalize this proposal. Please moving back to Provisional if there is further comment or concerns that I missed to address.
23-02-2022
PS After a corpus search, several subclasses of SSLParameters were found including: https://github.com/wildfly-security/wildfly-elytron/blob/1.x/ssl/src/main/java/org/wildfly/security/ssl/AbstractDelegatingSSLParameters.java From a quick read, this kind of subclass would need to be updated to correctly work with the proposed changes to SSLParameters .
23-02-2022
> So if I'm reading the draft correctly, in this case the implSpec for the current implementation would be something like: > > This implementation returns the most recent value passed to setSignatureSchemes if that method has been called and otherwise returns ... It's a good point to me. I would like to have an update in the getSignatureSchemes() method, like: * <p> - * If the {@link #setSignatureSchemes} method has not been called, this - * method should return the default signature schemes for connection - * populated objects, or {@code null} for pre-populated objects. + * This method returns the most recent value passed to + * {@link #setSignatureSchemes} if that method has been called and + * otherwise returns the default signature schemes for connection + * populated objects, or {@code null} for pre-populated objects. - * - * @implSpec - * This method was introduced since JDK 19, and could be unintentionally - * overridden by the existence of subclass {@link SSLParameters}. It is - * recommended that if possible, the subclass overriding implementation - * should be checked to comply to this method specification. - *
17-02-2022
> How would setSignatureSchemes "work" is a subclass has not been updated to support this method? It is not expected to subclass SSLParameters. But if an application does subclass SSLParameters, and then the super implementation in the SSLParameters code will be used, unless it has already defined a method with the same method name. As the setSignatureSchemes() method has an implementation in the SSLParameters class, it is not expected to have an impact if the subclass does not support this method. It is also not recommended, and not necessary, to override SSLParameters methods. It may be difficult to add final modifier to the SSLParameters, but what do you think if we add the final modifier to new methods in SSLParameters (for example, make the s/getSignatureSchemes methods final)?
17-02-2022
[~darcy] Could you clarify what you mean by self-use? All the implementation of this method does is return a clone of the array holding the signature scheme Strings which is already specified in the @return tag. And Xuelei noted that it is not typical for this class to be subclassed. In response to your feedback, Xuelei added the following text: ``` + * @implSpec + * This method was introduced since JDK 19, and could be unintentionally + * overridden by the existence of subclass {@link SSLParameters}. It is + * recommended that if possible, the subclass overriding implementation + * should be checked to comply to this method specification. ``` but I am not sure if that is what you meant. I think the compatibility risk section of the CSR and the release notes should be sufficient to document this potential risk, which occurs every time we want to add a new method to a non-final class.
17-02-2022
For this API, the SSLParameters is used directly, so the first suggestion does not work. The second suggestion is nice, but I think it only works if there is a stronger link between this class and the provider. In this case however, the main issue is that existing JSSE providers may not have been updated to call the new methods from their implementation classes. We can't make their code call the new methods and there currently is no practical way to know whether a provider supports the new methods from this class. This is just a container class, it doesn't have any information about what provider is being used with it, or will be used. (The provider may not even have been selected yet). This unfortunately means the application needs to simply know if the methods are supported by the provider it is using, which is why we added the following @implNote: ``` + * @implNote + * The SunJSSE provider supports this method. ``` If an application calls the `setSignatureSchemes` method and the provider doesn't support them, then there may be unexpected behavior, as the signature schemes would be ignored and the provider would use its own defaults. This is certainly not ideal, but in practice this has not been a serious issue when we have previously added other new methods to the `SSLParameters` API such as `setApplicationProtocols`, `setAlgorithmConstraints`, and a few others.
17-02-2022
PS If the SSLParameters is not used directly, it is fairly straightforward to add new methods in a mostly-compatible way if the new method do something like throw UnsupportedOperaitonException or call other methods on the class. Then the actual subclasses can provide the functionality in question. If that is not the case, you could do a hack like add a third method "isNewStuffSupported()" whose base behavior was testing if this.getClass() == SSLParameters and then have getSignatureSchemes query isNewStuffSupported and act accordingly. Subclasses would not be opt-into the new functionality by overriding isNewStuffSupported. HTH
17-02-2022
[~mullan], sure. To use an analogy to adding a default method to an interface, which has similarities to this situation, the implSpec tag on the new convenienceMethod will often be something like @implSpec The default implementation is equivalent to call " if (foo) {bar(); } else {quux();} " where bar() and quux() are existing methods on the interface. For the collection classes, "Effective Java" discusses documenting which overridable methods one method implementation might call so that subclasses can operate correctly. For example, AbstractCollection.addAll is defined in terms of calls to AbstractCollection.add. So if I'm reading the draft correctly, in this case the implSpec for the current implementation would be something like: This implementation returns the most recent value passed to setSignatureSchemes if that method has been called and otherwise returns ... How would setSignatureSchemes "work" is a subclass has not been updated to support this method?
16-02-2022
> SSLParameters is subclassable and a new getSignatureSchemes method is added. Can this get a @implSpec tag to describe the self-use of the new method for subclasses? In other words, could there be correctness issues for subclasses given the existence of the new method? Good point! I think the SSLParameters should have been declared as final class. Now it is a real problem if any sub-classes has already used the same method names. I will add a @implSpec for the cases. Did you have any ideas about how to make an improvement so that we don't worry about new adding methods in the future? I know if would be hard to make the SSLParameters as a final class now. Is it helpful to declare the s/getSignatureSchemes methods as final? Or could a class description added to discourage extending of this class? > For adding setSignatureSchemes, a more conventional approach to adding a method like this would be to have a "default" method that throws UnsupportedOperationException. Is that impractical here is many of the SSLParameters objects are of that exact class? The SSLParameters is not expected to be extended, and thus the JDK does not have an internal sub-class of SSLParameters. If the UnsupportedOperationException is used, it is required to extend SSLParameters and override the method. It is not the case in the current implementation of the parameters.
16-02-2022
Taking another look, SSLParameters is subclassable and a new getSignatureSchemes method is added. Can this get a @implSpec tag to describe the self-use of the new method for subclasses? In other words, could there be correctness issues for subclasses given the existence of the new method? For adding setSignatureSchemes, a more conventional approach to adding a method like this would be to have a "default" method that throws UnsupportedOperationException. Is that impractical here is many of the SSLParameters objects are of that exact class? Moving back to Provisional, not Approved.
16-02-2022
> For getSignatureSchemes, has returning an empty array rather than null considered? Yes, the original version is to use empty array. But after discussing, Sean, Brad and I thought it may be better to keep the spec consistent with the existing methods, which is more friendly for current developers. Besides that, if null is allowed, we could also use empty array for other purpose, to disable this feature for TLS 1.0 and 1.1. Thank you for the insights about frozen arrays and arrays-vs-lists.
04-02-2022
Moving to Provisional. For getSignatureSchemes, has returning an empty array rather than null considered? I don't think frozen arrays will arrive in the JDK any time soon. Valhalla should lower the overhead of wrapper around other values. Assuming the conceptual lists of signatures aren't that long, I don't think any efficiency arguments of arrays vs lists would be that compelling, leaving ease a programming a larger concern, IMO.
04-02-2022
> In looking at SSLParameters, it looks like we have some multi-valued parameters that use arrays and others that use Collections of various flavors. I wonder if there are any advantages/conveniences for both the caller and possibly JSSE internals to using List rather than String[] since there is a fairly rich API for List objects. I don't have strong feelings either way on this, I just thought it might be worth considering if you haven't already. It was a question to me as well when I designed the APIs. String array is more compact and easier to use, while List could be more efficient. I finally choose to use String array because of the effort of frozen arrays (See JDK-8261007). It may be possible to have more efficient array operations in the future. > Also I think it would be worth mentioning the jdk.tls.[client\|server].SignatureSchemes System properties, and indicate explicitly in the CSR how use of SSLParameters.setSignatureSchemes() interacts with the existing properties. It is implied that setSignatureSchemes would override the SignatureSchemes properties for any SSLSocket/SSLEngine that applies an SSLParameters object after having run the setSignatureSchemes() method. Good point! I will add a section. > Question: if a JVM is started with the SignatureSchemes properties set and then an SSLContext is initialized, will SSLSockets or SSLEngines built from that context object return the collection of SignatureScheme values as set through the property when [SOCKET\|ENGINE].getSSLParameters().getSignatureSchemes() is called? Or will it return an empty array? Same question with respect to SSLContext.getDefaultSSLParameters(). The System Properties set the default signature schemes. SSLContext.getDefaultSSLParameters() should return the default signature schemes, and the same for sslSocket.getSSLParameters() if the sslSocket parameters are not customized yet. Thanks!
28-01-2022
In looking at SSLParameters, it looks like we have some multi-valued parameters that use arrays and others that use Collections of various flavors. I wonder if there are any advantages/conveniences for both the caller and possibly JSSE internals to using List<String> rather than String[] since there is a fairly rich API for List objects. I don't have strong feelings either way on this, I just thought it might be worth considering if you haven't already. Also I think it would be worth mentioning the jdk.tls.[client\|server].SignatureSchemes System properties, and indicate explicitly in the CSR how use of SSLParameters.setSignatureSchemes() interacts with the existing properties. It is implied that setSignatureSchemes would override the SignatureSchemes properties for any SSLSocket/SSLEngine that applies an SSLParameters object after having run the setSignatureSchemes() method. Question: if a JVM is started with the SignatureSchemes properties set and then an SSLContext is initialized, will SSLSockets or SSLEngines built from that context object return the collection of SignatureScheme values as set through the property when [SOCKET\|ENGINE].getSSLParameters().getSignatureSchemes() is called? Or will it return an empty array? Same question with respect to SSLContext.getDefaultSSLParameters().
27-01-2022