A new proposal to add methods to HttpsURLConnection to access SSLSession

Xuelei Fan xuelei.fan at oracle.com
Wed Oct 31 20:03:05 UTC 2018


On 10/31/2018 8: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
>>
>> Thanks,
>> Xuelei
> 
> The new method looks fine.
> 
> On the deprecation, minimally the annotation should contain
> the "since" element, which will have a value of `12`.
> 
Hm, it looks better now if using the "since" element.  Thanks!

> Also, I wonder, now that I see the spec, whether or not it is
> actually a good idea to deprecate these methods. The reason
> I ask this is that the new method, getSSLSession, can throw
> UOE, which effectively makes it an optional method. Access
> to the specific security parameters provided by the existing
> methods is non-optional. This is a clear difference, and
> possibly a reason, for folk not interested in the "new"
> parameters, to continue to use the existing methods.
> 
Yes.  I had the same concern about the optional operation.  However, I 
came to a different conclusion if I'm from viewpoint of these users that 
need to use this new operation.

If an application have to use this new operation, for example to access 
the negotiated TLS version, this operation is essential to it. 
Unfortunately, because of compatibility impact, we cannot force all 
implementation supports this new added operation.  It is a potential 
problem to those applications that need it.

It would be nice if an implementation can support this operation as soon 
as possible.  If we just add the operation, providers may not aware 
there is a need to update their implementation.  Unfortunately. there is 
not much we can do to notify the provider.

If we deprecated the duplicated methods, it is easier for providers to 
catch up with this new added operation, and move forward to support it. 
As the deprecating will show up building warnings, or even error if run 
in strict building mode.

To make it more clear, I added a implNote in the getSSLSession() method, 
and recommend to support it in all implementations.

I prefer to deprecate these methods a little bit more, but not very 
strong.  If there is a strong preference, I can live with it.

BTW, I also updated the java.net.SecureCacheResponse accordingly.  I'm 
not sure if SecureCacheResponse is really used in practice.  I did not 
find the implementation of it in JDK.

Here is the webrev if you want to look at the implementation details:
     http://cr.openjdk.java.net/~xuelei/8212261/webrev.00/

Thanks,
Xuelei



More information about the security-dev mailing list