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.
Related
I would like to implement tls protocol on my server and client.
My question is simple:
the class SSLSocket use either the TLS protocol or is it the same thing?
I haven't implemented it in my code yet, but I'm excited about the possibility.
My question is simple: the class SSLSocket use either the TLS protocol or is it the same thing?
The short answer is Yes.
The standard SSLSocket class supports both SSL and TLS. Quoting from the first line of the javadoc:
"This class extends Sockets and provides secure socket using protocols such as the "Secure Sockets Layer" (SSL) or IETF "Transport Layer Security" (TLS) protocols."
However this need to be qualified in that the actual protocols and versions that are allowed depend on defaults and settings that change over time. For example, recent Java releases will (by default) reject SSLv2, SSLv3, TLSv1, and TLSv1.1.
Finally, you should avoid using any of the disabled versions (or related disabled features) if possible as they have known security weaknesses and in some cases are vulnerable to compromise.
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.
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'm trying to tunnel tls via a text-only communication channel (I thought about using base64) but I cannot seem to find a tls server example that doesn't use SSLSocket.
For a tls client I was able to find the bouncy castle TlsProtocolHandler which is transport agnostic because it just uses an input and output stream, but I couldn't find anything similar for a server tls implementation.
Using SSLSocket:
You can certainly implement your own Socket that is not based on TCP. For example there are Unix socket implementations. Once you have it for your own transport, SSLSocketFactory.createSocket(Socket, ...) can establish an SSLSocket on top of your own Socket.
Using SSLEngine (a bit more complex):
SSLEngine.wrap (and unwrap) work on ByteBuffers. These buffers could come from your own communication channel.
One of the difficulties you may encounter is the mapping of the notion of certificates to your custom transport. Certificates (or more generally proving the identity of the server) is essential to the security of an SSL/TLS channel, to prevent MITM attacks. Identity verification requires both checking the certificate as trusted, and that the identity it's for corresponds to the entity you were trying to reach (hostname verification). Hostname verification isn't enabled by default, but you'd need to find something similar anyway, if you don't have host names (that could be a problem for unix sockets, for example, although using SSL in this case might not make sense anyway).
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.