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.
Related
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.
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
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 tried connecting jms client with 5.3 / 6.0 MQseries client jars to 7.0+ server, but it threw follwoing exception
com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2423
at com.ibm.mq.MQQueueManager.sequentialConstruct(MQQueueManager.java:904)
at com.ibm.mq.MQQueueManager.<init>(MQQueueManager.java:865)
at com.ibm.mq.MQSPIQueueManager.<init>(MQSPIQueueManager.java:83)
at com.ibm.mq.jms.MQConnection.createQM(MQConnection.java:2009)
at com.ibm.mq.jms.MQConnection.createQMNonXA(MQConnection.java:1496)
at com.ibm.mq.jms.MQQueueAgentThread.setup(MQQueueAgentThread.java:306)
at com.ibm.mq.jms.MQQueueAgentThread.run(MQQueueAgentThread.java:1672)
at java.lang.Thread.run(Thread.java:570)
I do understand from http://www.ibm.com/developerworks/websphere/library/techarticles/0704_xu/0704_xu.html that it's not possible to use previous version client libs. But my question is are these latest client libs backward compatible with 5.3 / 6.0 servers ?
V6.0 Yes. V5.3, not so much. The problem here is the 5.3 libs and servers. They were never tested nor intended to be compatible with v7 components because v5.3 was end-of-life well before v7 was released.
The v6 clients are compatible with the v7 server and vice-versa and you would be able to open a PMR if you found issues. The manual for v7 clients states that they are compatible with supported levels of WMQ server, which includes only v6 and v7 (see this link for details).
Word to the wise, do your development on v7 because v6 is end-of-life as of September 2011. This will save you from having to upgrade again in a year. The v5.3 QMgrs should be updated to v7 as soon as time allows. Among other issues are that there are security vulns that were discovered after v5.3 went EOL so no patches were ever produced to address them at v5.3. If security is an issue for your app, you need to be at 6.0.2.9 or 7.0.1.1.
You can download the fix packs and clients here if you need them:
Recommended Fixes for WebSphere MQ
SupportPac MQC7: WebSphere MQ V7 Clients
WMQ v7.1 trial download
UPDATE March 13, 2011 - IBM recently published a Technote clarifying their support statement. According to the Technote:
WebSphere MQ V7.0 queue managers and
clients interoperate with queue
managers and clients from any previous
level of the WebSphere MQ or MQSeries
products.