When you first run SniffInet it asks you to create a Connector.

You can view the log data of an existing Connector by entering the exact same three inputs you used to create the Connector, so you can leave this screen and come back to it.

You can have only one Client IP at a time (obviously). If you go to create a new Connector with the same Client IP but different Server info, your only choice is to delete the old Connector and Capture. This is for security reasons.

Connectors exist and continue to log all data anytime a client connects to them, so for security you should delete a Connector when you are finished using it.

Connectors have three fields:

Client IP

The Connector will listen for a client to "come calling" from this IP address

Server IP

Once the Connector gets a "call" from a client, it will in turn call (connect to) a server at this IP address. See the next paragraph about "point" for where to find this in the client.

Server Port

The port the Connector should use when connecting to the server

To "point" your client at the Connector, find the setting in the client that says what server name or IP address to connect to. This is the IP address and port you should enter into the Connector Server settings above. Temporarily change your client to connect to sniffinet.checktls.com on port 1025 instead.

Once you have created a Connector and pointed a client to it, SniffInet will be in the middle sniffing all the traffic between the client and the server and logging it on our system.

After you create a new Connector or open an existing one, you have the following options:

Show Log

Displays the data that the Connector has captured since it was created or last erased.

Download Capture

Sends the data that the Connector has captured since it was created or last erased to your browser as a file you can save.

Erase Capture

Erase all the captured data. This does not delete the Connector, it just clears it so it's ready for new data.

Delete Connector

This removes the Connector from our system, removing the logged data and preventing a client from connecting to it anymore.

SniffInet can capture either binary or text data. Text data is displayed as it would appear on a screen that was magically inserted in the middle of the data stream. Binary data is displayed in a binary-dump format. See SniffInet Full Documentation for examples of the output formats.

Taken from the documentation for cpan IO::Socket::SSL::Intercept

Intercepting SSL connections is useful for analyzing encrypted traffic for security reasons or for testing. It does not break the end-to-end security of SSL, e.g. a properly written client will notice the interception unless you explicitly configure the client to trust your interceptor. Intercepting SSL works the following way:

• Create a new CA certificate, which will be used to sign the cloned certificates. This proxy CA certificate should be trusted by the client, or (a properly written client) will throw error messages or deny the connections because it detected a man in the middle attack. Due to the way the interception works there no support for client side certificates is possible.

  Using openssl such a proxy CA certificate and private key can be created with:

    openssl genrsa -out proxy_key.pem 1024
    openssl req -new -x509 -extensions v3_ca -key proxy_key.pem -out proxy_cert.pem
    # export as PKCS12 for import into browser
    openssl pkcs12 -export -in proxy_cert.pem -inkey proxy_key.pem -out proxy_cert.p12

• Configure client to connect to use intercepting proxy or somehow redirect connections from client to the proxy (e.g. packet filter redirects, ARP or DNS spoofing etc).

• Accept the TCP connection from the client, e.g. don't do any SSL handshakes with the client yet.

• Establish the SSL connection to the server and verify the servers certificate as usually. Then create a new certificate based on the original servers certificate, but signed by your proxy CA. This is the step where IO::Socket::SSL::Intercept helps.

• Upgrade the TCP connection to the client to SSL using the cloned certificate from the server. If the client trusts your proxy CA it will accept the upgrade to SSL.

• Transfer data between client and server. While the connections to client and server are both encrypted with SSL you will read/write the unencrypted data in your proxy application.