Issue when connecting to TLSv1 server

Tue Feb 9 16:18:41 UTC 2016

Hi Brad,

I've just uploaded my recreate which I ran and I gathered -Djavax.net.debug=ssl,handshake traces for both, OpenJDK9 and OpenJDK8, once with -Djdk.tls.client.protocols=TLSv1 and once without.

So, for OpenJDK8 with -Djdk.tls.client.protocols=TLSv1, I get the Response Code 403.
If I don't restrict "jdk.tls.client.protocols", I'll see this java.net.SocketException: Unrecognized Windows Sockets error: 0: recv failed
For JDK9 I get javax.net.ssl.SSLException: java.nio.BufferOverflowException in either case.

So, as you've mentioned in the bug - maybe the second handshake for client authentication (without creds) could be the cause which leads to shut down. However, when my customer is using credentials in his test (which he can't disclose obviously), we observer the same behavior. So, the question for me is to understand why with JDK8 and -Djdk.tls.client.protocols=TLSv1 there is a well behaving HTTPS communication going on (as it is with older JDKs, e.g. Java 7, Java 6 as well) but JDK8 and higher have issues. What is going different there?

I guess you can play around with that and look for the data that you are interested in.

And no discussion - the server is using outdated and insecure standards. But we don't have an influence on that.

Thanks
Christoph

-----Original Message-----
From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On Behalf Of Bradford Wetmore
Sent: Montag, 8. Februar 2016 20:13
To: Xuelei Fan <xuelei.fan at oracle.com>; security-dev at openjdk.java.net
Subject: Re: Issue when connecting to TLSv1 server

I looked at this last week and added a few more bits of info today.

Without the debug logs, it's hard to see what's going on.

Brad

On 2/5/2016 5:05 PM, Xuelei Fan wrote:
> Thanks for the report.  I filed a bug for further evaluation:
>
>     https://bugs.openjdk.java.net/browse/JDK-8149169
>
> Regards,
> Xuelei
>
> On 2/6/2016 7:18 AM, Langer, Christoph wrote:
>> Hi,
>>
>>
>>
>> while supporting an app development team, I'm facing a tough TLS issue -
>> maybe you experts have an idea.
>>
>>
>>
>> They try to open an HTTPS connection to the server URL
>> https://nfe-homologacao.sefazrs.rs.gov.br:443/ws/NfeAutorizacao/NFeAutorizacao.asmx.
>> This is a Web Service of some Brazilian financial authority. So, what
>> I'm basically doing is this:
>>
>>
>>
>> --code snippet--
>>
>> URL url = new
>> URL("https://nfe-homologacao.sefazrs.rs.gov.br:443/ws/NfeAutorizacao/NFeAutorizacao.asmx");
>>
>> HttpsURLConnection con = (HttpsURLConnection)url.openConnection();
>>
>> con.setHostnameVerifier(new DefaultHostnameVerifier());
>>
>>
>>
>> // optional default is GET
>>
>> con.setRequestMethod("GET");
>>
>>
>>
>> System.out.println("Sending 'GET' request to URL: " + url);
>>
>> int responseCode = con.getResponseCode();
>>
>> System.out.println("Response Code: " + responseCode);
>>
>> --end code snippet-
>>
>>
>>
>> I expect it to return "403 - not authorized".
>>
>>
>>
>> The coding will work with JDK7. However, with JDK8, I get this type of
>> exception:
>>
>>
>>
>> java.net.SocketException: Unrecognized Windows Sockets error: 0: recv failed
>>
>>          at java.net.SocketInputStream.socketRead0(Native Method)
>>
>>          at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
>>
>>          at java.net.SocketInputStream.read(SocketInputStream.java:170)
>>
>>          at java.net.SocketInputStream.read(SocketInputStream.java:141)
>>
>>          at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
>>
>>          at sun.security.ssl.InputRecord.read(InputRecord.java:503)
>>
>>          at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
>>
>>          at
>> sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:930)
>>
>>          at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)
>>
>>          at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
>>
>>          at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
>>
>>          at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
>>
>>          at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:704)
>>
>>          at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647)
>>
>>          at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:675)
>>
>>          at
>> sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1536)
>>
>>          at
>> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
>>
>>          at
>> java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
>>
>>          at
>> sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338)
>>
>>          ...
>>
>>
>>
>> I can get it to work in JDK8 by forcing it to TLSv1 only, e.g. by
>> setting property -Djdk.tls.client.protocols=TLSv1.
>>
>>
>>
>> For JDK9 I even get a different exception:
>>
>> javax.net.ssl.SSLException: java.nio.BufferOverflowException
>>
>>          at sun.security.ssl.Alerts.getSSLException(Alerts.java:214)
>>
>>          at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1948)
>>
>>          at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1900)
>>
>>          at
>> sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1883)
>>
>>          at
>> sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1809)
>>
>>          at sun.security.ssl.AppInputStream.read(AppInputStream.java:173)
>>
>>          at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
>>
>>          at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
>>
>>          at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
>>
>>          at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:704)
>>
>>          at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647)
>>
>>          at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:675)
>>
>>          at
>> sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1534)
>>
>>          at
>> sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1439)
>>
>>          at
>> java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
>>
>>          at
>> sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:319)
>>
>>          at
>> com.sap.cl.HttpsURLConnectionTest.sendGETRequest(HttpsURLConnectionTest.java:42)
>>
>>          at
>> com.sap.cl.HttpsURLConnectionTest.main(HttpsURLConnectionTest.java:63)
>>
>> Caused by: java.nio.BufferOverflowException
>>
>>          at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:206)
>>
>>          at
>> sun.security.ssl.SSLSocketInputRecord.decodeInputRecord(SSLSocketInputRecord.java:226)
>>
>>          at
>> sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:178)
>>
>>          at
>> sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1012)
>>
>>          at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:957)
>>
>>          at sun.security.ssl.AppInputStream.read(AppInputStream.java:159)
>>
>>          ... 12 more
>>
>>
>>
>> I've debugged a lot today and tried to get something out of the
>> javax.net.debug output but I didn't get any further with this - probably
>> due to my lack of understanding the details of TLS communication and its
>> implementation. I know the server is using some legacy protocol but
>> still I think it should work.
>>
>>
>>
>> Maybe someone has any helpful idea? Is it a bug? You can simply try to
>> run my test code snippet and should see the issue immediately...
>>
>>
>>
>> Thanks
>>
>> Christoph
>>
>>
>>
>