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
|
# 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.
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.
(It is possible to get INFO output whenever logs are added and removed. The
default verbosity is however NOTICE, which aims to be as silent as possible.)
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 via HTTP
GET for legitimately issued certificates (periodic job). 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 printed.
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 shared secret is used for each node to authenticate with the monitor. This
secret is never shown on the wire: an HMAC key is derived from it, which is used
to produce message authentication codes. All a machine-in-the-middle attacker
can do is replay or block integrity-protected submissions that a node generated.
"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 reading
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
|
