1 Filename: 191-mitm-bridge-detection-resistance.txt
2 Title: Bridge Detection Resistance against MITM-capable Adversaries
3 Author: George Kadianakis
9 Proposals 187, 189 and 190 make the first steps toward scanning
10 resistant bridges. They attempt to block attacks from censoring
11 adversaries who provoke bridges into speaking the Tor protocol.
13 An attack vector that hasn't been explored in those previous
14 proposals is that of an adversary capable of performing Man In The
15 Middle attacks to Tor clients. At the moment, Tor clients using the
16 v3 link protocol have no way to detect such an MITM attack, and
17 will gladly send a VERSIONS or AUTHORIZE cell to the MITMed
18 connection, thereby revealing the Tor protocol and thus the bridge.
20 This proposal introduces a way for clients to detect an MITMed SSL
21 connection, allowing them to protect against the above attack.
25 When the v3 link handshake protocol is performed, Tor's SSL
26 handshake is performed with the server sending a self-signed
27 certificate and the client blindly accepting it. This allows the
28 adversary to perform an MITM attack.
30 A Tor client must detect the MITM attack before he initiates the
31 Tor protocol by sending a VERSIONS or AUTHORIZE cell. A good
32 moment to detect such an MITM attack is during the SSL handshake.
34 To achieve that, bridge operators provide their bridge users with a
35 hash digest of the public-key certificate their bridge is using for
36 SSL. Bridge clients store that hash digest locally and associate it
37 with that specific bridge. Bridge clients who have "pinned" a
38 bridge to a certificate "fingerprint" can thereafter validate that
39 their SSL connection peer is the intended bridge.
41 Of course, the hash digest must be provided to users out-of-band
42 and before the actual SSL handshake. Usually, the bridge operator
43 gives the hash digest to her bridge users along with the rest of
44 the bridge credentials, like the bridge's address and port.
46 3. Security implications
48 Bridge clients who have pinned a bridge to a certificate
49 fingerprint will be able to detect an MITMing adversary in time.
50 If after detection they act as an innocuous Internet
51 client, they can successfully remove suspicion from the SSL
52 connection and subvert bridge detection.
54 Pinning a certificate fingerprint and detecting an MITMing attacker
55 does not automatically alleviate suspicions from the bridge or the
56 client. Clients must have a behavior to follow after detecting the
57 MITM attack so that they look like innocent Netizens. This proposal
58 does not try to specify such a behavior.
60 Implementation and use of this scheme does not render bridges and
61 clients immune to scanning or DPI attacks. This scheme should be
62 used along with bridge client authorization schemes like the ones
63 detailed in proposal 190.
67 4.1. Certificate fingerprint creation
69 The certificate fingerprints used on this scheme MUST be computed
70 by applying the SHA256 cryptographic hash function upon the ASN.1
71 DER encoding of a public-key certificate, then truncating the hash
72 output to 12 bytes, encoding it to RFC4648 Base32 and omitting any
75 4.2. Bridge side implementation
77 Tor bridge implementations SHOULD provide a command line option
78 that exports a fully equipped Bridge line containing the bridge
79 address and port, the link certificate fingerprint, and any other
80 enabled Bridge options, so that bridge operators can easily send it
83 In the case of expiring SSL certificates, Tor bridge
84 implementations SHOULD warn the bridge operator a sensible amount
85 of time before the expiration, so that she can warn her clients and
86 potentially rotate the certificate herself.
88 4.3. Client side implementation
90 Tor client implementations MUST extend their Bridge line format to
91 support bridge SSL certificate fingerprints. The new format is:
92 Bridge <method> <address:port> [["keyid="]<id-fingerprint>] \
93 ["shared_secret="<shared_secret>] ["link_cert_fpr="<fingerprint>]
95 where <fingerprint> is the bridge's SSL certificate fingerprint.
97 Tor clients who use bridges and want to pin their SSL certificates
98 must specify the bridge's SSL certificate fingerprint as in:
99 Bridge 12.34.56.78 shared_secret=934caff420aa7852b855 \
100 link_cert_fpr=GM4GEMBXGEZGKOJQMJSWINZSHFSGMOBRMYZGCMQ
102 4.4. Implementation prerequisites
104 Tor bridges currently rotate their SSL certificates every 2
105 hours. This not only acts as a fingerprint for the bridges, but it
106 also acts as a blocker for this proposal.
108 Tor trac ticket #4390 and proposal YYY were created to resolve this
113 5.1. Certificate tagging using a shared secret
115 Another idea worth considering is having the bridge use the shared
116 secret from proposal 190 to embed a "secret message" on her
117 certificate, which could only be understood by a client who knows
118 that shared secret, essentially authenticating the bridge.
120 Specifically, the bridge would "tag" the Serial Number (or any
121 other covert field) of her certificate with the (potentially
122 truncated) HMAC of her link public key, using the shared secret of
123 proposal 190 as the key: HMAC(shared_secret, link_public_key).
125 A client knowing the shared secret would be able to verify the
126 'link_public_key' and authenticate the bridge, and since the Serial
127 Number field is usually composed of random bytes a probing attacker
128 would not notice the "tagging" of the certificate.
130 Arguments for this scheme are that it:
131 a) doesn't need extra bridge credentials apart from the shared secret
133 b) doesn't need any maintenance in case of certificate expiration.
135 Arguments against this scheme are:
136 a) In the case of self-signed certificates, OpenSSL creates an
137 8-bytes random Serial number, and we would probably need
138 something more than 8-bytes to tag. There are not many other
139 covert fields in SSL certificates mutable by vanilla OpenSSL.
140 b) It complicates the scheme, and if not implemented and researched
141 wisely it might also make it fingerprintable.
142 c) We most probably won't be able to tag CA-signed certificates.
146 6.1. In section 4.1, why do you truncate the SHA256 output to 12 bytes?!
148 Bridge credentials are frequently propagated by word of mouth or
149 are physically written down, which renders the occult Base64
150 encoding unsatisfactory. The 104 characters Base32 encoding or the
151 64 characters hex representation of the SHA256 output would also be
154 By truncating the SHA256 output to 12 bytes and encoding it with
155 Base32, we get 39 characters of readable and easy to transcribe
156 output, and sufficient security. Finally, dividing '39' by the
157 golden ratio gives us about 24.10!
161 Thanks to Robert Ransom for his great help and suggestions on
162 devising this scheme and writing this proposal!