SSLv3 not supported from JBE

Michele Pegoraro (1.8k●14●119●103) | asked Nov 06 '15, 7:37 a.m.

Hi,
I was trying to run a jazz build engine in order to connect it to a jetty run of RTC (v5.0.2) on which I was testing some customization. It seems that it finds the server and login but then I have this error:

CRRTC3524W: Communication with the repository failed due to this error:
CRJAZ0099E An HTTP error occurred when this URL was being accessed: https://localhost:9443/jazz/versionCompatibility?clientVersion=5.0.2.
Error details: Server chose SSLv3, but that protocol version is not enabled or not supported by the client..

I suppose this is related to the jetty environment, because it works well with a standard installation. How can I fix it?

It worked well with version 3.x (I don't remember if I had tested this with version 4.x).

Thanks,
Michele.

Accepted answer

permanent link

Ralph Schoon (63.3k●3●36●46) | answered Nov 06 '15, 8:34 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

Please see

https://rsjazz.wordpress.com/2015/07/30/unable-to-connect-to-the-jetty-server-using-current-browsers-due-to-ssl-error-extending-rtc-versions-lower-than-6-x/
https://rsjazz.wordpress.com/2015/04/28/chrome-does-not-work-with-rtc-debug-server-on-jetty/

I haven't looked at the JBE in this context, but the problem is basically related to security risks like POODLE and that some SSL versions have been ditched. In Jetty SSL3 is hard coded to be used. I am not sure why your JBE has a problem, because the JBE, if it is from the same version, should still support the same SSL versions Jetty has set. Only in never versions, these have been removed. You should see problems with the browsers, but not from Jetty, if the versions are compatible, I think.

Michele Pegoraro selected this answer as the correct answer

Comments

Michele Pegoraro commented Nov 06 '15, 9:17 a.m.

Yes, I have the same error on firefox but on the browser I can manage it, in JBE I don't see how. I also have the same problem using the plain API but in that case it is only a warning exception on the server log and the java class is not really impacted.

Ralph Schoon commented Nov 06 '15, 9:28 a.m.

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

This does not make sense. If you use the same version of the Plain Java Client Libraries, the SDK, the client and the Server this can not happen, because they all shipped with the same settings and capabilities. The Browser would create issues because they get updated.

Michele Pegoraro commented Nov 12 '15, 5:26 a.m.

I think that the problem is that the server is launched with jetty that changes the SSL protocol. Plain API and build engine is not expecting this SSLv3 and so the server gives this warning. The problem is that in the jbe this warning is managed blocking the connection. Do you think it could be possible to launch the jbe with jetty? Probably I have to configure a proper launch configuration (and by now I don't know which feature/configuration could be included...)

Michele Pegoraro commented Nov 12 '15, 5:28 a.m.

This is the full exception stack given by the server that does not block the plain api but only the jbe:

2015-11-12 10:26:52.355:WARN::EXCEPTION
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
    at com.ibm.jsse2.o.a(o.java:32)
    at com.ibm.jsse2.o.a(o.java:3)
    at com.ibm.jsse2.SSLSocketImpl.b(SSLSocketImpl.java:817)
    at com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:500)
    at com.ibm.jsse2.SSLSocketImpl.h(SSLSocketImpl.java:645)
    at com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.java:138)
    at com.ibm.jsse2.SSLSocketImpl.startHandshake(SSLSocketImpl.java:268)
    at org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:675)
    at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)

Ralph Schoon commented Nov 12 '15, 9:44 a.m.

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I haven't tried that, so I can't say. In principle the JBE is basically an Eclipse Client based application. Unfortunately I don't have a feature based launch for it.

I reported the SSL problem and it is impossible to fix it, since the SSL protocol is hard coded into the Jetty Launch. So this needs a real patch. Problem is how to ship that for all previous versions?

You can use RTC 6 or 6.0.1 to develop the plugin, Jetty is fixed there, and then just remove the minimal dependent versions from the manifest and run it on older versions.

Michele Pegoraro commented Nov 13 '15, 5:26 a.m. | edited Nov 13 '15, 5:26 a.m.

As is has been fixed with version 6 in this case I think it will be easier to test the build engine related extension with a proper local server instead of the jetty one. Thanks!

Donald Nong commented Nov 13 '15, 5:31 a.m.

I believe from version 4.0.6, all RTC components (including JBE) disable SSLv3 as well. While for newer versions of Java, there are ways to enable SSLv3, I can't see any documents talking about how to enable SSLv3 back for RTC. I can get passed the handshake failure but JBE still reports communication errors. The below parameters do not seem to have any effects.
-Dcom.ibm.team.repository.transport.client.protocol=SSL_TLS
-Djazz.connector.sslProtocol=SSL_TLS

Ralph Schoon commented Nov 13 '15, 6:14 a.m.

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

In Jetty in the SDK the protocol is hard coded (SSL in versions before 6.0). No way to change it, except in the product code and shipping a new SDK.

In the product I would assume that several ciphers and protocols are basically removed, since they are too prone to attacks and you basically can't configure them any more.

showing 5 of 8 show 3 more comments

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

It's all about the answers!

Related questions

SSLv3 not supported from JBE

Accepted answer

Your answer