6

I have a Java Implementation which used by various client applications to connects to to the third party systems. These third party systems supports different protocols over http/https. In this case, all client applications are hosted in the same server where my Java Implementation hosted. So,in this case, various client applications set various https protocols to the System properties (eg: System.setProperty("https.protocols", "SSLv3") , System.setProperty("https.protocols", "TLS") when they are using this to connect to those third party systems.

Here, the System properties are shared among all the applications in that environment. So, modifying a System property leads to many problems. So, I want to know,

  1. Is there any way to get this done without using System properties?
  2. Is there any way to set all the possible https.protocols so that it supports any http or https connection made to the third party systems supports various protocols?

Protocols and algorithms supported in each JDK version as mentioned in blogs.oracle.com: enter image description here

Code :

String responseStr = null;

System.setProperty("https.protocols",http-protocol); // This is set by the client applications. Previously, there was one by one (eg : "SSLv3". Then I changed it to "TLSv1.2,TLSv1.1,TLSv1,SSLv3" assuming it will enable all) 

byteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
byteArrayOutputStream.write(requestStr.getBytes());

URL mUrl = new URL(proxy_url);
HttpURLConnection con = (HttpURLConnection) mUrl.openConnection(); // It works fine for the HttpURLConnection when there's no (s)

con.setRequestMethod("POST");
con.setDoOutput(true);
con.setUseCaches(false);
con.setDoInput(true);

con.setRequestProperty("user-agent","Mozilla(MSIE)");
con.setRequestProperty("Accept-Encoding","gzip,deflate");

byteArrayOutputStream.writeTo(con.getOutputStream());

String encodingHeader = con.getHeaderField("Content-Encoding");
InputStream inputStream = null;

if(encodingHeader != null && encodingHeader.toLowerCase().indexOf("gzip") != -1){
    inputStream = new GZIPInputStream(con.getInputStream());
}else {
    inputStream = con.getInputStream();

}

if (inputStream != null) {

    ByteArrayOutputStream baos = new ByteArrayOutputStream();
       byte[] buffer = new byte[4096];
       int length = 0;

       while ((length = inputStream.read(buffer)) != -1) {
           baos.write(buffer, 0, length);
       }

    responseStr = new String(baos.toByteArray());
    baos.close();

 }

My Java version : 1.5

namalfernandolk
  • 8,328
  • 11
  • 53
  • 105
  • You need to upgrade. 1.5 came out a decade ago. – user207421 Dec 15 '15 at 08:47
  • That is very true. But right now there's a big workaround there for that. So, I'm looking for solution in current version – namalfernandolk Dec 15 '15 at 09:06
  • The answers to this question may be relevant: https://superuser.com/questions/747377/enable-tls-1-1-and-1-2-for-clients-on-java-7 Of note is the Oracle documentation, which shows that while TLS1.2 is supported on Java 1.7, it is disabled by default for client connections. – BryKKan May 25 '17 at 16:25
  • The ByteArrayOutputStream is a waste of time and space here. – user207421 Nov 01 '17 at 01:45

1 Answers1

1

I suggest you don't set it at all. Just let the system negotiate with the peer. It will negotiate the strongest shared protocol.

user207421
  • 289,834
  • 37
  • 266
  • 440
  • But, then it uses the https.protocol default to the jdk version right? I mean, in this case, when I try to connect to the third party system that requires higher https protocol (eg : TLSv1.2) it will not supported since my java version is not higher enough. reference : https://blogs.oracle.com/java-platform-group/entry/diagnosing_tls_ssl_and_https – namalfernandolk Dec 15 '15 at 11:11
  • It negotiates the highest protocol common to both peers. I already said that. If your Java version doesn't support what the peer requires, no amount of setting system properties is going to change that. – user207421 Dec 15 '15 at 11:39
  • Yes I noted that EJP. But practically we have encountered some issues when it is not mentioned. So, you are saying that it is no use of mentioning https.protocols higher than the java version? (We can use it to connect via a lower protocol?). I really appreciate your comments. – namalfernandolk Dec 15 '15 at 11:47
  • That's exactly what I said. You will certainly encounter issues if the peer requires a higher version than your Java supports, but that has nothing to do with mentioning the system property. If you need TLS 1.2 support your only choice is to upgrade your Java version. – user207421 Dec 15 '15 at 11:48
  • 1
    I understand what you are saying. But think about a situation where I have a client application called "x" and another client application called "y" that uses my implementation. Suppose my java version is 1.7. Application x needs TLSv1.2 to connect third party, So, it doesn't connect when there's no protocol mentioned since it the default for JAVA 1.7 is TLSv1. When we set the http.protocols as TLSv1.2 it works. But it effects to other client application "y" that needs another protocol to connect. If we don't mention the https.protocol it uses the DEFAULT one right? Not the BEST one. – namalfernandolk Dec 15 '15 at 12:05
  • I updated the question with Protocols and algorithms supported in each JDK version as mentioned in blogs.oracle.com. – namalfernandolk Dec 15 '15 at 12:10
  • Your question says your Java version is 1.5, which doesn't support TLS 1.2, so why are we now talking about 1.7, which does? And doesn't have any problem talking to a peer that requires it? What is your actual question? – user207421 Dec 15 '15 at 12:32
  • Yes the version where I got the issue is in java 1.5. But I'm looking for a solution considering other java version also not only 1.5. And I got your answer on specifying higher protocol on lower version. It is clear and thank you very much for it. But I want to clarify this considering other versions too. Because it is (and it will be) currently using by many other versions also. If I completely remove that https.protocols from the application I want to know what will happen for above like scenarios. – namalfernandolk Dec 15 '15 at 14:23
  • I am using Java 1.7 which is supporting (TLS1 , TLS1.1, TLS1.2 and SSLv3). After enabling SSl debug on the client side. I found the following `*** ClientHello, TLSv1` Can we say - based on your answer - that the strongest protocol available at the server side is TLS1.0 ? – Salman Aug 25 '16 at 09:28
  • What will happen in any scenario and in any version of Java is that TLS will negotiate the highest common protocol. Nothing you've said changes anything, and your statement that 'it uses the default protocol' is *false*. You can't tell the server version from the ClientHello message. – user207421 Nov 01 '17 at 01:50