Skip to main content

CipherSuite for TLS 1.0 security issue in JXTA?

4 replies [Last post]
adamman71
Offline
Joined: 2007-01-31
Points: 0

Hi,

It looks like no cipher suite is specified by JXTA when creating a TLS 1.0 connection. Therefore it tacitly implies that the cipher suite that will be used depends on what both peers will agree on. It also means that it will depend on which CipherSuites each peer supports (i.e., has implemented).

Some of the authorized cipher suites defined in the official specification of TLS 1.0 use notoriously weak algorithms. So, if I am a vicious hacker, I could fiddle with the current JXTA implementation to pretend that my SSLSocket connection only supports one of those weak cipher suites.

I would distribute my product based on my fiddled version of JXTA, let those using this version start some communication and evedrop those communications. They will be able to establish 'secured connections' with non-fiddled JXTA implementation peers assuming that these implement the weak cipher suite too.

Since the CipherSuite algorithm can relatively easily be cracked, I can retrieve their secrets relatively easily, defeating the purpose of secured communication. This attack is a bit hard to achieve, but some hackers will manage to accomplish this.

I think that a simple control on TLS_NULL_WITH_NULL_NULL is not enough. If we set a list of 'good' cipher suites and checked against it when establishing TLS connections, this attack would automatically be defeated by those using the official implementation of JXTA.

Am I missing something?

J.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
thenetworker
Offline
Joined: 2003-06-13
Points: 0

I have approached the issue from a different perspective. Because the latest Java's SSL/TLS is engine based, that means you can use any transports to carry SSL/TLS traffic. I use JXTA (unsecured/regular) pipes just as a tranport. JXTA does not even care about what data it carries. My data happen to be the SSL/TLS data, into and out of the SSLEngine.

So, you can benefit from all the SSL/TLS features in Java SE, without worrying about the fact that JXTA is carrying your traffic.

adamman71
Offline
Joined: 2007-01-31
Points: 0

Hi, I get your point, but in order to transport the data over secured pipes, JXSE (the java implementation of JXTA) uses TLS via SSLSockets. The issue I am raising is that one can fiddle with that to create an attack on the system.

It is not because I would use a higher level JXTA protocol that the problem would be solved at a lower level. The solution is simple to implement. I will submit a proposition to the development team later.

Thanks,

J.

thenetworker
Offline
Joined: 2003-06-13
Points: 0

The point is that the entire secure pipe is obsolete now. It needs to be re-implemented anyway.

We would be better off if we spend time on upgrading the pipe instead of fixing an obsolete pipe.

By the way, the "new" (stable for two or three years by now) Java TLS/SSL engine is actually much simpler to use and more powerful than the old one.

adamman71
Offline
Joined: 2007-01-31
Points: 0

Hi,

After discussing this with buzzheavyyear, it seems like a balanced solution to this issue would be to implement some functionalities allowing users to select the cipher suites and the tls version to be used in secured communications.

I believe this should be done either in the NetworkConfigurator or the PSEConfig object (may be someone has a better proposition).

Unfortunately, I will not be able to implement this soon. So, if anyone wants to take the duty...

Cheers,

J.