A new proposal to add methods to HttpsURLConnection to access SSLSession

[Chris Hegarty]

> On 31 Oct 2018, at 20:03, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>> ...
> 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.

I have no issue with the addition of the new method to access the
SSLSession. Unfortunately, due to the evolutionary constraints of this
API, the `getSSLSession` method will likely need to be specified to
throw UOE. The actual JDK's HTTPS protocol handler implementation will
not throw UOE.

Clearly there is a desire for non-JDK HTTPS protocol handler
implementations to quickly determine the need to update their code and
override the default implementation of `getSSLSession` ( to do something
useful ), hence the request to deprecate the the existing individual
security parameter accessor methods.

I don't believe that deprecating these individual security parameter
accessors is a good idea for the following reasons:

1) Deprecated warnings are only issued at compile-time, so only HTTPS
   protocol handler implementations being recompiled may encounter the
   warnings. Existing binary artifacts will not.

2) More importantly. Forever more, developers wanting access to say,
   the peer principle or the server's certificate chain, will be
   encouraged to get them through an optional API ( rather than a
   non-optional API ). This increases the risk that the code will
   encounter an UOE. I don't think that this increased risk is justified
   by the desire to not-have-two-ways-to-do-the-same-thing. I would
   agree if this were a new API, but it is not.

HTTPS protocol handler implementations actively being maintained will
likely quickly get requests from their users to provide a better
implementation of this new method, as folk move towards TLS 1.3, etc.
Maybe such requests will be sufficient to help adoption, at which point
the deprecation of these methods could then be re-considered.

-Chris.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20181101/f3f7b547/attachment.htm>