[RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

Chris Hegarty chris.hegarty at oracle.com
Wed Sep 13 20:06:55 UTC 2017


Xuelei,

Without diving deeper into this issue, Rob’s suggested approach seems reasonable to me, and better than existing out-of-the-box behaviour. I’m not sure what issues you are thinking of, with using the read timeout in combination with a retry mechanism, in this manner? If the network is so slow, surely there will be other issues with connecting and reading, why is closing any different.

-Chris.

> On 13 Sep 2017, at 16:52, Rob McKenna <rob.mckenna at oracle.com> wrote:
> 
> Hi Xuelei,
> 
> This behaviour is already exposed via the autoclose boolean in:
> 
> https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocketFactory.html#createSocket-java.net.Socket-java.io.InputStream-boolean-
> 
> My position would be that allowing 5 retries allows us to say with some
> confidence that we're not going to get a close_notify from the server.
> If this is the case I think its reasonable to close the connection.
> 
> W.r.t. a separate timeout, the underlying mechanics of a close already
> depend on the readTimeout in this situation. (waiting on a close_notify
> requires performing a read so the read timeout makes sense in this
> context) I'm happy to alter that but I think that the combination of
> a timeout and a retry count is straightforward and lower impact.
> 
> In my opinion the default behaviour of potentially hanging indefinitely
> is worse than the alternative here. (bearing in mind that we are closing
> the underlying socket)
> 
> I'll file a CSR as soon as we settle on the direction this fix will
> take.
> 
>    -Rob
> 
> On 13/09/17 05:52, Xuelei Fan wrote:
>> In theory, there are intermittent compatibility problems as this update may
>> not close the SSL connection over the existing socket layer gracefully, even
>> for high speed networking environments, while the underlying socket is
>> alive.  The impact could be serious in some environment.
>> 
>> For safe, I may suggest turn this countermeasure off by default.  And
>> providing options to turn on this countermeasure:
>> 1. Close the SSL connection gracefully by default; or
>> 2. Close the SSL connection after a timeout.
>> 
>> It's hardly to say 5 times receiving timeout is better/safer than timeout
>> once in this context.  As you have already had a system property to control,
>> you may be able to use options other than the customized socket receiving
>> timeout, so that the closing timeout is not mixed/confused/dependent on/with
>> the receiving timeout.
>> 
>> Put all together:
>> 1. define a closing timeout, for example "jdk.tls.waitForClose".
>> 2. the property default value is zero, no behavior changes.
>> 3. applications can set positive milliseconds value for the property. The
>> SSL connection will be closed in the set milliseconds (or about the maximum
>> value between SO_TIMEOUT and closing timeout), the connection is not grant
>> to be gracefully.
>> 
>> What do you think?
>> 
>> BTW, please file a CSR as this update is introducing an external system
>> property.
>> 
>> Thanks,
>> Xuelei
>> 
>> On 9/11/2017 3:29 PM, Rob McKenna wrote:
>>> Hi folks,
>>> 
>>> In high latency environments a client SSLSocket with autoClose set to false
>>> can hang indefinitely if it does not correctly recieve a close_notify
>>> from the server.
>>> 
>>> In order to rectify this situation I would like to suggest that we
>>> implement an integer JDK property (jdk.tls.closeRetries) which instructs
>>> waitForClose to attempt the close no more times than the value of the
>>> property. I would also suggest that 5 is a reasonable default.
>>> 
>>> Note: each attempt times out based on the value of
>>> Socket.setSoTimeout(int timeout).
>>> 
>>> Also, the behaviour here is similar to that of waitForClose() when
>>> autoClose is set to true, less the retries.
>>> 
>>> http://cr.openjdk.java.net/~robm/8184328/webrev.01/
>>> 
>>>    -Rob
>>> 




More information about the security-dev mailing list