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

[rahul.r.yadav at oracle.com]

The current fix does not affect the scenarios discussed earlier(that is 
a broader discussion,may be a different bug/enhancement).
The scenarios would be vaild even if the fix would not have been in place.

-Rahul

On 27/03/2020 17:50, Chris Hegarty wrote:
> 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 
>> <mailto: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 
>>>> <mailto: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.org/pipermail/security-dev/attachments/20200330/1b6794a2/attachment.htm>