We’ve recently updated our SSLRobot TLS/SSL checking tool with three main changes:

1. It now uses the locally installed root CA certificates (Windows or MacOS) to support servers that use custom in-house generated SSL certificates.
2. The Network section displays detailed information about the operating system’s proxy configuration.
3. It’s free to use with any host name although the extended features such as save, print and email require a license key or an in-app purchase from the Mac App Store.

Item 2) means that SSLRobot can be a useful tool for debugging and verifying proxy settings even if you don’t need to check the SSL/TLS configuration. Just type a host name into SSLRobot and expand the Network section to see the system proxy configuration.

When there’s no proxy settings on a Mac or PC you’ll see something like this in the Network section:

and with a manually configured proxy you’ll see this:

The proxy data fields show how the proxy was configured and in this case that NTLM authentication was used. It also shows if a PAC (proxy auto config) file was used to specify the proxy on a per host basis:

If SSLRobot detects any potential problems it displays a warning, e.g. the WPAD file location could not be found when using proxy auto-detection :

HttpWatch shows a summary of the SSL connections used for HTTPS requests:

While this information is useful, our customers have asked for more detail about certificates, protocol versions and other aspects of the server’s configuration. There are online SSL tools that can do this but tests are often slow and cannot be used to investigate servers on local networks or in test environments.

To address these issues we have developed SSLRobot – a desktop (Mac and PC) based SSL scanning tool that quickly checks secure servers:

The tool highlights possible configuration issues that could compromise the security of a secure web server:

We’ve integrated this tool directly into HttpWatch (version 10.0.56+) so you can start a check from the SSL tab or URL context menu:

If you have a license for the current version of HttpWatch Professional you can request a free license key for SSLRobot by visiting the following page:

https://store.httpwatch.com/free-sslrobot-license/

One of the commonly voiced concerns with previous versions of HttpWatch was that the log file  may record passwords used to log into web based systems. If you looked at the POST tab after logging into a site you would usually be able to find the password in clear text:

HttpWatch 10 for Windows and iOS now includes a feature that will mask out the passwords for most commonly used login pages. It works by looking for form submits where the POST parameter name suggests a password or some other form of sensitive data. Any POST field that meets the matching criteria will have each character of input replaced with an asterisk (*).

For example, here’s the POST Data tab in HttpWatch showing a login to a Google account:

The password characters have been masked out and colored in green. The banner and icon on the tab also confirm that password masking has occurred. The masking also applies at the network level in the Stream tab:

Although the actual password was sent to the web server, HttpWatch only records the masked version of the password in the Stream tab.

The criteria used to select POST fields for masking is based on checking whether a list of sub-strings occur in the name. The default sub-strings of ‘pwd’, ‘pass’, ‘secure’ and ‘secret’ catch passwords on most sites but the list is configurable in Tools->Options:

You could change the list if a password field is not being masked or if you want to turn off the feature completely.

The same masking functionality is built into the POST Data section of the iOS app:

and a new Settings view allows the substrings to be modified:

There are still some security related issues to consider when recording and sharing log files:

1. The password masking feature doesn’t hide the length of the underlying password as it uses a character for character substitution.
2. Cookies used for session management are still recorded in the log file and could be re-used to access the logged in session if they have a long expiration time.
3. Content seen in the logged in session is recorded, e.g. html and images
4. Query string values are recorded but it’s probably  best to not put anything of a security sensitive nature in a URL

However compared to previous versions, the masking of submitted passwords is a significant improvement to security when sharing log files with third parties.