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....@oracle.com
<mailto:xuelei....@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....@oracle.com
<mailto:xuelei....@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.
