commit d329528c3942727c591ba8bb9100d5d65a50fd8a Author: Nick Mathewson nickm@torproject.org Date: Thu Dec 1 09:42:38 2011 -0500

Add proposal 191 and 192 --- proposals/000-index.txt | 4 + proposals/191-mitm-bridge-detection-resistance.txt | 114 ++++++++++++++++ proposals/192-store-bridge-information.txt | 137 ++++++++++++++++++++ 3 files changed, 255 insertions(+), 0 deletions(-)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 68ce0b2..950bc38 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -111,6 +111,8 @@ Proposals by number: 188 Bridge Guards and other anti-enumeration defenses [OPEN] 189 AUTHORIZE and AUTHORIZED cells [OPEN] 190 Password-based Bridge Client Authorization [OPEN] +191 Bridge Detection Resistance against MITM-capable Adversaries [OPEN] +192 Automatically retrieve and store information about bridges [OPEN]

Proposals by status: @@ -144,6 +146,8 @@ Proposals by status: 188 Bridge Guards and other anti-enumeration defenses 189 AUTHORIZE and AUTHORIZED cells 190 Password-based Bridge Client Authorization + 191 Bridge Detection Resistance against MITM-capable Adversaries + 192 Automatically retrieve and store information about bridges [for 0.2.[45].x] ACCEPTED: 110 Avoiding infinite length circuits [for 0.2.3.x] [in 0.2.1.3-alpha] 117 IPv6 exits [for 0.2.3.x] diff --git a/proposals/191-mitm-bridge-detection-resistance.txt b/proposals/191-mitm-bridge-detection-resistance.txt new file mode 100644 index 0000000..7709ae8 --- /dev/null +++ b/proposals/191-mitm-bridge-detection-resistance.txt @@ -0,0 +1,114 @@ +Filename: 191-mitm-bridge-detection-resistance.txt +Title: Bridge Detection Resistance against MITM-capable Adversaries +Author: George Kadianakis +Created: 07 Nov 2011 +Status: Open + +1. Overview + + Proposals 187, 189 and 190 make the first steps toward scanning + resistant bridges. They attempt to block attacks from censoring + adversaries who provoke bridges into speaking the Tor protocol. + + An attack vector that hasn't been explored in those previous + proposals is that of an adversary capable of performing Man In The + Middle attacks to Tor clients. At the moment, Tor clients using the + v3 link protocol have no way to detect such an MITM attack, and + will gladly send an VERSIONS or an AUTHORIZE cell to the MITMed + connection, thereby revealing the Tor protocol and thus the bridge. + + This proposal introduces a way for clients to detect an MITMed SSL + connection, allowing them to protect against the above attack. + +2. Motivation + + When the v3 link handshake protocol is performed, Tor's SSL + handshake is performed with the server sending a self-signed + certificate and the client blindly accepting it. This allows the + adversary to perform an MITM attack. + + A Tor client must detect the MITM attack before he initializes the + Tor protocol by sending a VERSIONS or an AUTHORIZE cell. A good + moment to detect such an MITM attack is during the SSL handshake. + + To achieve that, bridge operators provide their bridge users with a + hash digest of the public-key certificate their bridge is using for + SSL. Bridge clients store that hash digest locally and associate it + with that specific bridge. Bridge clients who have "pinned" a + bridge to a certificate "fingerprint" can thereafter validate that + their SSL connection peer is the intended bridge. + + Of course, the hash digest must be provided to users out-of-band + and before the actual SSL handshake. Usually, the bridge operator + gives the hash digest to her bridge users along with the rest of + the bridge credentials, like the bridge's address and port. + +3. Security implications + + Bridge clients who have pinned a bridge to a certificate + fingerprint will be able to detect an MITMing adversary in timely + fashion. If after detection they act as an innocuous Internet + client, they can successfully remove suspicion from the SSL + connection and subvert bridge detection. + + Pinning a certificate fingerprint and detecting an MITMing attacker + does not automatically aleviate suspicions from the bridge or the + client. Clients must have a behavior to follow after detecting the + MITM attack so that they look like innocent Netizens. This proposal + does not try to specify such a behavior. + + Implementation and use of this scheme does not render bridges and + clients immune to scanning or DPI attacks. This scheme should be + used along with bridge client authorization schemes like the ones + detailed in proposal 190. + +4. Tor Implementation + +4.1. Certificate fingerprint creation + + The certificate fingerprints used on this scheme MUST be computed + by applying the SHA256 cryptographic hash function upon the ASN.1 + DER encoding of a public-key certificate. + +4.2. Bridge side implementation + + Tor bridge implementations SHOULD provide a command line option + that exports a fully equipped Bridge line containing the bridge + address and port, the link certificate fingerprint and any other + enabled Bridge options, so that bridge operators can easily send it + to their users. + + In the case of expiring SSL certificates, Tor bridge + implementations SHOULD warn the bridge operator a sensible amount + of time before the expiration, so that she can warn her clients and + potentially rotate the certificate herself. + +4.3. Client side implementation + + Tor client implementations MUST extend their Bridge line format to + support bridge SSL certificate fingerprints. The new format is: + Bridge <method> address:port [["keyid="]<id-fingerprint>] \ + ["shared_secret="<shared_secret>] ["link_cert_fpr="<fingerprint>] + + where <fingerprint> is the bridge's SSL certificate fingerprint in + hexademical encoding. + + Tor clients who use bridges and want to pin their SSL certificates + must specify the bridge's SSL certificate fingerprint as in: + Bridge 12.34.56.78 shared_secret=934caff420aa7852b855 \ + link_cert_fpr=38b0712e90bed729df81f2a22811d3dd89e91406d2522f4482ae4079e5245187 + +4.4. Implementation prerequisites + + Tor bridges currently rotate their SSL certificates every 2 + hours. This not only acts as a fingerprint for the bridges, but it + also acts as a blocker for this proposal. + + Tor trac ticket #4390 and proposal YYY were created to resolve this + issue. + +5. Acknowledgements + + Thanks to Robert Ransom for his great help and suggestions on + devising this scheme and writing this proposal! + diff --git a/proposals/192-store-bridge-information.txt b/proposals/192-store-bridge-information.txt new file mode 100644 index 0000000..09ecc5a --- /dev/null +++ b/proposals/192-store-bridge-information.txt @@ -0,0 +1,137 @@ +Filename: 192-store-bridge-information.txt +Title: Automatically retrieve and store information about bridges +Author: Sebastian Hahn +Created: 16-Nov-2011 +Status: Open +Target: 0.2.[45].x + +Overview: +Currently, tor already stores some information about the bridges it is +configured to use locally, but doesn't make great use of the stored +data. This data is the Tor configuration information about the bridge +(IP address, port, and optionally fingerprint) and the bridge descriptor +which gets stored along with the other descriptors a Tor client fetches, +as well as an "EntryGuard" line in the state file. That line includes +the Tor version we used to add the bridge, and a slightly randomized +timestamp (up to a month in the past of the real date). The descriptor +data also includes some more accurate timestamps about when the +descriptor was fetched. + +The information we give out about bridges via bridgedb currently only +includes the IP address and port, because giving out the fingerprint as +well might mean that Tor clients make direct connections to the bridge +authority, since we didn't design Tor's UpdateBridgesFromAuthority +behaviour correctly. + +Motivation: + +The only way to let Tor know about a change affecting the bridge (IP +address or port change) is to either ask the bridge authority directly, +or reconfigure Tor. The former requires making a non-anonymized direct +connection to the bridge authority Tonga and asking it for the current +descriptor of the bridge with a given fingerprint - this is unsafe and +also requires prior knowledge of the fingerprint. The latter requires +user intervention, first to learn that there was an update and second to +actually teach Tor about the change. + +This is way too complicated for most users, and should be unnecessary +while the user has at least one bridge that remains working: Tonga can +give out bridge descriptors when asked for the descriptor for a certain +fingerprint, and Tor clients learn the fingerprint either from their +torrc file or from the first connection they make to a bridge. + +For some users, however, this option is not what they want: They might +use private bridges or have special security concerns, which would make +them want to connect to the IP addresses specified in their +configuration only, and not tell Tonga about the set of bridges they +know about, even through a Tor circuit. Also see +https://blog.torproject.org/blog/different-ways-use-bridge for more +information about the different types of bridge users. + +Design: + +Tor should provide a new configuration option that allows bridge users +to indicate that they wish to contact Tonga anonymously and learn about +updates for the bridges that they know about, but can't currently reach. +Once those updates have been received, the clients would then hold on to +the new information in their state file, and use it across restarts for +connection attempts. + +The option UpdateBridgesFromAuthority should be removed or recycled for +this purpose, as it is currently dangerous to set (it makes direct +connections to the bridge authority, thus leaking that a user is about +to use bridges). Recycling the option is probably the better choice, +because current users of the option get a surprising and never useful +behaviour. On the other hand, users who downgrade their Tors might get +the old behaviour by accident. + +If configured with this option, tor would make an anonymized connection +to Tonga to ask for the descriptors of bridges that it cannot currently +connect to, once every few hours. Making more frequent requests would +likely not help, as bridge information doesn't typically change that +frequently, and may overload Tonga. + +This information needs to be stored in the state file: + +- An exact copy of the Bridge stanza in the torrc file, so that tor can + detect when the bridge is unconfigured/the configuration is changed + +- The IP address, port, and fingerprint we last used when making a + successful connection to the bridge, if this differs from/supplements + the configured data. + +- The IP address, port, and fingerprint we learned from the bridge + authority, if this differs from both the configured data and the data + we used for the last successful connection. + +We don't store more data in the state file to avoid leaking too much if +the state file falls into the hands of an adversary. + +Security implications: + +Storing sensitive data on disk is risky when the computer one uses gets +into the wrong hands, and state file entries can be used to identify +times the user was online. This is already a problem for the Bridge +lines in a user's configuration file, but by storing more information +about bridges some timings can be deduced. + +Another risk is that this allows long-term tracking of users when the +set of bridges a user knows about is known to the attacker, and the set +is unique. This is not very hard to achieve for bridgedb, as users +typically make requests to it non-anomymized and bridgedb can +selectively pick bridges to report. By combining the data about +descriptor fetches on Tonga and this fingerprint, a usage pattern can be +established. Also, bridgedb could give out a made-up fingerprint to a +user that requested bridges, thus easily creating a unique set. + +Users of private bridges should not set this option, as it will leak the +fingerprints of their bridges to Tonga. This is not a huge concern, as +Tonga doesn't know about those descriptors, but private bridge users +will likely want to avoid leaking the existence of their bridge. We +might want to figure out a way to indicate that a bridge is private on +the Bridge line in the configuration, so fetching the descriptor from +Tonga is disabled for those automatically. This warrants more discussion +to find a solution that doesn't require bridge users to understand the +trade-offs of setting a configuration option. + +One idea is to indicate that a bridge is private by a special flag in +its bridge descriptor, so clients can avoid leaking those to the bridge +authority automatically. Also, Bridge lines for private bridges +shouldn't include the fingerprint so that users don't accidentally leak +the fingerprint to the bridge authority before they have talked to the +bridge. + +Specification: + +No change/addition to the current specification is necessary, as the +data that gets stored at clients is not covered by the specification. +This document is supposed to serve as a basis for discussion and to +provide hints for implementors. + +Compatibility: + +Tonga is already set up to send out descriptors requested by clients, so +the bridge authority side doesn't need any changes. The new +configuration options governing the behaviour of Tor would be +incompatible with previous versions, so the torrc needs to be adapted. +The state file changes should not affect older versions.