Improve support for Transport Layer Security (TLS) protocol

[brainslog]

Currently the TLS support in Diameter stack is somewhat "proprietary", based mostly on the way RFC 6733 specifies, and it's known to work properly between two jDiameter instances but not so much with other stack implementations.

This should be revised and made available in both modes (RFC 3588 and RFC 6733), being defined by configuration (if possible, on a per peer basis).

It should be tested against other implementations (freeDiameter, seagull, etc).

[deruelle]

@coolface88 I assigned the issue to you. Feel free to ask any questions here or/and report back regularly on progress. Thanks !

[coolface88]

Great! I will do some investigation first. Thanks

[coolface88]

I have built jDiameter successfully, now I am digging into the code and docs for insights..I am also trying to setup segull and the simulator found in this link http://docs.telestax.com/jdiameter-quick-telscale-diameter-performance-testing-using-seagull/

[deruelle]

Thanks for the update @coolface88 !

[coolface88]

I have excuted TLS testing scenarios configured with seagull client and jDiameter server..get an error of SSL_ERROR_WANT_READ from openssl..I will analyse more from tcpdump and enabled debug log.

[deruelle]

Thanks for the update @coolface88, keep us updated

[brainslog]

@coolface88, it's somewhat expected that Seagull and jDiameter won't work properly with TLS. IIRC in jDiameter it's being used RFC 6733 compliant TLS (CER is sent over TLS connection) while seagull uses RFC 3588 TLS (where CER is exchanged and only after successful capabilities negotiation, the transport is upgraded to TLS).

Having the RFC 3588 behavior implemented would be a good first step, after that, adding the possibility to choose between the different types, via configuration.

[coolface88]

@brainslog, thanks for your info..it is actually Seagull can work with both RFC 3588 and RFC 6733 based on its configuration scenerios. I was able to test both of them and it worked. At a first glance, I think jDiameter is complying with RFC 3588 not RFC 6733. Anyway I undersand your requirement will do it :)

[deruelle]

@coolface88 were you able to make progress on this ?

[coolface88]

@deruelle Hi, sorry last week I did not touch much. I have excuted the client/server with trace log enabled and understood the execution flow. I have changed the jDiameter code of server side to work with TLS. Hopefully, I will finish this week. Thanks , BR ... Hung

[deruelle]

Thanks for the update @coolface88 !

[coolface88]

Hi, it takes more time than I thought. There was a problem at TLS handshaking between jDiameter server and Seagull client. The client has not sent any setup information to server to initiate the handshaking. I will investigate more on this issue.

jdiameter_server_log.txt

[deruelle]

Thanks for update @coolface88.

[deruelle]

@coolface88 were you able to investigate the issue and get more insights ?

[coolface88]

ClientHello was sent but server did not understand it. I have changed ClientHello message with different formats like SSLv2Hello, SSLv3, TLS advertised as Java supported but no luck so far. One of outstanding known issue regarding ClientHello is large number of cipher suites in it. I am narrowing down the possibilities now.

[deruelle]

@coolface88 great, TLS handshakes are not the most easy to debug. you can try to enable -Djavax.net.debug=all to get more insights

[deruelle]

@coolface88 any news on this issue ?

[coolface88]

@deruelle @brainslog I did all TLS java debug enabling but the info was not very useful. I have spotted out one thing which is quite suspicious. Looks like the handshake message is sending too fast from seagull client so the server has not established the secured socket yet. I still have not figured out how to synchronize this

[deruelle]

Thanks @coolface88 let us know if you were able to make more progress.

[deruelle]

@coolface88 just to let you know. The stack also now has a Netty based TLS implementation as part of https://github.com/RestComm/jdiameter/issues/35 which may be worth testing as well.

[jehanzebqayyum]

