[tor-commits] [torspec/master] Add proposal 191 and 192
nickm at torproject.org
nickm at torproject.org
Thu Dec 1 14:39:53 UTC 2011
commit d329528c3942727c591ba8bb9100d5d65a50fd8a
Author: Nick Mathewson <nickm at 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.
More information about the tor-commits
mailing list