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

If you previously saved a Connector and have not deleted it, when you start SniffInet you will see your saved settings.

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 Log. This is for security reasons.

Connectors exist and may 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.

Connecting to a Connector:

To use SniffInet, you connect your Client to the SniffInet Connector after you tell the Connector how to connect to the Server.

To create a Connector, find the setting in your 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. Then to use the Connector you temporarily change your client to connect to SniffInet instead of the Server.

Your client should connect to sniffinet.checktls.com port 4023.

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

Connectors have eight options:

Client SSL

The Connector will connect to the Client using SSL. If set, the Client starts as SSL unless SSLSwitch (below) is set, in which case it waits to do SSL until SSLSwitch.

Server SSL

The Connector will connect to the Server using SSL, e.g. port 443 vs port 80. If set, the Server starts as SSL unless SSLSwitch (below) is set, in which case it waits to do SSL until SSLSwitch.

Suppress Log

The Connector will NOT log any information, e.g. any data sent or received. Use this when using SniffInet as a full-time protocol converter, e.g. not when debugging.

Show SSL

Show SSL details for all SSL connections. For example SSL version, ciphers, etc.

HTTP Fixup

The Connector will attempt to "fix up" IP address and protocol mappings. For example changing "listener:port" to "server:port".

SSL Intercept

See "How SSL Intercept" works below.

Cert Fixup

See "How Cert Fixup" works below.

SSL Switch

A regex that tells the Connector when to switch to Server to SSL. If set, neither the Client nor the Server start in SSL mode. For example setting this to "^STARTTLS\r\n" will switch the Connector Client and Server connections to SSL at the right time during an encrypted email test.

Connecting to a Connector:

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.

Update Connector

Save the current screen parameters to the Connector, replacing/updating whatever was there.

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.

SSL Interception (see also TLS Interception is a standard security and hacking process. SniffInet's "SSL Interception" option uses IO::Socket::SSL::Intercept library to do SSL Interception. 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 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.

TLS version 1.3 closes the security hole (see Man-In-The-Middle attacks) that SSL Intercept (above) uses. While this eliminates a weakness in Internet security, it breaks most (all?) DLP (see What is DLP), and other, security systems.

Full-blown MITM solutions do work with TLSv1.3 because they have two separate, independent encrypted connections: A talks to S and S talks to B. But full-blown MITM solutions suffer from a glaring deficinecy: they present the client (A) with a certificate from the MITM (S) and not from the server (B). Therefore, a browser for example, will claim that the site is dangerous and will not let you connect to it.

SniffInet works with TLSv1.3 and can present the server's real certificate.

No, again, SniffInet does not break Internet security. When a client (A) connects through SniffInet to a server (B), SniffInet first gets the server's certificate, removes the CA signature, signs it with a SniffInet CA, and then sends that to the client.

To use SniffInet with a re-signed server certificate requires the client to:

• point SERVERNAME to SniffInet.CheckTLS.com's IP address (165.227.190.238)
  (using DNS or /etc/hosts file)
• use port 4023
• trust Sniffinet's CA (add it to the Trusted Root Store)

And use this Connector:

With these changes, a client browsing to https://TLSv13.securesite.com (rewritten as "https://TLSv13.securesite.com:4023/") will get the correct website with securesite's certificate.