Aftermath of TLS 1.3 in Java 11 with wrapped IOExceptions

[Xuelei Fan]

Hi,

Could someone please help to verify if the attached patch (JDK 14) works 
HttpComponents?

Thanks & Regards,
Xuelei

On 12/1/2019 5:37 AM, Michael Osipov wrote:
> Hi folks,
> 
> I am one of the Apache HttpComponents committers and we get these nags
> once in a while:
> 
> -
> https://github.com/apache/httpcomponents-client/pull/178#discussion_r351492056 
> 
> - https://issues.apache.org/jira/browse/HTTPCLIENT-2032
> - https://stackoverflow.com/q/56306216/696632
> 
> It all boils down to that IOExceptions are not thrown as-is after the
> introduction of TLS 1.3 in Java 11, but now wrapped in SSLExceptions
> (partially fixed by JDK-8214339). This is counterproductive.
> 
> Questions:
> 
> * Why has this change been made?
> * Why has the incompatible change not properly communicated to the
> users/community?
> * Can this be restored back to Java 8 behavior for 15 (14 not likely?!)
> and 11u?
> 
> Looking into [1] the following requirements have been broken:
>>   - Verify that the implementation does not break backward 
>> compatibility in unexpected ways.
>>   - Verify that the implementation does not introduce any unexpected 
>> interoperability issues.
> 
> @Rory, can you engage also with Apache HttpComponents? We are not happy
> with the situation.
> I see your mails on other MLs like Maven and Tomcat where I commit too.
> 
> Regards,
> 
> Michael
> 
> [1] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8145252
-------------- next part --------------
diff -r 2baa1f8721b8 src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java
--- a/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java	Mon Dec 02 18:52:18 2019 +0100
+++ b/src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java	Mon Dec 02 10:32:32 2019 -0800
@@ -1254,8 +1254,11 @@
             } catch (SSLHandshakeException she) {
                 // may be record sequence number overflow
                 throw conContext.fatal(Alert.HANDSHAKE_FAILURE, she);
-            } catch (IOException e) {
+            } catch (SSLException ssle) {
                 throw conContext.fatal(Alert.UNEXPECTED_MESSAGE, e);
+            }   // re-throw other IOException, which should be caused by
+                // the underlying plain socket and could be handled by
+                // applications (for example, re-try the connection).
             }
 
             // Is the sequence number is nearly overflow, or has the key usage