Reputation: 54094
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?
Upvotes: 3
Views: 4513
Reputation: 74522
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.
Upvotes: 3
Reputation: 42018
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.
Upvotes: 1