proposals/191-mitm-bridge-detection-resistance.txt

   1 Filename: 191-mitm-bridge-detection-resistance.txt
   2 Title: Bridge Detection Resistance against MITM-capable Adversaries
   3 Author: George Kadianakis
   4 Created: 07 Nov 2011
   5 Status: Open
   6
   7 1. Overview
   8
   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.
  12
  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.
  19
  20    This proposal introduces a way for clients to detect an MITMed SSL
  21    connection, allowing them to protect against the above attack.
  22
  23 2. Motivation
  24
  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.
  29
  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.
  33
  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.
  40
  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.
  45
  46 3. Security implications
  47
  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.
  53
  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.
  59
  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.
  64
  65 4. Tor Implementation
  66
  67 4.1. Certificate fingerprint creation
  68
  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
  73    trailing padding '='.
  74
  75 4.2. Bridge side implementation
  76
  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
  81    to their users.
  82
  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.
  87
  88 4.3. Client side implementation
  89
  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>]
  94
  95    where <fingerprint> is the bridge's SSL certificate fingerprint.
  96
  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
 101
 102 4.4. Implementation prerequisites
 103
 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.
 107
 108    Tor trac ticket #4390 and proposal YYY were created to resolve this
 109    issue.
 110
 111 5. Other ideas
 112
 113 5.1. Certificate tagging using a shared secret
 114
 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.
 119
 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).
 124
 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.
 129
 130    Arguments for this scheme are that it:
 131    a) doesn't need extra bridge credentials apart from the shared secret
 132       of prop190.
 133    b) doesn't need any maintenance in case of certificate expiration.
 134
 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.
 143
 144 6. Discussion
 145
 146 6.1. In section 4.1, why do you truncate the SHA256 output to 12 bytes?!
 147
 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
 152    too much bloat.
 153
 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!
 158
 159 7. Acknowledgements
 160
 161    Thanks to Robert Ransom for his great help and suggestions on
 162    devising this scheme and writing this proposal!
 163