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.

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