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).
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 have a weblogic 10.3.6 installed in windows server 2008 R2 64-bit with Java 7 update 111. With in weblogic server I have 4 manged server running many java applications.
I have new client web-services application need to be deployed in one of the 4 manged server and this application require TLS1.2 as requested by third party services provider application. For that purpose, I am setting the following property in client application code like System.setProperty("jdk.tls.client.protocols", "TLSv1.2");
Question:
Will the statement System.setProperty("jdk.tls.client.protocols", "TLSv1.2"); change the protocol for only manged server where the application is deployed ? Or it will be for all application servers available within weblogic ?
If this command change the protocol for all manged servers, then this is a problem since other applications may get affected. What is the solution in this case and what is the right action to be taken to enable the required SSL protocol for that specific application without affecting other running applications ?
It should affect all managed servers on that box (probably after the nodes are restarted)
TLS is compatible with SSL - just not with insecure handshake protocols (which you should have stopped doing years ago) For more information, see: Modifiying Weblogic Server to use TLS
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
OpenShift swiftly addressed the SSL 'Poodle' vulnerability around October 16th 2014. Since then the e-commerce provider I work with can no longer establish a secure HTTPS connection with my OpenShift PHP application. I suspect this is, at least in part, because SSL3 is no longer an available protocol.
The error logged at the e-commerce provider end is:
javax.net.ssl.SSLException
java.lang.RuntimeException: Could not generate DH keypair
Here's what I've tried and discovered so far:
The online SSL testing tool at https://www.ssllabs.com/ssltest/ indicates my SSL Certificate is installed correctly (installed via the OpenShift WebConsole), and it receives an 'A' grade. HTTPS works fine when connecting to my OpenShift PHP application in a normal web browser. In general the SSL Certificate & installation itself seems fine.
As a test, I have tried using OpenShift's shared SSL Certificate instead of my own, with exactly the same result.
Java 7
The remote e-commerce platform that is attempting to connect to my OpenShift PHP app via HTTPS uses Java 7. Tech support thinks the issue is that their Java 7 system doesn't support cipher key lengths > 1024 bits. Unfortunately they're not in a position to upgrade their system to Java 8 at present, so their hands are a bit tied.
Handshake Simulation
The ssllabs analysis of my SSL Certficate includes a useful Handshake Simulation test with various clients. This actually shows a Java 7 simulation connecting OK using TLS1.0, however the Java 6 simulation fails with a 'Client does not support DH parameters > 1024 bits' error - roughly echoing what e-commerce tech support is seeing reported by their Java 7 based system.
How might I solve this? To narrow the question down a little:
Is there a simple adjustment my e-commerce provider could make at their end to enable HTTPS connections to OpenShift applications, without them having to upgrade Java or make significant changes that could impact others? e.g. An option to accept DH parameters > 1024 bits.
Is there anything I can adjust at my end (perhaps an OpenShift or PHP setting) to enable their Java 7 based system to establish a HTTPS connection with my OpenShift application successfully? e.g. An option instructing OpenShift to provide DH parameters <= 1024 bits.
Restarting your application should resolve the issue as it will pick up the latest JDK that should contain the latest fixes for this issue.
https://bugzilla.redhat.com/show_bug.cgi?id=1035818
https://bugzilla.redhat.com/show_bug.cgi?id=1080125
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.