SSLSocketImpl improperly wraps SocketException in SSLProtocolException

[Xuelei Fan]

Hi,

Thanks for reporting the issue.  Did you have the thread stacks of the unexpected exception?  

Please file a bug.  I’d appreciate it if there is a reproducible test code.

Thanks,
Xue-Lei

> On Nov 21, 2018, at 10:31 AM, Oleg Golberg <ogolberg at toasttab.com> wrote:
> 
> Hello,
> 
> I'd like to report a potential SSLSocketImpl bug in OpenJDK-11.
> 
> It appears that the TLS1.3-related work in OpenJDK-11 changed
> SSLSocketImpl.handleException to wrap underlying SocketExceptions in
> SSLProtocolExceptions.
> 
> Specifically, before TLS1.3 changes, handleException simply rethrows
> IOExceptions (here:
> https://github.com/unofficial-openjdk/openjdk/blob/322f09b333edd0d26594c52fab7a5346f7b40578/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java#L1895).
> After TLS1.3 changes, handleException pipes a SocketException into
> .fatal(..) and then into Alert.UNEXPECTED_MESSAGE.createSslException which
> ultimately wraps the cause in an SSLProtocolException.
> 
> First, this contradicts the SSLProtocolException javadoc which says that an
> SSLProtocolException "Reports an error in the operation of the SSL
> protocol. Normally this indicates a flaw in one of the protocol
> implementations."
> 
> Additionally, there's existing, widely used code that relies on
> SocketExceptions being rethrown here. A good example is Apache HttpClient
> whose default retry logic excludes all SSLExceptions from being retried
> (see
> https://hc.apache.org/httpcomponents-client-ga/httpclient/xref/org/apache/http/impl/client/DefaultHttpRequestRetryHandler.html#L104
> ).
> 
> Thanks,
> 
> - Oleg