There are two methods of performing a man-in-the-middle attack on SSL IM connectins. Firstly, with a static certificate:
If enabled, IMSpector will proxy SSL connections, presenting the certificate configured with the ssl_cert and ssl_key options to the client. This will enable it to log SSL/TLS IM sessions, but with the obvious drawback of the wrong certificate being given to the client.
Alternativly a certificate can be created on demand. In this mode IMSpector will create and sign a certificate with the correct Common Name. This certificate will be signed by a CA managed by IMSpector. The public part of this CA can be loaded into client machines, after which the certificate presented by the IM proxy will appear genuine:
Here, the ssl_ca_cert and ssl_ca_key options set the CA certificate and key, whilst the ssl_key option sets the key which all proxied IM clients will receive. The ssl_cert_dir should point at a directory, writeable by the IMSpector user, which will be used to store on-demand created server certificates. The certificates will be created with hashed filenames, and will be valid for one year after the date of creation.
A disadvantage with any form of man-in-the-middle atack, from the point of view of the client, is that the client will be unable to do any validation checks on the server certs. This opens clients up to the possibility of connecting to IM servers which have invalid or expired certificates. The solution to this problem is to do validation on the IM proxy, on the clients behalf. This feature can be used either with on-demand or static MITM certificates, but is more useful if on-demand certs are used.
The ssl_verify_dir option sets the location of system-wide CA certs within the machine running IMSpector. This is the set of certs that is provided with the OpenSSL package, and unfortunately its exact location varies from system to system. The example given above is for Debian derived systems, and within Debian the certs are contained within the ‘ca-certificates’ pacakge. If IMSpector has this list of CAs available, it is able to do its own CA validation, as well as other checks.
There are three actions available for dealing with connections to IM servers who’s certificate fails validation:
- off – No validation. This is the default. All certs created will be signed by the built in CA.
- selfsigned – Certs that fail validation will be presented to the client as self-signed certs, affording the client user the chance to cancel the connection.
- block – Close the connection if validation fails.
Note that these SSL options are global options, but presently only Jabber supports SSL. It does so in two ways:
- The “starttls” command over the normal port, 5222.
- Port 5223, the “old style” SSL port.
IMSpector supports both methods, but obviously an extra redirect firewall rule is needed for port 5223.
IMSpector could easily support SSL for other protocols, but SSL is not very popular with IM providers, with the excpetion of Jabber via Gtalk.