A new proposal to add methods to HttpsURLConnection to access SSLSession

Xuelei Fan xuelei.fan at oracle.com
Mon Nov 5 18:52:06 UTC 2018


Hi Chris and Sean,

There are a few feedback for the CSR approval.  I updated to use 
Optional<SSLSession> for the returned value.  For more details, please 
refer to:
   https://bugs.openjdk.java.net/browse/JDK-8213161
   http://cr.openjdk.java.net/~xuelei/8212261/webrev.03/


Please let me know if you are OK with this change.

Thanks,
Xuelei

On 11/2/2018 11:42 AM, Xuelei Fan wrote:
> Thanks for the review and suggestions, Chris and Sean.
> 
> I just finalized the CSR.
> 
> Thanks,
> Xuelei
> 
> On 11/2/2018 5:58 AM, Chris Hegarty wrote:
>> Thanks for the updates Xuelei, some minor comments inline..
>>
>>> On 1 Nov 2018, at 23:42, Xuelei Fan <xuelei.fan at oracle.com 
>>> <mailto:xuelei.fan at oracle.com>> wrote:
>>>
>>> On 11/1/2018 11:24 AM, Sean Mullan wrote:
>>>> On 10/31/18 11:52 AM, Chris Hegarty wrote:
>>>>> Xuelei,
>>>>>
>>>>> On 30/10/18 20:55, Xuelei Fan wrote:
>>>>>> Hi,
>>>>>>
>>>>>> For the current HttpsURLConnection, there is not much security 
>>>>>> parameters exposed in the public APIs.  An application may need 
>>>>>> richer information for the underlying TLS connections, for example 
>>>>>> the negotiated TLS protocol version.
>>>>>>
>>>>>> Please let me know if you have concerns to add a new method 
>>>>>> HttpsURLConnection.getSSLSession() and deprecate the duplicated 
>>>>>> methods, by the end of Nov. 2, 2018.
>>>>>>
>>>>>> Here is the proposal:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8213161
>>>> Are there any security issues associated with returning the 
>>>> SSLSession, since it is mutable?
>>> It should be fine.  The update APIs of the session (invalidating, 
>>> bind values) does not impact the connection.
>>
>> Alternatively, as is done in the new HTTP Client, an immutable
>> SSLSession instance can be returned.
>>
>>>> +     *           SHOULD override this method with appropriate 
>>>> implementation.
>>>> s/appropriate/an appropriate/
>>>> I would probably not capitalize "SHOULD" and just say "should". 
>>>> "SHOULD" is more common in RFCs. I don't see that much in javadocs.
>>>> +     * @implNote The JDK Reference Implementation supports this 
>>>> operation.
>>>> +     *           As an application may have to use this operation 
>>>> for more
>>>> +     *           security parameters, it is recommended to support 
>>>> this
>>>> +     *           operation in all implementations.
>>>> I think it should be obvious that the JDK implementation would 
>>>> override this method so not sure that first sentence is necessary. 
>>>> The other sentence seems like it could be combined with the previous 
>>>> sentence, ex:
>>>> "Subclasses should override this method with an appropriate 
>>>> implementation since an application may need to access additional 
>>>> parameters associated with the SSL session."
>>> Updated accordingly, in the CSR and webrev:
>>> https://bugs.openjdk.java.net/browse/JDK-8213161
>>
>> The CSR looks good. I made a few minor edits to the verbiage
>> and added myself as reviewer.
>>
>> The title will need to be updated to reflect the addition of the
>> new method in SecureCacheResponse. Maybe:
>>
>> "Add SSLSession accessors to HttpsURLConnection and
>> SecureCacheResponse"
>>
>> -Chris.
>>
>>
>>



More information about the security-dev mailing list