SecurityEngineering/TLS Error Reports
Firefox collects TLS Error Reports from users that opt-in when they reach a secure connection interstitial. We can use these reports to help make better security decisions for Firefox.
Contents
Background
Historical Feature Page: Security/Features/SSL Error Reporting
Analyzing TLS Error Reports with ATMO
To get at the TLS reports, use ATMO to spin up a new Spark cluster. The actual use of Spark / ATMO is better covered in Telemetry/Custom analysis with spark, but below are specifics for TLS Error Report data.
Getting Started
From within Spark (started with pyspark
), you need to interact with the "sslreports" dataset:
from moztelemetry.dataset import Dataset ssl_reports = Dataset.from_source("sslreports") \ .where(submissionDate=lambda xx: xx.startswith("201702")) \ .records(sc, sample=0.01)
Note that you'll want to filter for submission dates per your requirements, and you'll often want to use a sample rate < 1, as we receive a lot of error reports each day, and they are larger than average telemetry.
Schema
ping['meta'] = { hostname, port, timestamp, errorCode, // From NSS' errors failedCertChain, // DER-encoded without PEM blocks userAgent, // protocolHandler.userAgent, version, // 1 build, // Services.appinfo.appBuildID, product, // Services.appinfo.name, channel, // UpdateUtils.UpdateChannel }
(See securityreporter/SecurityReporter.js)
The meta structure has an errorCode field that can pick out particular connection errors. For example, to filter down to SEC_ERROR_UNKNOWN_ISSUER:
unknown_issuer_reports = ssl_reports.filter(lambda y: y['meta']['errorCode'] == -8179.0)
Sample Bias
Like Telemetry, but independent of it, these reports are opt-in. The data returned is thus inherently noisy.
Examples
Here's a procedure to obtain all the certificates that provoked SEC_ERROR_UNKNOWN_ISSUER: https://gist.github.com/jcjones/535b5672d075910fdce4f55b9ce57ef7