[Deprecated] SSL / TLS Simulators

 

Warning: This documentation is out-dated, newest version of the documentation is available at https://gazelle.ihe.net/gazelle-documentation/Gazelle-Security-Suite/user.html

 

The TLS mode gathers two functionnality : the simulators and the connection testing. While simulators can be used to perform exploratory testing, the connection testing provide a more rigorous environnement where test cases are defined and expect specifics results.

Simulators

The simulator is used to effectively test the establishement of a secured connection. It can simulate both side of a connection : client or server. And those simulators are fully tuneable by the administrator of the tool. Here is some example of parameters :

  • supported protocols
  • supported ciphersuites
  • Client side authentication required or not.
  • Certificate used
  • Trusted certificate authorities
  • Revokation checking

Once the simulators are set up, They can be used by any logged user for testing. Running a client is equivalent to do a "secured" ping on a target, while server is a listening channel for connection attempts.

The TLS simulator rely on a dedicated instance of the Gazelle Proxy to intercept messages. It offers a shortcut to validate the message content with EVSClient tool.

Each time a connection attempt is done, whatever the client side or server side it is, a secured connection summary is recorded and is added to the connection list. It informs users about the security negociation result. A blue circle indicates the negociation has succeed, and a red circle the negociation has failed. Details on this connection can be displayed for a better understanding.

Using clients simulators

To initiate a secured connection with a SUT that act as server, simulated clients can be used. Go to "SSL / TLS" > "Simulators" > "Clients". You will see the list of all available clients. Chose one of them and click on "Start a test". On this new page all TLS parameters for this simulator will be sum up. Verify it adress your needs. Simulated client are not dependent on the application message, so you can select the desired kind of message to send. Here is the list of supported application protocol :

  • DICOM_ECHO
  • HL7
  • WEBSERVICE
  • SYSLOG
  • RAW

Finally input the targeted host and port of your SUT and click on "Start client". The connection attempt will be recorded and displayed below the "Start client" button.

Sometimes connection takes a bit more time than expected and are not immediately displayed. In this case, try to refresh the page.

Using server simulators

Server simulators are permanently listening. To test your SUT acting as a client, you just have to choose one of the availabled and running servers in the list "SSL / TLS" > "Simulators" > "Servers", note its IPaddress (or host) and port and send a message to it with your system. Connections will be recorded, go to "Access logs" or in the "View" page to list them.

In fact, server simulators are just channels that forward the message to a real server. If an answer is expected to your message, pay attention to select a server that forward to a system that can effectively understand the content of your message. It is usually indicated in the keyword of the simulator.

Sometimes connection takes a bit more time than expected and are not immediately displayed. In this case, try to refresh the page.

Secured connection testing

Since EU-CAT 2015, a set of test scenario has been set up to increase the TLS negociation testing part. There is two goals :

  • Make easier the graduation of the Authentication testing for the monitors
  • Perform error case scenarios to stress the system under test and get a better trust level.

For now, only the systems acting as responder (servers) can run these scenarios.

Test cases overview

go to "SSL / TLS" > "Testing" > "Test Cases". You will see the list of available test cases. For each test, a short description presents the goal of the scenario. In the detailed view, all the parameters that will be used during the test and its expected result are summarized.

At the bottom of the page, all the test instances are recorded. You can apply filters on the list to help you to find your results. To view the detail of a test run, click on the magnifying glass.

Run a test

To run a test, you must previously add the IHE Europe CA certificate to your trust-store.

Click on the "Run" button of the test of your choice. The TLS negociation tests are not dependent on the application message, so you can select the desired kind of message to send. Here is the list of supported application protocol :

  • DICOM_ECHO
  • HL7
  • WEBSERVICE
  • SYSLOG
  • RAW

Finally input the targeted host and port of your SUT and click on "Run the test". The test instance will be recorded and displayed below.

Sometimes, the TLS Simulator is not initiated and the test instance is marked "NO RUN". In this case, re-launch the test.

Understand the verdict

The verdict of a test is determined according to 3 sub-verdict : the handshake verdict, the alert level verdict, and the alert description verdict. Some of theses sub-verdict can be declared as optional while the others are required. To be PASSED, a test must have all its required verdict to PASSED.

An optional element wiill not be taken into account to calculate the final test verdict and you can consider this element as a warning. Here is an example, where the alert received was a 'certificate_unknown' :

Example of test instance with an optional expected result FAILED.

In error test cases, the Handshake is usually expected to be FAILED. However it is not the only requirement ! The simulator expect to receive a fatal/warning alert or a close_notify from the targeted system. If the connection is closed without recieving those alert messages, the Handshake verdict will be failed. For more information about ending a TLS negociation and error alerts, see RFC 2246 section 7.2.

Tips

TLS renegociation

Mostly with IIS servers (Microsoft HTTP server), some resources may be protected. So other a single TLS connection, not authenticated at first, the client request a specific resource (like “GET /secret”). Before responding, server starts a renegociation of the connection. This was a cause of several security failures, mostly fixed now with TLSv1. The renegociation asks a certificate to the client for mutual authentication. Even if it is over a single TLS connection, TLS tools record two connections in the logs. The first one is not valid as it is not requesting a certificate, the second one can be valid if it requests for a certificate issued by the CAT certificate authority.

TLS Administration

Simulators

How to create a client

Only one client is needed.

How to create a server

TLS tools must provide one TLS server per protocol. Each server must be started to record connections, on a fixed port accessible from SUTs. TLS server is “dumb” as it can’t provide content to the clients tested. It acts as a proxy to a real server, using an unencrypted connection. For each protocol, an available server must be found. However, it can be simplified as follows :

  • DICOM : OrderManager DICOM server
  • HL7v2 : OrderManager HL7v2 server
  • HTTP, Syslog, Raw : any HTTP server (Gazelle one for simplicity)

How to update server parameters

Once a server it's created, we can only change its connection parameters (listening port, remote host/port)