RFR JDK-8239595/JDK-8239594 : ssl context version is not respected/jdk.tls.client.protocols is not respected

[Chris Hegarty]

Thank you for these clarifications. We will now consider how these affect, if at all, the HTTP Client.

-Chris.

> On 27 Mar 2020, at 17:47, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> On 3/27/2020 10:36 AM, Chris Hegarty wrote:
>> Thank you Xuelei, this very helpful.
>> Sorry, but I am going to ask just a few more clarifying questions to make sure that we’re on the same page.
>>> On 27 Mar 2020, at 16:23, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>>> 
>>> On 3/27/2020 5:52 AM, Chris Hegarty wrote:
>>>> Xuelei,
>>>> Before commenting further on the interaction of the HTTP Client with various contorted configurations, I would like to get a better understanding of the `jdk.tls.client.protocols` property.
>>>> Is there a specification or other documentation describing `jdk.tls.client.protocols` ?
>>> See the jdk.tls.client.protocols line in table 'Table 8-3 System Properties and Customized Items" in JSSE Reference Guides:
>>> 
>>> "https://docs.oracle.com/en/java/javase/14/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-A41282C3-19A3-400A-A40F-86F4DA22ABA9
>>> 
>>> For your quick reference, I copied the note here:
>>> 
>>> ---------------
>>> Customized Item:
>>> Default handshaking protocols for TLS/DTLS clients.
>>> 
>>> Notes:
>>> To enable specific SunJSSE protocols on the client, specify them in a comma-separated list within quotation marks; all other supported protocols are not enabled on the client
>> “supported” here means protocols that are supported by the provider, and may be used within a specific context. This translates, for the default SSLContext, to the API call getSupportedSSLParameters().getProtocols(), right?
> Yes.
> 
>> getSupportedSSLParameters().getProtocols() returns a superset of getDefaultSSLParameters().getProtocols(). Conversely, getDefaultSSLParameters().getProtocols() is a strict subset of getSupportedSSLParameters().getProtocols(), right?
> Yes.
> 
>> The `jdk.tls.client.protocols` property has no affect on getSupportedSSLParameters().getProtocols()  only getDefaultSSLParameters().getProtocols(), right?
> Yes.
> 
>> In which case, getDefaultSSLParameters().getProtocols() returns the value of  `jdk.tls.client.protocols`.
>>> For example,
>>> 
>>>    If jdk.tls.client.protocols="TLSv1,TLSv1.1", then the default protocol settings on the client for TLSv1 and TLSv1.1 are enabled, while SSLv3, TLSv1.2, TLSv1.3, and SSLv2Hello are not enabled
>>> 
>>>    If jdk.tls.client.protocols="DTLSv1.2" , then the protocol setting on the client for DTLS1.2 is enabled, while DTLS1.0 is not enabled
>>> ---------------
>> Seems that the term “client” here is referring to client-initiated exchanges, rather than any specific technology.
>> The assumption, which is reasonable, is that “clients” will use the default context. Again, this is reasonable default out-of-the-box behavior.
> The client refer to the client side SSLSocket or SSLEngine created with the default SSLContext.  or example:
>    SSLContext sslContext = SSLContext.getInstance("TLS");
>    SSLEngine sslEngine = sslContext.createSSLEngine();
>    sslEngine.setUseClientMode(true);
> 
> The sslEngine object is a client that impacted by the property.
> 
> While if
>    sslEngine.setUseClientMode(false);
> 
> then the object should not be impacted by the property.
> 
> Xuelei
> 
>>>> It is my understanding that the property only affects the *default* protocol’s ( not the supported protocols ) of the *default* context. That is, the context returned by `SSLContext.getInstance("Default”)`,
>>> It is correct that the property impact the default SSLContext only.  The default SSLContext instance could get from:
>>>    SSLContext.getInstance("Default");
>>>    SSLContext.getInstance("TLS");
>>>    SSLContext.getInstance("DTLS”);
>> Thanks for this clarification.
>>> 
>>>> and the protocol values returned by the following invocation on that context `getDefaultSSLParameters().getProtocols()`. Is this correct? If not, what does it do?
>>> Yes.
>> Thanks,
>> -Chris.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200327/90f899f0/attachment-0001.htm>