Click to here to enter the Proxy

Project Overview

The proxy is used to capture TCP/IP packets exchanged by test participants. The packed flow is analyzed and stored in a database for further analysis by protocol specific analysers.

The packet analyser availables are :

• HTTP
• DICOM
• HL7V2
• Syslog

Each message is saved with the network details, including an id of the socket (named channel id) used for that message as a socket can transport many messages (HTTP, DICOM).

The proxy is set up on kujira.irisa.fr, and accessed with the web interface. kujira.irisa.fr has a limited range of port numbers available from the Internet. Ports from 10000 to 11000 must be used for channel creation.

Usage

The web interface allows to create channels. A channel opens a port on the server hosting the proxy and redirecting all traffic to a configured server on a specific port.

Data stream is not modified, but analyzed using the chosen packet analyser.

Channel List

This page displays the list of current running channels. A channel can be deleted if password is known.

New channel

It allows to create a new channel if password is known. All fields are required.

Messages list

A grid displays all messages matching provided filter. Reset button sets all fields to default value.

Each row allows to display message details if id is clicked. Network details can also be clicked to define filter values.

For HTTP(S) messages, matching request/response is displayed in parenthesis.

Filter panel is collapsable, to provide more space for grid.

TLS channels

The proxy allows to capture HTTP messages sent over a TLS channel. However, as we are not able to decode encrypted frames (like in a man in the middle attack), the proxy acts as a TLS server and a TLS client.

If the proxy has to be used transparently, clients and servers should not check for the mapping between the ip and the certificate (server : DN = TCP qualified name, client : validation of certificate based on IP).

When a TLS channel is created, a PKCS12 (.p12) file MUST be provided for the TLS server socket. The p12 should contain a private key and certificates. The .p12 MUST be protected by a password, provided in the matching form input.

The server p12 should mimic the real server certificates, as clients could validate the TLS channel against a truststore.

Also, the proxy supports TLS authentication. When a client connects to the proxy, it first connects to the real server without using any certificate. When the TLS channel is open, data from client is forwarded to the server. The server then can ask a renegotiation to the proxy for authentication. The key used is then the p12 provided for client.

At the moment, if the proxy failed to authenticate on server, the source connection is closed without the source error transmitted.

Gazelle integration

The proxy is integrated with Gazelle using web standards.

It publishes a web service allowing Gazelle to send test instance steps and configurations. Also, when a step is done, Gazelle calls the web service.

The proxy then opens the needed channels and listen on specified ports (provided in the system configurations). It also records the test instance chronology for further searches.

In Gazelle, if the test instance has proxy enabled, a link is available on each step. This link opens the proxy with the Gazelle step technical id as a parameter. The proxy then builds a filter to get messages matching the step and displays the matching messages.