1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
|
# 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 achieve the property of _silence_, the trusted nodes push legitimately issued
certificates to the monitor which listens for such requests using an HTTP API.
The monitor will use the feedback from these nodes to further filter the
downloaded certificates that matched based on which ones are legitimate. 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.
Accounting for replayed messages is either way a good thing, because it makes it
easy to overcome temporary issues like a spotty network, a monitor reboot, etc.
In other words, nodes can periodically (re)submit their legitimate certificates.
Blocked messages can not be solved by cryptography and will result in alerts.
To keep the attack surface of the monitor down, one may optionally choose to
operate it as a Tor onion service, restrict access using WireGuard, or similar.
Or in the case of a single-node deployment, run everything on the same system.
## Open questions
- What do we do about certificates that appear in the logs after time `T`, but
which were issued with a `NotBefore` timestamp that is before time `T`? We
want to minimize noise, but also not open up for CA backdating threats.
- What options for generating alerts should be supported other than stdout, if
any? Most deployments already have ways to integrate with dashboards/email.
## Further documentation
- [HTTP API](./http-api.md): read more about how the trusted nodes
authenticate with the monitor to submit legitimately issued certificates.
- [State directory](./state.md): read more about how the trusted monitor keeps
track of its state as plaintext files in a given directory. Staying away
from a database is meant to ease debugging, silencing of alerts, etc.
## 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
|
