We have a Tomcat based Infra monitoring application which will connect to other servers and monitor / alert etc.
However , some of our servers are using TLSv1.2 only and seems that the monitoring application is only using the TLSv1 to connect which is having a slight issue.
We are currently doing a workaround by using http port to mornitor but for long term we would like to use the TLSv1.2.
Is there a way to force Tomcat to connect to other applications via TLSv1.2 only?
Thanks
Using Tomcat 7 and Java 1.7.
The documentation for the SunJSSEProvider says:
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.
So TLS 1.2 is there, it just isn't enabled. To enable it add something like
-Dhttps.protocols=TLSv1.1,TLSv1.2
to the startup-parameters of your tomcat. Then it should be able to speak TLS 1.2 as well as TLS 1.1. If you need any older protocols you can also add them as described in the linked documentation.
Related
We are trying to validate what TLS version our web client application is using. We can run nmap --script ssl-enum-ciphers -p 443 www.example.com as we see TLS version 1.2 (That's the version we want.) However we are wanting to validate what version of TLS is being used from web application client directly? Not the server. This is a 1.6 java application that is deployed on Weblogic. Is this request possible to validate on the application directly? I see a lot of threads validating at the server level or the or validating what the server end, not the client application level.
I need to connect with a URL but I can only connect with TLS 1.2 and the Java version available is Java 1.4. Is it possible, and if so, how to do it?
I have a client application communicating with external party application. The client application is up and running for long time.
Recently, I received a request from the third party asking about the allowed SSL/TLS protocols from the application server where my client application is running and calling their application.
Questions
How to tell what SSL/TLS protocols allowed from my client application ?
What has been done so far
1 - I checked SSL configration at the server's browser where my client application is running, See below screen shot. Is this what the third party team trying to know?
2 - The client application is running from weblogic 10.3.6. I cheked weblogic configuration in the following but I could not find any thing about the SSL/TLS protoclos used:
2.1 - Summary of Servers >Server_1 >Protocols
2.2 - Summary of Servers >Server_1 >Configuration >SSL
------ Update ------
I am using Java 7 for the client application. For that I checked the Java™ Secure Socket Extension (JSSE) documentation online. In the online documentation I found the following
Engine Class Implemented : SSLContext
Algorithm or Protocol: SSLv3 (a.k.a. SSL), TLSv1 (a.k.a. TLS), TLSv1.1, TLSv1.2
See documentation Java Cryptography Architecture Oracle Providers Documentation for Java Platform Standard Edition 7, The SunJSSE Provider for more information.
So is this the allowed SSL/TLS protocols from my client application? Further if Java has its own allowed Protocols, then how is that related to protocols setting in the browser ( Point 1 above )?
See http://docs.oracle.com/cd/E24329_01/web.1211/e24422/ssl.htm#SECMG634 (there are similar settings for 11G)
The browser settings are a red herring - the third-party app will connect to weblogic, not your browser, and negotiate a secure protocol based on what WLS + the third party app can mutually support.
Java7's default settings are acceptable, although if you need PCI-DSS compliance, you should probably set TLS1.1 as the minimum.
I want to initiate an SSL connection with a remote server using SSLv2. I am using Java. I tried to get the supported protocols in my socket using:
String[] suppProtocols=socket.getSupportedProtocols();
System.out.println("The protocols supported for this socket are:
"+Arrays.toString(suppProtocols));
and I got this in the output:
[SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]
Now, I read that Java does not support SSLv2 and SSLv2Hello only sends hello message using SSLv2. I can't grasp what does this means? Isn't the same as if the client support SSLv2? How can I make SSL connection using SSLv2.
SSLv3 and TLSv1.x offer a way to wrap their Client Hello message in an SSLv2 Client Hello, as described in the TLS specification: Backward compatibility with SSL. SSLv3 and TLS 1 and above have a more consistent mechanism to negotiate the version. As the TLS spec says:
The ability to send Version 2.0 client hello messages will be
phased out with all due haste. Implementors SHOULD make every
effort to move forward as quickly as possible. Version 3.0
provides better mechanisms for moving to newer versions.
The Sun/Oracle JRE or OpenJDK doesn't support SSLv2. Wrapping an SSLv3+ message into an SSLv2 message was just for backward compatibility. It is now disabled by default for clients in Java 7. From a server point of view, it can at least accept other SSLv3+ clients that wrap their Client Hello message in an SSLv2 message this way, whether they support SSLv2 or not.
You'll find more details about Java support (including other implementations) in this question.
Generally speaking, SSLv2 is considered insecure: you simply shouldn't use it. The general trend is to move away from SSLv3 towards TLS 1.0 or higher, not to go backwards.
There is a project that uses extensively JSSE.
Depending on a configuration parameter the SSLContext is initialized for SSLv3. Meaning that if the parameter is not set it is SSLv3, otherwise it is TLS.
I noticed some handshake failures occasionally and traced it: If the client negotiated TLS and the server replied with SSLv3, the handshake failed
Why does this happen? I thought that TLS and SSLv3 are pretty much interchangeable.
Are they not? If I change server side to always reply TLS is there a chance I will break something?
TLS 1.0 is, internally, SSL 3.1. A client and a server may accept to use either or both; during the handshake, the client sends the highest protocol version it knows of, and the server should select the highest version that it supports that is not always newer than the one sent by the client.
My guess is that when you configure your client to use TLS, then the client understands it as "use only TLS 1.0": the client sends "3.1", and if the server is configured to respond with "3.0", then the client will quite logically reject the connection.
What you should do is find a way to configure the server to accept both 3.0 and 3.1, and thus use whatever protocol version was announced by the client. Alternatively, configure the client to declare that it knows 3.1, but such that it also accepts a "downgrade" to 3.0 if the server says so.
You don't say what you are trying to achieve by varying the protocol parameter. SSLv3 and TLS1.0 are very similar but nevertheless distinct protocols. The protocol negotiation mechanism introduced in SSLv3 is also used in subsequent protocols. The bottom line is that in SSLContext.getInstance("proto"); you should set proto to the earliest version of the SSL protocol you are willing to support. After that, the peers will negotiate to use the newest version of the protocol they both support.