search

RestComm / Restcomm-Connect

The Open Source Cloud Communications Platform
http://www.restcomm.com/
GNU Affero General Public License v3.0
243 stars 215 forks source link

Restcomm TLS version Incompatibility with Media Server #1366

Open croufay opened 8 years ago

croufay commented 8 years ago

Restcomm supports TLSv1, TLSv1.1 and TLSv2 when accessing the Admin UI and RVD over https.

If you disabled the HTTPS connectors to only use TLSv1.2, Restcomm generates an exception, NullExceptionPointer when Downloading RCML

The code that controls downloading RCML can be found here

https://github.com/RestComm/Restcomm-Connect/blob/5647acb9de6e0f138293c537ff0f5ff4b50059ba/restcomm/restcomm.commons/src/main/java/org/mobicents/servlet/restcomm/http/CustomHttpClientBuilder.java#L76

After updating the code to allow TLSv1.2, the NullExceptionPointer is no longer generated but calls still fail.

Restcomm server.log shows the following:

17:15:50,008 INFO org.mobicents.servlet.restcomm.interpreter.VoiceInterpreter MediaGroupResponse, succeeded: false jain.protocol.ip.mgcp.JainIPMgcpException: The IVR request failed with the following error code 312

Media Server logs show this

16:58:49,736 WARN [JitterBuffer] Buffer overflow! 16:58:49,747 ERROR AudioPlayerImpl error occured javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) at sun.security.ssl.Alerts.getSSLException(Alerts.java:154) at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1979) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1086) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1359) at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1343) at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1301) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254) at java.net.URL.openStream(URL.java:1037) at org.mobicents.media.server.impl.resource.mediaplayer.audio.wav.WavTrackImpl.(WavTrackImpl.java:68) at org.mobicents.media.server.impl.resource.mediaplayer.audio.AudioPlayerImpl.setURL(AudioPlayerImpl.java:150) at org.mobicents.media.server.mgcp.pkg.au.Play.startAnnouncementPhase(Play.java:162) at org.mobicents.media.server.mgcp.pkg.au.Play.execute(Play.java:115) at org.mobicents.media.server.mgcp.controller.Request.execute(Request.java:142) at org.mobicents.media.server.mgcp.tx.cmd.NotificationRequestCmd$Executor.perform(NotificationRequestCmd.java:213) at org.mobicents.media.server.scheduler.Task.run(Task.java:122) at org.mobicents.media.server.scheduler.PriorityQueueScheduler$WorkerThread.run(PriorityQueueScheduler.java:424) 16:58:49,749 INFO [Play] Received URL can not be found , firing of 16:58:49,750 INFO [MgcpTransaction] tx=2 Started, message= NTFY mobicents/ivr/1@192.168.1.3:2427, call agent = croufay/192.168.1.3:2727 16:58:49,750 INFO [MgcpTransaction] tx=147483656 was executed normaly 16:58:49,750 INFO [MgcpTransaction] tx=2 was executed normaly
16:58:49,764 INFO [MgcpTransaction] tx=147483654 was executed normaly

I enabled -Djavax.net.debug=ssl on Restcomm and the Media Server and this shows

Allow unsafe renegotiation: false Allow legacy hello messages: true Is initial handshake: true Is secure renegotiation: false scheduler-worker-6, setSoTimeout(0) called %% No cached client session *\ ClientHello, TLSv1 RandomCookie: GMT: 1456532777 bytes = { 199, 214, 238, 1, 57, 106, 87, 126, 48, 2, 132, 188, 4, 226, 162, 94, 116, 185, 133, 208, 7, 27, 228, 83, 218, 84, 156, 189 } Session ID: {} Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, ... truncated] Compression Methods: { 0 } Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1} Extension ec_point_formats, formats: [uncompressed]

scheduler-worker-6, WRITE: TLSv1 Handshake, length = 149 scheduler-worker-6, READ: TLSv1 Alert, length = 2 scheduler-worker-6, RECV TLSv1 ALERT: fatal, handshake_failure scheduler-worker-6, called closeSocket() scheduler-worker-6, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

Restcomm using logs

15:00:21,560 INFO stdout RestComm-akka.actor.default-dispatcher-7, WRITE: TLSv1.2 Handshake, length = 64 15:00:21,569 INFO stdout http-/192.168.1.3:8443-1, READ: TLSv1.2 Change Cipher Spec, length = 1 15:00:21,570 INFO stdout http-/192.168.1.3:8443-1, READ: TLSv1.2 Handshake, length = 64 15:00:21,571 INFO stdout http-/192.168.1.3:8443-1, WRITE: TLSv1.2 Change Cipher Spec, length = 1 15:00:21,571 INFO stdout RestComm-akka.actor.default-dispatcher-7, READ: TLSv1.2 Change Cipher Spec, length = 1

Media Server seems to use TLSv1 by default and when Restcomm is set to use TLSv1.2, the incompatibilty breaks the the handshake.

deruelle commented 8 years ago

@croufay can you make a pull request for the Restcomm fix and create a new issue at RMS to allow for the same thing ?