torproject/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-12-06 19:41:15 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

other cleanups that have been sitting in my sandbox

Browse Source 
svn:r13649
This commit is contained in:
Roger Dingledine
2008-02-21 09:01:32 +00:00
parent a60f7caa54
commit b3c0d066e5
10 changed files with 33 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/design-paper/blocking.pdf
BIN
View File
Binary file not shown.
doc/design-paper/blocking.tex
+4 -3
View File
@@ -25,7 +25,7 @@
%\newcommand{\workingnote}[1]{(**#1)} % makes the note visible.
\date{}
\title{Design of a blocking-resistant anonymity system}
\title{Design of a blocking-resistant anonymity system\\DRAFT}
%\author{Roger Dingledine\inst{1} \and Nick Mathewson\inst{1}}
\author{Roger Dingledine \\ The Tor Project \\ arma@torproject.org \and
@@ -46,7 +46,8 @@ itself, blocked users can no longer benefit from the security Tor offers.
Here we describe a design that builds upon the current Tor network
to provide an anonymizing network that resists blocking
by government-level attackers.
by government-level attackers. We have implemented and deployed this
design, and talk briefly about early use.
\end{abstract}
@@ -194,7 +195,7 @@ currently~\cite{clayton:pet2006}:
certain strings or patterns in TCP packets. Offending packets can be
dropped, or can trigger a response like closing the
connection.
\item Block a destination by listing its IP address at a
\item Block certain IP addresses or destination ports at a
firewall or other routing control point.
\item Intercept DNS requests and give bogus responses for certain
destination hostnames.
doc/design-paper/roadmap-future.tex
+5 -3
View File
@@ -52,7 +52,7 @@ into Vidalia.
We should add a new option ``auto'' that cycles through a set of preferred
ports, testing bindability and reachability for each of them, and only
complains to the user once it's given up on the common options.
complains to the user once it's given up on the common choices.
\subsection{Incentives design}
@@ -112,8 +112,9 @@ routers can't handle this many connections in their routing table.
One approach is a restricted-route topology~\cite{danezis:pet2003}:
predefine which relays can reach which other relays, and communicate
these restrictions to the clients. We would need to compute which links
are acceptable in a way that's decentralized yet scalable, and we would
these restrictions to the relays and the clients. We need to compute
which links are acceptable in a way that's decentralized yet scalable,
and in a way that achieves a small-worlds property; and we
need an efficient (compact) way to characterize the topology information
so all the users could keep up to date.
@@ -162,6 +163,7 @@ Metrics for deciding when you're fast enough and stable enough
\subsection{Continue Torbutton improvements}
especially better docs
\subsection{Vidalia and stability (especially wrt ongoing Windows problems)}
learn how to get useful crash reports (tracebacks) from Windows users
\subsection{Polipo support on Windows}
\subsection{Auto update for Tor, Vidalia, others}
\subsection{Tor browser bundle for USB and standalone use}
doc/spec/proposals/121-hidden-service-authentication.txt
+16 -15
View File
@@ -42,8 +42,8 @@ Motivation:
The major part of hidden services does not require client authorization
now and won't do so in the future. To the contrary, many clients would
not want to be (pseudonymously) identifiable by the service (which
is unavoidable to some extend), but rather use the service
not want to be (pseudonymously) identifiable by the service (though this
is unavoidable to some extent), but rather use the service
anonymously. These services are not addressed by this proposal.
However, there may be certain services which are intended to be accessed
@@ -93,8 +93,8 @@ Motivation:
previously guaranteed QoS level, thus providing better latency or
bandwidth for selected clients.
As a disadvantage of performing authorization within the Tor network can
be seen that a hidden service cannot make use of authorization data in
A disadvantage of performing authorization within the Tor network is
that a hidden service cannot make use of authorization data in
the transported protocol. Tor hidden services were designed to be
independent of the transported protocol. Therefore it's only possible to
either grant or deny access to the whole service, but not to specific
@@ -120,7 +120,7 @@ Motivation:
Details:
1 General infrastructure for authorization to hidden services
1. General infrastructure for authorization to hidden services
We spotted three possible authorization points in the hidden service
protocol:
@@ -133,7 +133,7 @@ Details:
The general idea of this proposal is to allow service providers to
restrict access to all of these points to authorized clients only.
1.1 Client authorization at directory
1.1. Client authorization at directory
Since the implementation of proposal 114 it is possible to combine a
hidden service descriptor with a so-called descriptor cookie. If done so,
@@ -183,7 +183,7 @@ Details:
(clients and servers would have to be upgraded anyway for using the new
features).
1.2 Client authorization at introduction point
1.2. Client authorization at introduction point
The next possible authorization point after downloading and decrypting
a hidden service descriptor is the introduction point. It is important
@@ -288,7 +288,7 @@ Details:
depending on the version of the contained INTRODUCE2 cell; however, this
approach does not appear very clean.)
1.3 Client authorization at hidden service
1.3. Client authorization at hidden service
The time when a hidden service receives an INTRODUCE2 cell constitutes
the last possible authorization point during the hidden service
@@ -363,7 +363,7 @@ Details:
rendezvous point for 3 times and a total number of 10 connection
establishments (not requests in the transported protocol) per hour.
1.4 Summary of authorization data fields
1.4. Summary of authorization data fields
In summary, the proposed descriptor format and cell formats provide the
following fields for carrying authorization data:
@@ -393,7 +393,7 @@ Details:
cannot be performed without using an encryption schema for introduction
information.
1.5 Managing authorization data at servers and clients
1.5. Managing authorization data at servers and clients
In order to provide authorization data at the hidden server and the
authenticated clients, we propose to use files---either the tor
@@ -407,7 +407,7 @@ Details:
and is also a bad idea, because in case of HTTP the requested URL may be
contained in the Host and Referer fields.
2 An authorization protocol based on group and user passwords
2. An authorization protocol based on group and user passwords
In the following we discuss an authorization protocol for the proposed
authorization architecture that performs authorization at all three
@@ -419,7 +419,7 @@ Details:
derived from the user key will be used for performing authorization at
the introduction and the hidden service.
2.1 Client authorization at directory
2.1. Client authorization at directory
The server creates groups of users that shall be able to access his
service. He provides all users of a certain group with the same group key
@@ -437,7 +437,7 @@ Details:
server decides to remove authorization for a group, he can simply stop
publishing hidden service descriptors using the descriptor cookie.
2.2 Client authorization at introduction point
2.2. Client authorization at introduction point
The idea for authenticating at the introduction point is borrowed from
authorization at the rendezvous point using a rendezvous cookie. A
@@ -496,7 +496,7 @@ Details:
number for the encrypted introduction cookies as well as for
ESTABLISH_INTRO and INTRODUCE1 cells is "1".
2.3 Client authorization at hidden service
2.3. Client authorization at hidden service
Authorization at the hidden service also makes use of the user key,
because whoever is authorized to pass the introduction point shall be
@@ -526,7 +526,7 @@ Details:
connection limit of 10 requests per hour and user that helps prevent some
threats.
2.4 Providing authorization data
2.4. Providing authorization data
The authorization data that needs to be provided by servers consists of
a number of group keys, each having a number of user keys assigned. These
@@ -647,3 +647,4 @@ Compatibility:
changed, so that they understand the new cell versions and perform
authorization. But again, the new introduction points would remain
compatible to the existing hidden service protocol.
src/common/aes.c
+2 -2
View File
@@ -135,9 +135,9 @@ static void rijndaelEncrypt(const u32 rk[/*4*(Nr + 1)*/], int Nr,
/*======================================================================*/
/* Interface to AES code, and counter implementation */
/** Implements an aes counter-mode cipher. */
/** Implements an AES counter-mode cipher. */
struct aes_cnt_cipher {
/** This next element (howevever it's defined) is the AES key. */
/** This next element (however it's defined) is the AES key. */
#if defined(USE_OPENSSL_EVP)
EVP_CIPHER_CTX key;
#elif defined(USE_OPENSSL_AES)
src/common/container.h
+1 -1
View File
@@ -207,7 +207,7 @@ DECLARE_MAP_FNS(digestmap_t, const char *, digestmap_);
#undef DECLARE_MAP_FNS
/** Used to iterate over the key-value pairs in a map <b>map</b> in order.
/** Iterates over the key-value pairs in a map <b>map</b> in order.
* <b>prefix</b> is as for DECLARE_MAP_FNS (i.e., strmap_ or digestmap_).
* The map's keys and values are of type keytype and valtype respectively;
* each iteration assigns them to keyvar and valvar.
src/common/tortls.c
+1 -1
View File
@@ -1306,7 +1306,7 @@ _check_no_tls_errors(const char *fname, int line)
}
/** Return true iff the initial TLS connection at <b>tls</b> did not use a v2
* TLS handshake. Output undefined if the handshake isn't finished. */
* TLS handshake. Output is undefined if the handshake isn't finished. */
int
tor_tls_used_v1_handshake(tor_tls_t *tls)
{
src/or/config.c
+1 -1
View File
@@ -2446,7 +2446,7 @@ options_init(or_options_t *options)
config_init(&options_format, options);
}
/** Set all vars in the configuration object 'options' to their default
/** Set all vars in the configuration object <b>options</b> to their default
* values. */
static void
config_init(config_format_t *fmt, void *options)
src/or/geoip.c
+2 -2
View File
@@ -296,8 +296,8 @@ geoip_get_history_start(void)
/** Helper type: used to sort per-country totals by value. */
typedef struct c_hist_t {
char country[3]; /**< two-leter country code. */
unsigned total; /**< total ips seen in this country. */
char country[3]; /**< Two-letter country code. */
unsigned total; /**< Total IP addresses seen in this country. */
} c_hist_t;
/** Sorting helper: return -1, 1, or 0 based on comparison of two
src/or/routerlist.c
+1 -1
View File
@@ -3939,7 +3939,7 @@ update_consensus_router_descriptor_downloads(time_t now)
log_info(LD_DIR,
"%d router descriptors downloadable. %d delayed; %d present "
"(%d of those were in old_routers); %d would_reject; "
"%d wouldnt_use, %d in progress.",
"%d wouldnt_use; %d in progress.",
smartlist_len(downloadable), n_delayed, n_have, n_in_oldrouters,
n_would_reject, n_wouldnt_use, n_inprogress);