netty jdiameter impl is only RFC 3588 at the moment. I tried that with seagull client using TLS and it sent Client Hello without sending a CER. So seagull is following RFC 6733 for TLS although it advertises on the website that it is following RFC 3588. (ref: http://gull.sourceforge.net/doc/diameter.html)

[coolface88]

@jehanzebqayyum seagull can be configured to work with both RFCs, I will post a guide here later today

[coolface88]

@jehanzebqayyum I assume that you know how to install all TLS related stuff of seagull. Then you can continue with below configurations. For RFC 3588 complying, you need to set these two transport-option channel="channel-1" value="secure-mode" and init-args="...secure=no". For RFC 6733 complying, you need to set only init-args="...secure=yes".

ccr-cca-event-client.txt conf.client.txt

[jehanzebqayyum]

thanks @coolface88. netty jdiameter impl waits for StartTlsRequest whereas seagull client sends ClientHello after CEA.

[coolface88]

@jehanzebqayyum I am not sure about netty but StartTlsRequest is related to LDAP association. I believe that the current implementation of jDiameter has not coped with this. ClientHello happens during TLS handshaking phase. Maybe this issue need another ticket.

[jehanzebqayyum]

I removed startTls and change to simple tls handshake impl. For some reason seagull sends CER again, after receiving CEA, during/after handshake which makes the whole communication out of synch.

Does it look like a successful handshake? Client Hello Server Hello, Certificate, Server Key Exchange, Server Hello Done Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message Change Cipher Spec, Encrypted Handshake Message

P.S: I had to add Inband-Security-Id=1 in CER in seagull config.

[coolface88]

@jehanzebqayyum can you please clarify what is simple tls handshake and share your app and wireshark logs? looks like you had a successful handshake.
In my case, with current tls setup the jDiameter server has not sent out anything after receiving the ClientHello. seagull: Client Hello sent over plain socket jdiameter: Client Hello acknowledged jdiameter: startTLS() executed jdiamter: Server hang We should receive Client Hello after startTLS()

[jehanzebqayyum]

By simple i mean not StartTLS which starts with StartTlsRequest and StartTlsResponse befor ClientHello. I will share my branch. But i have a problem that seagull goes to init section again after the handshake i.e. it sends CER twice. It does not even respect the wait-ms.

[coolface88]

Thanks @jehanzebqayyum please share it. I could not tell much without logs. Can you confirm that the server side has setup TLS socket successfully before receiving ClientHello ?

[jehanzebqayyum]

@coolface88 Here it is: netty-tls for your ref: I originally created keys & certs using keytool. And later converted the same to pem files for use with seagull. Changes in server's conf.xml <LocalPeer security_ref="tls-server">

  <Security>
    <SecurityData name="tls-server" protocol="TLSv2" enable_session_creation="true" use_client_mode="false" need_client_auth="true">
      <KeyData manager="PKIX" store="JKS" file="/home/jehanzeb/Documents/software/eclipse_workspaces/restcomm/jdiameter/testsuite/tests/src/test/resources/certs/server-ks.jks" pwd="changeit" />
      <TrustData manager="PKIX" store="JKS" file="/home/jehanzeb/Documents/software/eclipse_workspaces/restcomm/jdiameter/testsuite/tests/src/test/resources/certs/server-ts.jks" pwd="changeit" />
    </SecurityData>
  </Security>

  <Extensions>
    <Connection value="org.jdiameter.client.impl.transport.tls.netty.TLSClientConnection" />
    <NetworkGuard value="org.jdiameter.server.impl.io.tls.netty.NetworkGuard" />
  </Extensions>

In conf.client.xml i only mentioned client certificate and client key. init-args="method=SSLv23;cert_chain_file=certs/client-ksc.pem;private_key_file=certs/client-ksk.pem;passwd=changeit;secure=no">

In seagull logs i see following sequence 1- Send CER 2- Received CEA 3- Send CER

[deruelle]

@coolface88 @brainslog were you able to validate @jehanzebqayyum testing as well ?

[coolface88]

@jehanzebqayyum I am not sure why removing STARTLS relates to this issue. Do u know if StartTLSRequest happens with this legacy code or just netty? because i did not see that request in the tcp dump. It might take some times to read your code but can you please share your tcp dump and execution log so that I can validate. It should include CER/CEA followed by a sequence of TLS encoded messages in the tcp dump.

[deruelle]

@jehanzebqayyum do you think you can help @coolface88 with his questions ? @coolface88 were you able to make progress on that ?

[stephenmontgomery]

Hi Guys, Just checking if any update on this?

[gsaslis]

Hi @stephenmontgomery !

Afraid there's no ongoing work on this front on Telestax side at the moment. We're more than happy to review & accept contributions here though! Would you like to give it a go?

Would you also mind sharing which particular issue you're facing on your side? (RFC 3588 or 6733) and with which other peer (seagull or other) ?