[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/master] trivial fixes from earlier readings
commit 5ce6cbbb5f6b2e9f40ccecea0029c82e3fdea61c
Author: Roger Dingledine <arma@xxxxxxxxxxxxxx>
Date: Mon Aug 13 16:11:46 2012 -0400
trivial fixes from earlier readings
---
.../190-shared-secret-bridge-authorization.txt | 8 ++++----
proposals/191-mitm-bridge-detection-resistance.txt | 14 +++++++-------
proposals/203-https-frontend.txt | 4 ++--
proposals/ideas/xxx-port-knocking.txt | 2 +-
4 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/proposals/190-shared-secret-bridge-authorization.txt b/proposals/190-shared-secret-bridge-authorization.txt
index 8683652..e3c2f79 100644
--- a/proposals/190-shared-secret-bridge-authorization.txt
+++ b/proposals/190-shared-secret-bridge-authorization.txt
@@ -7,7 +7,7 @@ Status: Needs-Revision
1. Overview
Proposals 187 and 189 introduced AUTHORIZE and AUTHORIZED cells.
- Their purpose is to make bridge relays scanning resistant against
+ Their purpose is to make bridge relays scanning-resistant against
censoring adversaries capable of probing hosts to observe whether
they speak the Tor protocol.
@@ -58,7 +58,7 @@ Status: Needs-Revision
generating 10 octets of random data using a strong RNG or PRNG.
Tor bridge implementations MUST store the shared secret in
- 'DataDirectory/keys/bridge_auth_ss_key' in hexademical encoding.
+ 'DataDirectory/keys/bridge_auth_ss_key' in hexadecimal encoding.
Tor bridge implementations MUST support the boolean
'BridgeRequireClientSharedSecretAuthorization' configuration file
@@ -73,9 +73,9 @@ Status: Needs-Revision
Tor client implementations must extend their Bridge line format to
support bridge shared secrets. The new format is:
- Bridge <method> <address:port> [["keyid="]<id-fingerprint>] ["shared_secret="<shared_secret>]
+ Bridge [<method>] <address[:port]> [["keyid="]<id-fingerprint>] ["shared_secret="<shared_secret>]
- where <shared_secret> is the bridge shared secret in hexademical
+ where <shared_secret> is the bridge shared secret in hexadecimal
encoding.
Tor clients who use bridges with shared-secret-based client
diff --git a/proposals/191-mitm-bridge-detection-resistance.txt b/proposals/191-mitm-bridge-detection-resistance.txt
index 013d76c..5e9848e 100644
--- a/proposals/191-mitm-bridge-detection-resistance.txt
+++ b/proposals/191-mitm-bridge-detection-resistance.txt
@@ -14,7 +14,7 @@ Status: Open
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
+ will gladly send a VERSIONS or 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
@@ -27,8 +27,8 @@ Status: Open
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
+ A Tor client must detect the MITM attack before he initiates the
+ Tor protocol by sending a VERSIONS or 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
@@ -46,13 +46,13 @@ Status: Open
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
+ fingerprint will be able to detect an MITMing adversary in time.
+ 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
+ does not automatically alleviate 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.
@@ -76,7 +76,7 @@ Status: Open
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
+ address and port, the link certificate fingerprint, and any other
enabled Bridge options, so that bridge operators can easily send it
to their users.
diff --git a/proposals/203-https-frontend.txt b/proposals/203-https-frontend.txt
index 8d3c2e3..26101b3 100644
--- a/proposals/203-https-frontend.txt
+++ b/proposals/203-https-frontend.txt
@@ -39,7 +39,7 @@ Goals and requirements:
HTTPS client talking to an HTTPS server.
We should make it impossible for an active attacker talking to the
- server to tell a Tor bridge server from regular HTTPS server.
+ server to tell a Tor bridge server from a regular HTTPS server.
We should make it impossible for an active attacker who can MITM the
server to learn from the client whether it thought it was connecting
@@ -205,7 +205,7 @@ Some considerations on distinguishability
entirely.)
Against an active non-MITM attacker, the best probing attacks will be
- ones designed to provoke the system in acting in ways different from
+ ones designed to provoke the system into acting in ways different from
those in which a webserver would act: responding earlier than a web
server would respond, or later, or differently. We need to make sure
that, whatever the front-end program is, it answers anything that
diff --git a/proposals/ideas/xxx-port-knocking.txt b/proposals/ideas/xxx-port-knocking.txt
index 85c27ec..bf5afa0 100644
--- a/proposals/ideas/xxx-port-knocking.txt
+++ b/proposals/ideas/xxx-port-knocking.txt
@@ -45,7 +45,7 @@ no longer possible to rebind to those lower ports after they are closed.
Tor does not know about any OS level packet filtering. Currently there is no
packet filters that understands the Tor network in real time.
-1.x Possible partioning of users by bridge operator
+1.x Possible partitioning of users by bridge operator
Depending on implementation, it may be possible for bridge operators to
uniquely identify users. This appears to be a general bridge issue when a
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits