Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

SSLv3 not supported from JBE

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.

0 votes


Accepted answer

Permanent link
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

0 votes

Comments

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.

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.

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...)

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)

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.

1 vote

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!

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


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.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 10,941
× 76
× 36

Question asked: Nov 06 '15, 7:37 a.m.

Question was seen: 3,925 times

Last updated: Sep 20 '17, 10:50 a.m.

Confirmation Cancel Confirm