SSL Digestor

From Komodia
Jump to: navigation, search

What is the SSL Digestor

The SSL Digestor is a module that is layered on top Komodia's Redirector and allows the programmer a transparent access to the decrypted SSL data, this is without raising an alert from the brower.

Applications supported

  • The SSL Digestor supports the following browsers:
    • Internet Explorer
    • Safari
    • Chrome
    • Firefox
    • Opera
  • Chat software:
    • The module supports Gmail and Facebook chat decoding.
  • The SSL Digestor supports the following SSL enabled email clients:
    • Outlook
    • Outlook express
    • Winmail
    • Forte agent
    • Becky! internet mail
    • Mailwasher
    • Pocomail
    • Poppeeper
  • The SSL Digestor supports the following SSL enabled applications:
    • iTunes
  • The SSL Digestor does not support the following SSL decrypting resisting applications:
    • Dropbox
    • Google drive
    • Logmein
    • AIM

Applications not in the list

The module may work with unlisted applications that use either the Windows or NSS certificate stores, but that's not officially supported.

How does it work?

The SSL Digestor is a modified Man In The Middle attack, what it does is "talk" with the application on one side, and talking with the target server on the other, and the Redirector being the man in the middle, just as someone who gets a secret whispered in each ear, normally the browser/app would raise an alert because of the modified certificate, but the Komodia's Redirector installs a root CA certificate in advance which means the browser will not send an alert because the certificate created is legit from SSL point of view.

CA Store

A root certificate is installed in a certificate store, currently there are three supported store:

  • Windows which affects: Internet Explorer, Chrome, Safari/iTunes (Apple software require an extra step to make it work), Outlook, Outlook express and Winmail.
  • NSS which affects: Firefox and Thunderbird.
  • Opera

Applications that manages their own store or applications that tries to verify the certificate will raise an alert when the certificate is replaced and will not work with the SSL Digestor (for example Dropbox)

Cert creation

The SSL Digestor tries to copy the certificate as best as possible, one field it can't copy is the generating entity which will be the company name the module is branded to, it will also copy fields that may cause the certificate verification to fail, because if the original site's certificate would fail, the module wants the same affect so it will not cause a security problem. Also the module tries to verify that the certificate is indeed signed by an approved signer, it will use the CA store of the browser used to verify that (for Internet Explorer the Windows store will be used, and for Firefox the NSS store will be used), if the certificate isn't legit, the created certificate will be created in a way it would raise an alert to protect the user.

Cert validation

When you receive the cert from the remote server the SDK will validate the cert with the store of the browser that created the connection, also in Windows 7 IE/Chrome the SDK will try to download root and intermediate certs in real time in order to validate the end cert.

Limitations

Cert checking

Some applications are actively checking that they receive a certificate they expected to receive (they compare it with a binary copy inside the executable) and you will not be able to decrypt their data, those applications should be SSL excluded (known resisting applications are excluded by default), for example: Dropbox, Logmein ActiveX, also officially only the five browsers are supported.

Non HTTPS SSL

SSL/TLS can be used in protocols that are not HTTPS, for example SMTPS and FTPS, which start the secure handshake after they send plaintext, the SSL digestor only supports SSL/TLS decrypting when it start at the first data transfer (such as HTTPS).

Client side certificate

The SDK can't work with sites that require client side cert, what the SDK does is when a site requests client cert, the SDK excludes the entire domain, then the browser can "speak" with the site directly.

Combining SSL Digestor with existing solutions

Some clients have existing solutions that does not support SSL decrypting and want to use Komodia's module, these are the options to do the upgrade:

  • Upgrade the entire product and use Komodia's SDK for both HTTP and HTTPS.
  • Use Komodia's SDK just for port 443, and keep using the existing solution for all other ports, also the existing component must know how to co exist with Komodia's filtering components such as LSP or WFP, because some solutions are written (on purpose or because of bugs) to not work with other solutions.

SSL decryption via proxy

Some of Komodia's clients requested to have the ability to receive the decrypted inside their proxy so there's an optional module that does that. How it works:

  • A connection is made to the Redirector, the SDK checks if it has the certificate for this IP/Port.
  • If it does, it uses the one in cache, if not, it creates a direct connection (not via the proxy) just to get the certificate, once it gets it, it disconnects the session.
  • The Redirector is using the cache it has to communicate with the browser, and it sends the decrypted data to the socks5 proxy of the client.
  • The client's socks5 proxy uses regular SSL when it outputs the data to the original server (the proxy has to encrypt the outbound data)

Alternative methods

It's possible to use detour like functionality to intercept the SSL stream before it's encoded and after it's decrypted but there are limitations to this method:

  1. MS Detours costs 10,000$ at the day of writing this post.
  2. Opera will be almost impossible to detour as it's statically linked with a SSL library.
  3. DLL injection is required (if not using LSP), which will cause alerts from AV software.

The Komodia's SSL Sniffer is based upon detouring technique (using Komodia's proprietary code detour library), but we discontinued this technology.

TLS SNI

TLS SNI is used by the browser (when using TLS) to tell the server the name of the host it wants to use, this is needed for multi homed SSL sites.

Pros:

  • No need to decrypt traffic.

Cons:

  • Doesn't work with IE/Chrome on Windows XP.
  • May not work with ActiveX or Java.
  • Can only get the host and not the full URL.
  • You can't modify the data, just block the connection.
  • Data remains encrypted, this method is used only to extract the host.