# Silent Certificate Transparency

This document introduces a silent Certificate Transparency monitor design.

## Setting

We consider a setting where one or more trusted _nodes_ request certificates for
a specified list of domain names.  The domain names that a node requests
certificates for may overlap with the domain names of other nodes.  For example,
there may be two distinct nodes that request certificates for a given domain.

    TODO: Add figure.
    Figure 1: A few examples of how trusted nodes may be deployed.

The threat we are worried about is certificate mis-issuance.  Due to considering
a multi-node setting with overlapping domain names, no single node can be aware
of all legitimately issued certificates for the domain names that it manages.

A certificate is considered mis-issued if it contains:

  1. at least one domain name that any of the trusted nodes manage _but without
     any of the trusted nodes requesting that certificate to be issued_, or
  2. at least one subdomain of the domain names that any of the trusted nodes
     manage _unless that subdomain is explicitly specified as out of scope_.

The cause of certificate mis-issuance can vary, ranging from BGP and DNS hijacks
to certificate authorities that are coerced, compromised, or actively malicious.

## Goals and non-scope

The goal is to detect certificate mis-issuance, not to prevent it.  It is out of
scope to detect certificate mis-issuance that happened in the past.  In other
words, if the architecture described herein is put into operation at time `T`,
then any certificate mis-issuance that happened before time `T` is out of scope.

It is also out of scope to detect certificate mis-issuance that targets web
browsers without Certificate Transparency enforcement.  This is because we
cannot get a concise view of all certificates without Certificate Transparency.

To achieve the goal of certificate mis-issuance, we want a _monitor_ that:

  1. _is easy to self-host_, because you trust yourself or can then find someone
     else that is appropriate and willing to host your infrastructure, and
  2. _is silent_, so that there is little or no noise unless certificate
     mis-issuance is suspected or other noteworthy log events are happening.

## Assumptions

  - The attacker is unable to control two independent logs that count towards
    the SCT checks in web browsers.  So, we need not worry about split-views and
    can just download the logs while verifying that they are locally consistent.
  - The nodes that request certificates start in good states but may be
    compromised sometime in the future.  Detection of certificate mis-issuance
    is then out of scope for all domains that the compromised nodes managed.
  - A mis-issued certificate will only be used to target connections from a
    fixed set of IP addresses.  Any party that can distinguish between
    certificates that are legitimate and mis-issued will never be targeted.
  - A domain owner notices alerts about suspected certificate mis-issuance.  The
    monitor that generates these alerts is trusted and never compromised.

## Architecture

A monitor downloads all certificates that are issued by certificate authorities
from Certificate Transparency logs.  The exact logs to download is automatically
updated using a list that Google publishes in signed form.  All historical
updates to the list of logs is stored locally in case any issues are suspected.

To filter out certificates that are not relevant, the monitor is configured with
a list of domains to match on.  Only matching certificates will be stored, which
means there are nearly no storage requirements to run this type of monitor.

To get the property of _silence_, the monitor pulls the trusted nodes
periodically (HTTP GET) for legitimately issued certificates.  The monitor will
use this feedback to filter the downloaded certificates that matched.  If any
certificates are found that no node pushed to the monitor, an alert is created.

The communication channel between the trusted nodes and the monitor can be
tampered with.  For example, it may be plain HTTP or an HTTPS connection that
the attacker trivially hijacks by obtaining yet another mis-issued certificate.
Owning that the communication channel is insecure helps avoid misconfiguration.

A pre-shared secret is used for each node to authenticate with the monitor.
That secret is never shown on the wire (an HMAC key is derived from it), which
means that all a man-in-the-middle attacker can do is replay and block messages.
"Replays" can happen either way because the monitor polls periodically, i.e.,
the monitor needs to account for the fact that it may poll the same thing twice.
Blocking can not be solved by cryptography and would simply result in alerts.

## Further documentation

docdoc

## Future ideas

  - Reduce the amount of bandwidth that the monitor spends downloading
    certificates that are either way discarded (non-matches).  This can be
    achieved by introducing a _verifiable proxy_ supporting wildcard
    (non-)membership proofs, see [verifiable light-weight monitoring][].  Ignore
    the parts about changing the logs; that is easily solved by the proxy alone.

[verifiable light-weight monitoring]: https://arxiv.org/pdf/1711.03952.pdf