I developed a client to communicate with a distant server using a jersey jackson library in java 1.6 (I am obligated to use this version). -- All is fine so far!
I was informed that the distant server is going to start using e a more recent TLS version to communicate. (now it is TLS V1.0 and the version that will be used is TLS V1.2).
What is the impact that this will have on my application (Taking into account that the operating system can handle a TLS V1.2)?
Remark: I use a simple WebResource to retrieve the answer.
The answer to your question is platform dependent. It depends on the JSSE your client JVM comes packaged with.
The JSSE is the Java Secure Sockets extension. It is a pluggable component of the the JVM that provides the SSL/TLS support for your application. I know the JSSE that comes with the Sun 1.6 JVM for Windows does not support TLS v1.2. IBM's JSSE for their 1.6 JVM does support v1.2.
WRT to how this affects your application: that also depends. If the only protocol your server supports is 1.2 then you must also have that support in your client's JVM/JSSE. If the server will negotiate down to 1.1 then your 1.6 JVM/JSSE will most likely support that.
BTW it really doesn't have anything to do with the versions of Jersey/Jackson your app uses. It really depends on the JVM the application is running on.
If your client app will run on a 1.7 or 1.8 JVM you will get TLS v1.2 support for free from the JVM without any code changes. Also the newer VMs by default deactivate some insecure cipher suites that are enabled by default in most of the 1.6 JVMs out there
Related
Just noticed that netty-tcnative-boringssl doesn't support AIX(tried on AIX and confirmed by netty-tcnative's dev). Which got my ass burning and eager to find the alternative solution for HTTP2 with native openssl lib as sooner as possible.
Since I need to run it on Java8 which doesn't have HTTP2, so they must have native support of it. Does anyone know Apache HTTP Client 5 or OkHTTP have native openssl(boringSSL) builtin, or addon lib that could make them running without using JDK's SSL provider?
I am fairly new to the web development, I have been going over the release notes of the Java on different platforms like linux (oracle hotspot), AIX and hp-ux. I am actually investigating around the TLS support of each version of java on those platforms. I am coming across information(Java 8, AIX) showing the support for client-side connections and server-side connections. What I do not understand is what is the difference between them.
Does it simply mean that the client trying to connect to a server and the other is server trying to connect to a client? If that is the case why is the TLS support different for both of those connections. I would like to understand the general difference between both of them and what it has to do with the TLS support.
I am running a java application which uses J2ssh library to establish the connection to the server.
Last week we migrated to a new IBM server
Here the problem is we are unable to establish FTP/SFTP connection to the new server from my java application. But the connectivity is working fine from other tools.
My doubt is whether the J2SSH library will support the below ciphers/macs ? because these are the ciphers configured in the new IBM server.
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128
MACs hmac-sha1,umac-64#openssh.com,hmac-ripemd160
It sounds like your using a very outdated version of J2SSH.
You should upgrade to the more recent open source version J2SSH Maverick that supports counter mode ciphers.
My apllication is deployed on Tomcat 6 with Java 6, I want to restrict the SSL protocol to use only TLSv1.1. According to Java 6 documentation JCE isn't supporting TLSv1.1 while Java 7 does.
Upgrade my Java version isn't acceptable. There is any providers that implements TLSv1.1 protocol that I can integrate to my java?
Since it's production system I am looking for quick and safe fix. I thought to front end my application server with apache web server at the same host(which supports TLSv1.1 through openssl) and use him as a proxy server. Unfortunately my physical resources are low.
Any other ideas are welcome.
Thanks.
Front it with a system that does the SSL and does get security updates. You can run apache using the connector - if you still trust this - or setup a Java application (a newer version of Tomcat?) to act as an SSL proxy (connecting to port 80 of your server, if this is acceptable to you).
I'm using Openfire 3.8.1 as XMPP server on windows, but open fire supports only TLS 1.0 and i need support for TLS 1.2
How can i configure Openfire to support TLS 1.2?
Also i read that openfire is compiled with jdk 1.5 or 1.6 and those versions of jdk don't support TLS 1.2. If I compile openfire sources with jdk 1.7 that support TLS 1.2 will it be enough?
Change the JRE Openfire is using from 1.6 to 1.7. If you are running Openfire in Windows, create a batch file that uses Java 7, based on the shell script openfirectl. There is no need to recompile the code.
You'd have to upgrade from 1.6 (e.g. openjdk-6) to 1.7 (e.g. openjdk-7) to get TLS 1.2.
Note that even with openjdk-7, TLS 1.2 is still disabled for client connections:
http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#tlsprotonote
Although SunJSSE in the Java SE 7 release supports TLS 1.1 and TLS 1.2, neither version is enabled by default for client connections. Some servers do not implement forward compatibility correctly and refuse to talk to TLS 1.1 or TLS 1.2 clients. For interoperability, SunJSSE does not enable TLS 1.1 or TLS 1.2 by default for client connections.
This means that for server-to-server connections, where openfire is acting as a client, it will still not use TLS 1.2 even with openjdk-7 (only in openjdk-8 would TLS 1.2 be finally enabled by default).
I've looked at the source code of openfire and the Java API, and made a conclusion that you should be able to fix the issue with the following (although I haven't had the chance to confirm it having the desired effect):
INSERT INTO OFPROPERTY VALUES('xmpp.socket.ssl.algorithm','TLSv1.2')
E.g. your best bet is to go with either Java 7 or 8, then if going with 7, try the above setting, too.