aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat
-rw-r--r--control-spec.txt131
-rw-r--r--dir-spec.txt12
-rw-r--r--proposals/000-index.txt10
-rw-r--r--proposals/304-socks5-extending-hs-error-codes.txt2
-rw-r--r--proposals/308-counter-galois-onion.txt12
-rw-r--r--proposals/309-optimistic-socks-in-tor.txt78
-rw-r--r--rend-spec-v3.txt10
-rw-r--r--socks-extensions.txt4
8 files changed, 208 insertions, 51 deletions
diff --git a/control-spec.txt b/control-spec.txt
index ab164ea..11f62ba 100644
--- a/control-spec.txt
+++ b/control-spec.txt
@@ -811,6 +811,7 @@
if unknown
"dir/status-vote/current/consensus" [added in Tor 0.2.1.6-alpha]
+ "dir/status-vote/current/consensus-microdesc" [added in Tor 0.4.3.1-alpha]
"dir/status/authority"
"dir/status/fp/<F>"
"dir/status/fp/<F1>+<F2>+<F3>"
@@ -1604,17 +1605,18 @@
KeyType =
"NEW" / ; The server should generate a key of algorithm KeyBlob
"RSA1024" / ; The server should use the 1024 bit RSA key provided
- in as KeyBlob
+ in as KeyBlob (v2).
"ED25519-V3"; The server should use the ed25519 v3 key provided in as
- KeyBlob
+ KeyBlob (v3).
KeyBlob =
"BEST" / ; The server should generate a key using the "best"
- supported algorithm (KeyType == "NEW")
+ supported algorithm (KeyType == "NEW").
+ [As of 0.4.2.3-alpha, ED25519-V3 is used]
"RSA1024" / ; The server should generate a 1024 bit RSA key
- (KeyType == "NEW")
+ (KeyType == "NEW") (v2).
"ED25519-V3"; The server should generate an ed25519 private key
- (KeyType == "NEW")
+ (KeyType == "NEW") (v3).
String ; A serialized private key (without whitespace)
Flag =
@@ -1623,7 +1625,7 @@
"Detach" / ; Do not associate the newly created Onion Service
to the current control connection.
"BasicAuth" / ; Client authorization is required using the "basic"
- method.
+ method (v2 only).
"NonAnonymous" /; Add a non-anonymous Single Onion Service. Tor
checks this flag matches its configured hidden
service anonymity mode.
@@ -1641,10 +1643,10 @@
optional HiddenServicePort "TARGET" argument).
ClientName = An identifier 1 to 16 characters long, using only
- characters in A-Za-z0-9+-_ (no spaces).
+ characters in A-Za-z0-9+-_ (no spaces) (v2 only).
ClientBlob = Authorization data for the client, in an opaque format
- specific to the authorization method.
+ specific to the authorization method (v2 only).
The server reply format is:
"250-ServiceID=" ServiceID CRLF
@@ -1667,11 +1669,11 @@
way to recreate the generated keypair and the corresponding Onion
Service at a later date).
- If client authorization is enabled using the "BasicAuth" flag, the
- service will not be accessible to clients without valid authorization
- data (configured with the "HidServAuth" option). The list of authorized
- clients is specified with one or more "ClientAuth" parameters. If
- "ClientBlob" is not specified for a client, a new credential will be
+ If client authorization is enabled using the "BasicAuth" flag (which is v2
+ only), the service will not be accessible to clients without valid
+ authorization data (configured with the "HidServAuth" option). The list of
+ authorized clients is specified with one or more "ClientAuth" parameters.
+ If "ClientBlob" is not specified for a client, a new credential will be
randomly generated and returned.
Tor instances can either be in anonymous hidden service mode, or
@@ -1709,13 +1711,9 @@
PRF secret, and just pay the cost of recomputing the public key when
importing an ED25519-V3 key.]
- (The "NEW:BEST" option obeys the HiddenServiceVersion torrc option default
- value. Since 0.3.5.1-alpha, it is 3. For Tor versions before 0.3.5.1-alpha,
- default HiddenServiceVersion is 2.)
-
Examples:
C: ADD_ONION NEW:BEST Flags=DiscardPK Port=80
- S: 250-ServiceID=exampleonion1234
+ S: 250-ServiceID=exampleoniont2pqglbny66wpovyvao3ylc23eileodtevc4b75ikpad
S: 250 OK
C: ADD_ONION RSA1024:[Blob Redacted] Port=80,192.168.1.1:8080
@@ -1723,11 +1721,11 @@
S: 250 OK
C: ADD_ONION NEW:BEST Port=22 Port=80,8080
- S: 250-ServiceID=testonion1234567
- S: 250-PrivateKey=RSA1024:[Blob Redacted]
+ S: 250-ServiceID=sampleonion4t2pqglbny66wpovyvao3ylc23eileodtevc4b75ikpad
+ S: 250-PrivateKey=ED25519-V3:[Blob Redacted]
S: 250 OK
- C: ADD_ONION NEW:BEST Flags=DiscardPK,BasicAuth Port=22
+ C: ADD_ONION NEW:RSA1024 Flags=DiscardPK,BasicAuth Port=22
ClientAuth=alice:[Blob Redacted] ClientAuth=bob
S: 250-ServiceID=testonion1234567
S: 250-ClientAuth=bob:[Blob Redacted]
@@ -1736,7 +1734,7 @@
Examples with Tor in anonymous onion service mode:
C: ADD_ONION NEW:BEST Flags=DiscardPK Port=22
- S: 250-ServiceID=testonion1234567
+ S: 250-ServiceID=exampleoniont2pqglbny66wpovyvao3ylc23eileodtevc4b75ikpad
S: 250 OK
C: ADD_ONION NEW:BEST Flags=DiscardPK,NonAnonymous Port=22
@@ -1748,13 +1746,13 @@
S: 512 Tor is in non-anonymous hidden service mode
C: ADD_ONION NEW:BEST Flags=DiscardPK,NonAnonymous Port=22
- S: 250-ServiceID=testonion1234567
+ S: 250-ServiceID=exampleoniont2pqglbny66wpovyvao3ylc23eileodtevc4b75ikpad
S: 250 OK
[ADD_ONION was added in Tor 0.2.7.1-alpha.]
- [ClientAuth was added in Tor 0.2.9.1-alpha.]
- [NonAnonymous was added in Tor 0.2.9.3-alpha.]
[MaxStreams and MaxStreamsCloseCircuit were added in Tor 0.2.7.2-alpha]
+ [ClientAuth was added in Tor 0.2.9.1-alpha. It is v2 only.]
+ [NonAnonymous was added in Tor 0.2.9.3-alpha.]
[HS v3 support added 0.3.3.1-alpha]
3.28. DEL_ONION
@@ -1819,7 +1817,88 @@
[HSPOST was added in Tor 0.2.7.1-alpha]
-3.23. DROPOWNERSHIP
+3.30. ONION_CLIENT_AUTH_ADD
+
+ The syntax is:
+ "ONION_CLIENT_AUTH_ADD" SP HSAddress
+ SP KeyType ":" PrivateKeyBlob
+ [SP "ClientName=" Nickname]
+ [SP "Flags=" TYPE] CRLF
+
+ HSAddress = 56*Base32Character
+ KeyType = "x25519" is the only one supported right now
+ PrivateKeyBlob = base64 encoding of x25519 key
+
+ Tells the connected Tor to add client-side v3 client auth credentials for the
+ onion service with "HSAddress". The "PrivateKeyBlob" is the x25519 private
+ key that should be used for this client, and "Nickname" is an optional
+ nickname for the client.
+
+ FLAGS is a comma-separated tuple of flags for this new client. For now, the
+ currently supported flags are:
+ "Permanent" - This client's credentials should be stored in the filesystem.
+ If this is not set, the client's credentials are epheremal
+ and stored in memory.
+
+ If client auth credentials already existed for this service, replace them
+ with the new ones.
+
+ If Tor has cached onion service descriptors that it has been unable to
+ decrypt in the past (due to lack of client auth credentials), attempt to
+ decrypt those descriptors as soon as this command succeeds.
+
+ On success, "250 OK" is returned. Otherwise, the following error codes exist:
+ 251 - Client auth credentials for this onion service already existed and replaced.
+ 252 - Added client auth credentials and successfully decrypted a cached descriptor.
+ 512 - Syntax error in "HSAddress", or "PrivateKeyBlob" or "Nickname"
+ 551 - Client with with this "Nickname" already exists
+ 552 - Unrecognized KeyType
+
+3.31. ONION_CLIENT_AUTH_REMOVE
+
+ The syntax is:
+ "ONION_CLIENT_AUTH_REMOVE" SP HSAddress
+
+ KeyType = "x25519" is the only one supported right now
+
+ Tells the connected Tor to remove the client-side v3 client auth credentials
+ for the onion service with "HSAddress".
+
+ On success "250 OK" is returned. Otherwise, the following error codes exist:
+ 512 - Syntax error in "HSAddress".
+ 251 - Client credentials for "HSAddress" did not exist.
+
+3.32. ONION_CLIENT_AUTH_VIEW
+
+ The syntax is:
+ "ONION_CLIENT_AUTH_VIEW" [SP HSAddress] CRLF
+
+ Tells the connected Tor to list all the stored client-side v3 client auth
+ credentials for "HSAddress". If no "HSAddress" is provided, list all the
+ stored client-side v3 client auth credentials.
+
+ The server reply format is:
+ "250-ONION_CLIENT_AUTH_VIEW" [SP HSAddress] CRLF
+ *("250-CLIENT" SP KeyType ":" PrivateKeyBlob
+ [SP "ClientName=" Nickname]
+ [SP "Flags=" FLAGS] CRLF)
+ "250 OK" CRLF
+
+ KeyType = "x25519" is the only one supported right now
+ PrivateKeyBlob = base64 encoding of x25519 key
+
+ "Nickname" is an optional nickname for this client, which can be set either
+ through the ONION_CLIENT_AUTH_ADD command, or it's the filename of this
+ client if the credentials are stored in the filesystem.
+
+ FLAGS is a comma-separated field of flags for this client, the currently
+ supported flags are:
+ "Permanent" - This client's credentials are stored in the filesystem.
+
+ On success "250 OK" is returned. Otherwise, the following error codes exist:
+ 512 - Syntax error in "HSAddress".
+
+3.33. DROPOWNERSHIP
The syntax is:
"DROPOWNERSHIP" CRLF
diff --git a/dir-spec.txt b/dir-spec.txt
index f620751..2a38d3b 100644
--- a/dir-spec.txt
+++ b/dir-spec.txt
@@ -634,10 +634,10 @@
The "Method" describes how a Bridge address is distributed by
BridgeDB. Recognized methods are: "none", "any", "https", "email",
- "moat", "hyphae". If set to "none", BridgeDB will avoid distributing
- your bridge address. If set to "any", BridgeDB will choose how to
- distribute your bridge address. Choosing any of the other methods will
- tell BridgeDB to distribute your bridge via a specific method:
+ "moat". If set to "none", BridgeDB will avoid distributing your bridge
+ address. If set to "any", BridgeDB will choose how to distribute your
+ bridge address. Choosing any of the other methods will tell BridgeDB to
+ distribute your bridge via a specific method:
- "https" specifies distribution via the web interface at
https://bridges.torproject.org;
@@ -645,14 +645,12 @@
bridges@torproject.org;
- "moat" specifies distribution via an interactive menu inside Tor
Browser; and
- - "hyphae" specifies distribution via a cryptographically-secure,
- invitation-based system.
Potential future "Method" specifiers must be as follows:
Method = (KeywordChar | "_") +
All bridges SHOULD include this line. Non-bridges MUST NOT include
- it. (It is currently ignored by Bridge DB.)
+ it.
BridgeDB SHOULD treat unrecognized Method values as if they were
"none".
diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index f65f50e..44de59f 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -222,13 +222,14 @@ Proposals by number:
299 Preferring IPv4 or IPv6 based on IP Version Failure Count [OPEN]
300 Walking Onions: Scaling and Saving Bandwidth [DRAFT]
301 Don't include package fingerprints in consensus documents [ACCEPTED]
-302 Hiding onion service clients using padding [ACCEPTED]
+302 Hiding onion service clients using padding [CLOSED]
303 When and how to remove support for protocol versions [DRAFT]
-304 Extending SOCKS5 Onion Service Error Codes [ACCEPTED]
+304 Extending SOCKS5 Onion Service Error Codes [CLOSED]
305 ESTABLISH_INTRO Cell DoS Defense Extension [DRAFT]
306 A Tor Implementation of IPv6 Happy Eyeballs [OPEN]
307 Onion Balance Support for Onion Service v3 [DRAFT]
308 Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography [DRAFT]
+309 Optimistic SOCKS Data [DRAFT]
Proposals by status:
@@ -242,6 +243,7 @@ Proposals by status:
305 ESTABLISH_INTRO Cell DoS Defense Extension
307 Onion Balance Support for Onion Service v3
308 Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography
+ 309 Optimistic SOCKS Data
NEEDS-REVISION:
212 Increase Acceptable Consensus Age [for 0.2.4.x+]
219 Support for full DNS and DNSSEC resolution in Tor [for 0.2.5.x]
@@ -273,8 +275,6 @@ Proposals by status:
288 Privacy-Preserving Statistics with Privcount in Tor (Shamir version)
292 Mesh-based vanguards
301 Don't include package fingerprints in consensus documents
- 302 Hiding onion service clients using padding
- 304 Extending SOCKS5 Onion Service Error Codes
META:
000 Index of Tor Proposals
001 The Tor Proposal Process
@@ -376,6 +376,8 @@ Proposals by status:
293 Other ways for relays to know when to publish [for 0.3.5] [in 0.4.0.1-alpha]
297 Relaxing the protover-based shutdown rules [for 0.3.5.x] [in 0.4.0.x]
298 Putting family lines in canonical form [for 0.3.6.x] [in 0.4.0.1-alpha]
+ 302 Hiding onion service clients using padding [in 0.4.1.1-alpha]
+ 304 Extending SOCKS5 Onion Service Error Codes
SUPERSEDED:
112 Bring Back Pathlen Coin Weight
113 Simplifying directory authority administration
diff --git a/proposals/304-socks5-extending-hs-error-codes.txt b/proposals/304-socks5-extending-hs-error-codes.txt
index 56a3487..d8ff7d5 100644
--- a/proposals/304-socks5-extending-hs-error-codes.txt
+++ b/proposals/304-socks5-extending-hs-error-codes.txt
@@ -2,7 +2,7 @@ Filename: 304-socks5-extending-hs-error-codes.txt
Title: Extending SOCKS5 Onion Service Error Codes
Author: David Goulet, George Kadianakis
Created: 22-May-2019
-Status: Accepted
+Status: Closed
Note: We are extending SOCKS5 here but in terms, when Tor Browser supports
HTTPCONNECT, we should not do that anymore.
diff --git a/proposals/308-counter-galois-onion.txt b/proposals/308-counter-galois-onion.txt
index ead0e81..e311c0c 100644
--- a/proposals/308-counter-galois-onion.txt
+++ b/proposals/308-counter-galois-onion.txt
@@ -94,7 +94,7 @@ Status: Draft
(indexing starts at 1)
INT(X) Translate string X into an unsigned integer
-2.2. Security parameters %%%REVISE
+2.2. Security parameters
POLY_HASH_LEN -- The length of the polynomial hash function's output,
in bytes. For POLYVAL, POLY_HASH_LEN = 16.
@@ -112,11 +112,11 @@ Status: Draft
2.3. Primitives
- The polynomial hash function is POLYVAL with a HASH_KEY_LEN-bit key. We
+ The polynomial hash function is POLYVAL with a HASH_KEY_LEN-byte key. We
write this as PH(H, M) where H is the key and M the message to be hashed.
- We use AES with a BC_KEY_LEN-bit key. For AES encryption (resp.,
- decryption) we write E(K, X) (resp., D(K, X)) where K is a BC_KEY_LEN-bit
+ We use AES with a BC_KEY_LEN-byte key. For AES encryption (resp.,
+ decryption) we write E(K, X) (resp., D(K, X)) where K is a BC_KEY_LEN-byte
key and X the block to be encrypted (resp., decrypted). For an integer
j, we use <j> to denote the string of length BC_BLOCK_LEN representing
that integer.
@@ -227,7 +227,7 @@ Status: Draft
Cf_n = M ^ Z
X_n = PH(HDf_n, (LNf_n | Cf_n))
Y_n = Nf_n ^ X_n
- Tf_n = E(KDf_n, Y_n) ^ X_n)
+ Tf_n = E(KDf_n, Y_n) ^ X_n
and updates its state by overwriting the old variables with the new
ones.
@@ -247,7 +247,7 @@ Status: Draft
% BC_BLOCK_LEN = 16
Cf_I = Cf_{I+1} ^ Z[1, 509]
X_I = PH(HSf_n, (LTf_{I+1} | Cf_I))
- Y_I = Tf_I ^ X_I
+ Y_I = Tf_{I+1} ^ X_I
Tf_I = E(KSf_I, Y_I) ^ X_I
LTf_{I+1} = Tf_{I+1}
diff --git a/proposals/309-optimistic-socks-in-tor.txt b/proposals/309-optimistic-socks-in-tor.txt
new file mode 100644
index 0000000..dbd7af6
--- /dev/null
+++ b/proposals/309-optimistic-socks-in-tor.txt
@@ -0,0 +1,78 @@
+Filename: 309-optimistic-socks-in-tor.txt
+Title: Optimistic SOCKS Data
+Author: Tom Ritter
+Created: 21-June-2019
+Status: Draft
+Ticket: #5915
+
+0. Abstract
+
+ We propose that tor should have a SocksPort option that causes it to lie
+ to the application that the SOCKS Handshake has succeeded immediately,
+ allowing the application to begin sending data optimistically.
+
+1. Introduction
+
+ In the past, Tor Browser had a patch that allowed it to send data
+ optimistically. This effectively eliminated a round trip through the
+ entire circuit, reducing latency.
+
+ This feature was buggy, and specifically caused problems with MOAT, as
+ described in [0] and Tor Messenger as described in [1]. It is possible
+ that the other issues observed with it were the same issue, it is
+ possible they were different.
+
+ Rather than trying to identify and fix the problem in Tor Browser, an
+ alternate idea is to have tor lie to the application, causing it to send
+ the data optimistically. This can benefit all users of tor. This
+ proposal documents that idea.
+
+ [0] https://trac.torproject.org/projects/tor/ticket/24432#comment:19
+ [1] https://trac.torproject.org/projects/tor/ticket/19910#comment:3
+
+2. Proposal
+
+2.1. Behavior
+
+ When the SocksPort flag defined below is present, Tor will immediately
+ report a successful SOCKS handshake subject for non-onion connections.
+ If, later, tor recieves an end cell rather than a connected cell, it
+ will hang up the SOCKS connection.
+
+ The requirement to omit this for onion connections is because in
+ #30382 we implemented a mechanism to return a special SOCKS error code
+ if we are connecting to an onion site that requires authentication.
+ Returning an early success would prevent this from working.
+
+ Redesigning the mechanism to communicate auth-required onion sites to
+ the browser, while also supporting optimistic data, are left to a future
+ proposal.
+
+2.2. New SocksPort Flag
+
+ In order to have backward compatibility with third party applications that
+ do not support or do not want to use optimistic data, we propose a new
+ SocksPort flag that needs to be set in the tor configuration file in order
+ for the optimistic beahvior to occur.
+
+ The new SocksPort flag is:
+
+ "OptimisticData" -- Tor will immediately report a successful SOCKS
+ handshake subject for non-onion connections and
+ hang up if it gets an end cell rather than a
+ connected cell.
+
+3. Application Error Handling
+
+ This behavior will cause the application talking to Tor to potentially
+ behave abnormally as it will believe that it has completed a TCP
+ connection. If no such connection can be made by tor, the program may
+ behave in a way that does not accurately represent the behavior of the
+ connection.
+
+ Applications SHOULD test various connection failure modes and ensure their
+ behavior is acceptable before using this feature.
+
+References:
+
+[RFC1928] https://www.ietf.org/rfc/rfc1928.txt
diff --git a/rend-spec-v3.txt b/rend-spec-v3.txt
index 7c80f1a..a3e0b0a 100644
--- a/rend-spec-v3.txt
+++ b/rend-spec-v3.txt
@@ -468,8 +468,6 @@ Table of contents:
optional client authorization is enabled, the service may additionally
require the client to prove knowledge of a pre-shared private key.
- (NOTE: client authorization is not implemented as of 0.3.2.1-alpha.)
-
1.4. In more detail: Distributing hidden service descriptors. [IMD:DIST]
Periodically, hidden service descriptors become stored at different
@@ -645,7 +643,7 @@ Table of contents:
[TODO: Also specify stealth client authorization.]
- (NOTE: client authorization is not implemented as of 0.3.2.1-alpha.)
+ (NOTE: client authorization is implemented as of 0.3.5.1-alpha.)
2. Generating and publishing hidden service descriptors [HSDIR]
@@ -1194,8 +1192,6 @@ Table of contents:
[Any number]
- (NOTE: client authorization is not implemented as of 0.3.2.1-alpha.)
-
When client authorization is enabled, the hidden service inserts an
"auth-client" line for each of its authorized clients. If client
authorization is disabled, the fields here can be populated with random
@@ -2341,7 +2337,7 @@ Appendix F. Hidden service directory format [HIDSERVDIR-FORMAT]
See section [CLIENT-AUTH-MGMT] for more details and the format of the client file.
- (NOTE: client authorization is not implemented as of 0.3.2.1-alpha.)
+ (NOTE: client authorization is implemented as of 0.3.5.1-alpha.)
Appendix G. Managing authorized client data [CLIENT-AUTH-MGMT]
@@ -2350,7 +2346,7 @@ Appendix G. Managing authorized client data [CLIENT-AUTH-MGMT]
scheme for configuring client authorization. Please see appendix
[HIDSERVDIR-FORMAT] for more information about relevant hidden service files.
- (NOTE: client authorization is not implemented as of 0.3.2.1-alpha.)
+ (NOTE: client authorization is implemented as of 0.3.5.1-alpha.)
G.1. Configuring client authorization using torrc
diff --git a/socks-extensions.txt b/socks-extensions.txt
index ed249ad..e2fe5da 100644
--- a/socks-extensions.txt
+++ b/socks-extensions.txt
@@ -42,6 +42,10 @@ Tor's extensions to the SOCKS protocol
username/password fields of this message to be empty. This technically
violates RFC1929 [4], but ensures interoperability with somewhat broken
SOCKS5 client implementations.
+ - Custom reply error code. The "REP" fields, as per the RFC[3], has
+ unassigned values which are used to describe Tor internal errors. See
+ ExtendedErrors in the tor.1 man page for more details. It is only sent
+ back if this SocksPort flag is set.
(For more information on stream isolation, see IsolateSOCKSAuth on the Tor
manpage.)
7apu2bq3rhoylwmucxizk54afw5jyda7pho4j5zdcqpwkufke7zdzwad.onion