Over the past month I have audited the TLS/SSL deployments of half a dozen small operators — friends, friends of friends, a couple of formal engagements. The findings are largely consistent across the audits.
This post is a sanitised summary of what I found and what it teaches about the current state of HTTPS deployment.
The audit method
For each operator I:
- Used a small set of tools to probe the publicly-reachable endpoints (essentially
openssl s_clientplus some custom checks). - Reviewed the server configuration (with permission) for cipher suites, certificate setup, and supporting services.
- Examined the certificate chain for completeness and validity.
- Tested the application for HTTPS-specific issues (mixed content, cookie scoping, redirect behaviour).
- Wrote up findings with severity ratings and recommendations.
The whole thing was about a day per audit. The findings cluster around a small number of patterns.
The common findings
In rough order of frequency.
SSL 2.0 still enabled. All six operators had SSL 2.0 enabled on their TLS endpoints, despite SSL 2.0 having known weaknesses for years. The fix is one configuration directive (SSLProtocol -SSLv2 for Apache mod_ssl). Most operators were unaware that the protocol was still negotiable.
Weak cipher suites permitted. Five of six had 40-bit or 56-bit DES cipher suites in their permitted list. These are below the level of strength a modern operator should require. The fix is to restrict the cipher suite to 128-bit-and-stronger options.
Certificate chain delivery incomplete. Four of six were sending only the leaf certificate, not the intermediate chain. Browsers handled this correctly most of the time but produced warnings for some clients. The fix is to configure the server with the full chain.
Mixed content on HTTPS pages. Three of six had HTTPS pages that loaded resources (images, scripts) over HTTP. The browser security model is degraded by this; most browsers warn but the user experience is bad. The fix is to ensure all resources are served over HTTPS or are local.
Cookie scoping issues. Three of six set session cookies without the Secure flag, meaning the cookie would be sent over HTTP if the user navigated there. Two of three would, on examination, have produced credential leaks under specific session-management patterns. The fix is to set Secure on session cookies.
Logging exposes sensitive URLs. Two of six logged full URLs including query parameters, in some cases including credentials passed via URL. The fix is to scrub sensitive parameters before logging or to never put credentials in URLs in the first place.
HSTS not implemented. None of the six had any form of HSTS-like header. This is partly because HSTS as a formal standard is not yet widely deployed; the equivalent functionality (forcing HTTPS for known users) has been technically possible for some time. The fix is to implement appropriate redirect-and-cache behaviour.
What the findings have in common
Three observations.
The bugs are mostly default-configuration. Most of the issues are produced by the default configuration of widely-used software. Apache mod_ssl ships with SSL 2.0 enabled, weak ciphers permitted, and no specific cookie-flag enforcement. Operators have to actively change defaults to get sensible posture.
The fixes are documented but obscure. Each fix has a one-line answer in the right Apache or mod_ssl manual section. None of them are difficult; all of them are non-obvious. The discoverability of the right configuration is the bottleneck.
The audit cost was modest. A day per operator, mostly running well-known commands. The cost-benefit favours regular external auditing for any operator running a non-trivial TLS deployment.
What this implies
The broader observation: TLS deployment quality is a separate dimension from TLS deployment presence. An operator who has TLS configured may have all of the issues above; the configuration is non-trivial to get right; the gap between "HTTPS is on" and "HTTPS is correctly deployed" is wider than most operators appreciate.
For my own work: I have produced a short configuration template for mod_ssl that addresses the common findings. Friends asking about HTTPS deployment now get the template plus a recommendation to run the same audit checks I have been running.
For the broader recommendation: any operator running TLS for non-trivial use cases should commission an audit at least annually. The cost is modest; the benefit is real.
A small note on the changing baseline
Three years ago, the right advice was "deploy HTTPS". Today, the advice is more nuanced: deploy HTTPS, configure it correctly, audit it periodically, fix the issues the audit finds.
The deployment baseline keeps moving. Each thing that used to be the leading edge becomes the new minimum. By 2003 I expect we will be discussing things like forward secrecy as a baseline expectation rather than a sophisticated extra. The operational discipline for an internet-facing service has, structurally, increased.
More as the year develops.