diff options
| -rw-r--r-- | bandwidth-file-spec.txt | 14 | ||||
| -rw-r--r-- | control-spec.txt | 64 | ||||
| -rw-r--r-- | dir-list-spec.txt | 52 | ||||
| -rw-r--r-- | dir-spec.txt | 20 | ||||
| -rw-r--r-- | padding-spec.txt | 266 | ||||
| -rw-r--r-- | proposals/000-index.txt | 20 | ||||
| -rw-r--r-- | proposals/176-revising-handshake.txt | 2 | ||||
| -rw-r--r-- | proposals/251-netflow-padding.txt | 2 | ||||
| -rw-r--r-- | proposals/254-padding-negotiation.txt | 11 | ||||
| -rw-r--r-- | proposals/289-authenticated-sendmes.txt | 67 | ||||
| -rw-r--r-- | proposals/295-relay-crypto-with-adl.txt | 103 | ||||
| -rw-r--r-- | proposals/302-padding-machines-for-onion-clients.txt | 301 | ||||
| -rw-r--r-- | proposals/303-protover-removal-policy.txt | 62 | ||||
| -rw-r--r-- | proposals/304-socks5-extending-hs-error-codes.txt | 109 | ||||
| -rw-r--r-- | proposals/305-establish-intro-dos-defense-extention.txt | 197 | ||||
| -rw-r--r-- | proposals/306-ipv6-happy-eyeballs.txt | 300 | ||||
| -rw-r--r-- | proposals/307-onionbalance-v3.txt | 180 | ||||
| -rw-r--r-- | proposals/308-counter-galois-onion.txt | 550 | ||||
| -rw-r--r-- | proposals/309-optimistic-socks-in-tor.txt | 78 | ||||
| -rw-r--r-- | rend-spec-v3.txt | 40 | ||||
| -rw-r--r-- | tor-spec.txt | 116 |
21 files changed, 2368 insertions, 186 deletions
diff --git a/bandwidth-file-spec.txt b/bandwidth-file-spec.txt index 1c36558..abcd0a8 100644 --- a/bandwidth-file-spec.txt +++ b/bandwidth-file-spec.txt @@ -98,7 +98,7 @@ Int SP (space) NL (newline) - Keyword + KeywordChar ArgumentChar nickname hexdigest (a '$', followed by 40 hexadecimal characters @@ -112,7 +112,9 @@ Line ::= ArgumentChar* NL RelayLine ::= KeyValue (SP KeyValue)* NL - KeyValue ::= Keyword "=" Value + HeaderLine ::= KeyValue NL + KeyValue ::= Key "=" Value + Key ::= (KeywordChar | "_")+ Value ::= ArgumentCharValue+ ArgumentCharValue ::= any printing ASCII character except NL and SP. Terminator ::= "=====" or "====" @@ -141,6 +143,14 @@ 2.2. Header List format + It consists of a Timestamp line and zero or more HeaderLines. + + All the header lines MUST conform to the HeaderLine format, except + the first Timestamp line. + + The Timestamp line is not a HeaderLine to keep compatibility with + the legacy Bandwidth File format. + Some header Lines MUST appear in specific positions, as documented below. All other Lines can appear in any order. diff --git a/control-spec.txt b/control-spec.txt index 01063b0..f09640c 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>" @@ -1131,6 +1132,14 @@ 0 or 1, depending on whether it is possible to use SAVECONF without the FORCE flag. (Introduced in 0.3.1.1-alpha.) + "limits/max-mem-in-queues" + The amount of memory that Tor's out-of-memory checker will allow + Tor to allocate (in places it can see) before it starts freeing memory + and killing circuits. See the MaxMemInQueues option for more + details. Unlike the option, this value reflects Tor's actual limit, and + may be adjusted depending on the available system memory rather than on + the MaxMemInQueues option. (Introduced in 0.2.5.4-alpha) + Examples: C: GETINFO version desc/name/moria1 S: 250+desc/name/moria= @@ -1596,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 = @@ -1615,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. @@ -1633,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 @@ -1659,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 @@ -1701,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 @@ -1715,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] @@ -1728,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 @@ -1740,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 @@ -2340,6 +2346,14 @@ Severity = "DEBUG" / "INFO" / "NOTICE" / "WARN"/ "ERR" + Some low-level logs may be sent from signal handlers, so their destination + logs must be signal-safe. These low-level logs include backtraces, + logging function errors, and errors in code called by logging functions. + Signal-safe logs are never sent as control port log events. + + Control port message trace debug logs are never sent as control port log + events, to avoid modifying control output when debugging. + 4.1.6. New descriptors available This event is generated when new router descriptors (not microdescs or diff --git a/dir-list-spec.txt b/dir-list-spec.txt index 3087246..037319d 100644 --- a/dir-list-spec.txt +++ b/dir-list-spec.txt @@ -63,11 +63,37 @@ 1.3. Format Versions + The directory list format uses semantic versioning: https://semver.org + + In particular: + * major versions are used for incompatible changes, like + removing non-optional fields + * minor versions are used for compatible changes, like adding + fields + * patch versions are for bug fixes, like fixing an + incorrectly-formatted Summary item + 1.0.0 - The legacy fallback directory list format 2.0.0 - Adds name and extrainfo structured comments, and section separator comments to make the list easier to parse. + 2.1.0 - Adds a source list comment to the header. + +1.4. Future Plans + + Tor also has an auth_dirs.inc file, but it is not yet in this format. + Tor uses slightly different formats for authorities and fallback + directory mirrors, so we will need to make some changes to tor so that + it parses this format. (We will also need to add authority-specific + information to this format.) See #24818 for details. + + We want to add a torrc option so operators can opt-in their relays as + fallback directory mirrors. This gives us a signed opt-in confirmation. + (We can also continue to accept whitelist entries, and do other checks.) + We need to write a short proposal, and make some changes to tor and the + fallback update script. See #24839 for details. + 2. Format Details Directory lists contain the following sections: @@ -149,16 +175,10 @@ [In second position, exactly once.] - The version of the directory list format. version_number uses - semantic versioning: https://semver.org + The version of the directory list format. - In particular: - * major versions are used for incompatible changes, like - removing non-optional fields - * minor versions are used for compatible changes, like adding - fields - * patch versions are for bug fixes, like fixing an - incorrectly-formatted Summary item + version_number is a semantic version, see the "Format Versions" + section for details. Version 1.0.0 represents the undocumented, legacy fallback list format(s). Version 2.0.0 and later are documented by this @@ -174,6 +194,20 @@ The current timestamp format is YYYYMMDDHHMMSS, as an integer. + "/*" SP+ "source=" Keyword SP+ "*/" SP* NL + + [Zero or one time.] + + The source of the directory entries in the list. + + As of version 2.1.0, the sources are: + * "whitelist" - the fallback.whitelist file in the fallback-scripts + repository. This is the default. + * "fallback" - a fallback_dirs.inc file from a tor repository. + Used in check_existing mode. + + This line was added in version 2.1.0 of this specification. + "/*" SP+ key_value SP+ "*/" SP* NL [Zero or more times.] diff --git a/dir-spec.txt b/dir-spec.txt index 460d02a..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". @@ -2098,6 +2096,14 @@ the circuit queue a given circuit. Min: 0. Max: 50000. Default 1000. First appeared: 0.4.0.3-alpha. + "sendme_emit_min_version" -- Minimum SENDME version that can be sent. + Min: 0. Max: 255. Default 0. First + appeared: 0.4.1.1-alpha. + + "sendme_accept_min_version" -- Minimum SENDME version that is accepted. + Min: 0. Max: 255. Default 0. First + appeared: 0.4.1.1-alpha. + "shared-rand-previous-value" SP NumReveals SP Value NL [At most once] diff --git a/padding-spec.txt b/padding-spec.txt index b85f0fd..4c3c152 100644 --- a/padding-spec.txt +++ b/padding-spec.txt @@ -1,6 +1,6 @@ Tor Padding Specification - Mike Perry + Mike Perry, George Kadianakis Note: This is an attempt to specify Tor as currently implemented. Future versions of Tor will implement improved algorithms. @@ -10,8 +10,6 @@ various traffic patterns from external and internal observers. Other implementations MAY take other approaches, but implementors should be aware of the anonymity and load-balancing implications of their choices. - THIS SPEC ISN'T DONE YET. - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in @@ -35,9 +33,15 @@ the anonymity and load-balancing implications of their choices. padding to be sent to any intermediate node in a circuit (as per Section 6.1 of tor-spec.txt). - Currently, only single-hop CELL_PADDING is used by Tor. It is described in - Section 2. At a later date, further sections will be added to this document - to describe various uses of multi-hop circuit-level padding. + Tor uses both connection level and circuit level padding. Connection + level padding is described in section 2. Circuit level padding is + described in section 3. + + The circuit-level padding system is completely orthogonal to the + connection-level padding. The connection-level padding system regards + circuit-level padding as normal data traffic, and hence the connection-level + padding system will not add any additional overhead while the circuit-level + padding system is actively padding. 2. Connection-level padding @@ -274,6 +278,250 @@ the anonymity and load-balancing implications of their choices. open. - Default: 3600 + +3. Circuit-level padding + + The circuit padding system in Tor is an extension of the WTF-PAD + event-driven state machine design[15]. At a high level, this design places + one or more padding state machines at the client, and one or more padding + state machines at a relay, on each circuit. + + State transition and histogram generation has been generalized to be fully + programmable, and probability distribution support was added to support more + compact representations like APE[16]. Additionally, packet count limits, + rate limiting, and circuit application conditions have been added. + + At present, Tor uses this system to deploy two pairs of circuit padding + machines, to obscure differences between the setup phase of client-side + onion service circuits, up to the first 10 cells. + + This specification covers only the resulting behavior of these padding + machines, and thus does not cover the state machine implementation details or + operation. For full details on using the circuit padding system to develop + future padding defenses, see the research developer documentation[17]. + +3.1. Circuit Padding Negotiation + + Circuit padding machines are advertised as "Padding" subprotocol versions + (see tor-spec.txt Section 9). The onion service circuit padding machines are + advertised as "Padding=2". + + Because circuit padding machines only become active at certain points in + circuit lifetime, and because more than one padding machine may be active at + any given point in circuit lifetime, there is also a padding negotiation cell, + with fields as follows: + + const CIRCPAD_COMMAND_STOP = 1; + const CIRCPAD_COMMAND_START = 2; + + const CIRCPAD_RESPONSE_OK = 1; + const CIRCPAD_RESPONSE_ERR = 2; + + const CIRCPAD_MACHINE_CIRC_SETUP = 1; + + struct circpad_negotiate { + u8 version IN [0]; + u8 command IN [CIRCPAD_COMMAND_START, CIRCPAD_COMMAND_STOP]; + + u8 machine_type IN [CIRCPAD_MACHINE_CIRC_SETUP]; + }; + + When a client wants to start a circuit padding machine, it first checks that + the desired destination hop advertises the appropriate subprotocol version for + that machine. It then sends a circpad_negotiate cell to that hop with + command=CIRCPAD_COMMAND_START, and machine_type=CIRCPAD_MACHINE_CIRC_SETUP (for + the circ setup machine, the destination hop is the second hop in the circuit). + + When a relay receives a circpad_negotiate cell, it checks that it supports + the requested machine, and sends a circpad_negotiated cell, which is formatted + as follows: + + struct circpad_negotiated { + u8 version IN [0]; + u8 command IN [CIRCPAD_COMMAND_START, CIRCPAD_COMMAND_STOP]; + u8 response IN [CIRCPAD_RESPONSE_OK, CIRCPAD_RESPONSE_ERR]; + + u8 machine_type IN [CIRCPAD_MACHINE_CIRC_SETUP]; + }; + + If the machine is supported, the response field will contain + CIRCPAD_RESPONSE_OK. If it is not, it will contain CIRCPAD_RESPONSE_ERR. + + Either side may send a CIRCPAD_COMMAND_STOP to shut down the padding machines + (clients MUST only send circpad_negotiate, and relays MUST only send + circpad_negotiated for this purpose). + +3.2. Circuit Padding Machine Message Management + + Clients MAY send padding cells towards the relay before receiving the + circpad_negotiated response, to allow for outbound cover traffic before + negotiation completes. + + Clients MAY send another circpad_negotiate cell before receiving the + circpad_negotiated response, to allow for rapid machine changes. + + Relays MUST NOT send padding cells or circpad_negotiated cells, unless a + padding machine is active. Any padding-related cells that arrive at the client + from unexpected relay sources are protocol violations, and clients MAY + immediately tear down such circuits to avoid side channel risk. + +3.3. Obfuscating client-side onion service circuit setup + + The circuit padding currently deployed in Tor attempts to hide client-side + onion service circuit setup. Service-side setup is not covered, because doing + so would involve significantly more overhead, and/or require interaction with + the application layer. + + The approach taken aims to make client-side introduction and rendezvous + circuits match the cell direction sequence and cell count of 3 hop general + circuits used for normal web traffic, for the first 10 cells only. The + lifespan of introduction circuits is also made to match the lifespan + of general circuits. + + Note that inter-arrival timing is not obfuscated by this defense. + +3.3.1. Common general circuit construction sequences + + Most general Tor circuits used to surf the web or download directory + information start with the following 6-cell relay cell sequence (cells + surrounded in [brackets] are outgoing, the others are incoming): + + [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [BEGIN] -> CONNECTED + + When this is done, the client has established a 3-hop circuit and also opened + a stream to the other end. Usually after this comes a series of DATA cell that + either fetches pages, establishes an SSL connection or fetches directory + information: + + [DATA] -> [DATA] -> DATA -> DATA...(inbound cells continue) + + The above stream of 10 relay cells defines the grand majority of general + circuits that come out of Tor browser during our testing, and it's what we use + to make introduction and rendezvous circuits blend in. + + Please note that in this section we only investigate relay cells and not + connection-level cells like CREATE/CREATED or AUTHENTICATE/etc. that are used + during the link-layer handshake. The rationale is that connection-level cells + depend on the type of guard used and are not an effective fingerprint for a + network/guard-level adversary. + +3.3.2 Client-side onion service introduction circuit obfuscation + + Two circuit padding machines work to hide client-side introduction circuits: + one machine at the origin, and one machine at the second hop of the circuit. + Each machine sends padding towards the other. The padding from the origin-side + machine terminates at the second hop and does not get forwarded to the actual + introduction point. + + From Section 3.3.1 above, most general circuits have the following initial + relay cell sequence (outgoing cells marked in [brackets]): + + [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [BEGIN] -> CONNECTED + -> [DATA] -> [DATA] -> DATA -> DATA...(inbound data cells continue) + + Whereas normal introduction circuits usually look like: + + [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 + -> [INTRO1] -> INTRODUCE_ACK + + This means that up to the sixth cell (first line of each sequence above), + both general and intro circuits have identical cell sequences. After that + we want to mimic the second line sequence of + -> [DATA] -> [DATA] -> DATA -> DATA...(inbound data cells continue) + + We achieve this by starting padding INTRODUCE1 has been sent. With padding + negotiation cells, in the common case of the second line looks like: + -> [INTRO1] -> [PADDING_NEGOTIATE] -> PADDING_NEGOTIATED -> INTRO_ACK + + Then, the middle node will send between INTRO_MACHINE_MINIMUM_PADDING (7) and + INTRO_MACHINE_MAXIMUM_PADDING (10) cells, to match the "...(inbound data cells + continue)" portion of the trace (aka the rest of an HTTPS response body). + + We also set a special flag which keeps the circuit open even after the + introduction is performed. With this feature the circuit will stay alive for + the same duration as normal web circuits before they expire (usually 10 + minutes). + +3.3.3. Client-side rendezvous circuit hiding + + Following a similar argument as for intro circuits, we are aiming for padded + rendezvous circuits to blend in with the initial cell sequence of general + circuits which usually look like this: + + [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [BEGIN] -> CONNECTED + -> [DATA] -> [DATA] -> DATA -> DATA...(incoming cells continue) + + Whereas normal rendezvous circuits usually look like: + + [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [EST_REND] -> REND_EST + -> REND2 -> [BEGIN] + + This means that up to the sixth cell (the first line), both general and + rend circuits have identical cell sequences. + + After that we want to mimic a [DATA] -> [DATA] -> DATA -> DATA sequence. + + With padding negotiation right after the REND_ESTABLISHED, the sequence + becomes: + + [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [EST_REND] -> REND_EST + -> [PADDING_NEGOTIATE] -> [DROP] -> PADDING_NEGOTIATED -> DROP... + + After which normal application DATA cells continue on the circuit. + + Hence this way we make rendezvous circuits look like general circuits up + till the end of the circuit setup. + + After that our machine gets deactivated, and we let the actual rendezvous + circuit shape the traffic flow. Since rendezvous circuits usually imitate + general circuits (their purpose is to surf the web), we can expect that they + will look alike. + +3.3.4. Circuit setup machine overhead + + For the intro circuit case, we see that the origin-side machine just sends a + single [PADDING_NEGOTIATE] cell, whereas the origin-side machine sends a + PADDING_NEGOTIATED cell and between 7 to 10 DROP cells. This means that the + average overhead of this machine is 11 padding cells per introduction circuit. + + For the rend circuit case, this machine is quite light. Both sides send 2 + padding cells, for a total of 4 padding cells. + +3.4. Circuit padding consensus parameters + + The circuit padding system has a handful of consensus parameters that can + either disable circuit padding entirely, or rate limit the total overhead + at relays and clients. + + * circpad_padding_disabled + - If set to 1, no circuit padding machines will negotiate, and all + current padding machines will cease padding immediately. + - Default: 0 + + * circpad_padding_reduced + - If set to 1, only circuit padding machines marked as "reduced"/"low + overhead" will be used. (Currently no such machines are marked + as "reduced overhead"). + - Default: 0 + + * circpad_global_allowed_cells + - This is the number of padding cells that must be sent before + the 'circpad_global_max_padding_percent' parameter is applied. + - Default: 0 + + * circpad_global_max_padding_percent + - This is the maximum ratio of padding cells to total cells, specified + as a percent. If the global ratio of padding cells to total cells + across all circuits exceeds this percent value, no more padding is sent + until the ratio becomes lower. 0 means no limit. + - Default: 0 + + * circpad_max_circ_queued_cells + - This is the maximum number of cells that can be in the circuitmux queue + before padding stops being sent on that circuit. + - Default: CIRCWINDOW_START_MAX (1000) + + A. Acknowledgments This research was supported in part by NSF grants CNS-1111539, @@ -293,3 +541,9 @@ A. Acknowledgments 12. http://freehaven.net/anonbib/cache/murdoch-pet2007.pdf 13. https://gitweb.torproject.org/torspec.git/tree/proposals/188-bridge-guards.txt 14. http://www.ntop.org/wp-content/uploads/2013/03/nProbe_UserGuide.pdf +15. http://arxiv.org/pdf/1512.00524 +16. https://www.cs.kau.se/pulls/hot/thebasketcase-ape/ +17. https://github.com/torproject/tor/tree/master/doc/HACKING/CircuitPaddingDevelopment.md +18. https://www.usenix.org/node/190967 + https://blog.torproject.org/technical-summary-usenix-fingerprinting-paper + diff --git a/proposals/000-index.txt b/proposals/000-index.txt index a504c27..6e7b802 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -209,7 +209,7 @@ Proposals by number: 286 Controller APIs for hibernation access on mobile [REJECTED] 287 Reduce circuit lifetime without overloading the network [OPEN] 288 Privacy-Preserving Statistics with Privcount in Tor (Shamir version) [ACCEPTED] -289 Authenticating sendme cells to mitigate bandwidth attacks [OPEN] +289 Authenticating sendme cells to mitigate bandwidth attacks [CLOSED] 290 Continuously update consensus methods [META] 291 The move to two guard nodes [NEEDS-REVISION] 292 Mesh-based vanguards [ACCEPTED] @@ -222,6 +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 [CLOSED] +303 When and how to remove support for protocol versions [DRAFT] +304 Extending SOCKS5 Onion Service Error Codes [ACCEPTED] +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: @@ -231,6 +239,11 @@ Proposals by status: 273 Exit relay pinning for web services [for n/a] 294 TLS 1.3 Migration 300 Walking Onions: Scaling and Saving Bandwidth + 303 When and how to remove support for protocol versions + 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] @@ -250,10 +263,10 @@ Proposals by status: 277 Detect multiple relay instances running with same ID [for 0.3.??] 285 Directory documents should be standardized as UTF-8 287 Reduce circuit lifetime without overloading the network - 289 Authenticating sendme cells to mitigate bandwidth attacks 295 Using ADL for relay cryptography (solving the crypto-tagging attack) 296 Have Directory Authorities expose raw bandwidth list files 299 Preferring IPv4 or IPv6 based on IP Version Failure Count + 306 A Tor Implementation of IPv6 Happy Eyeballs ACCEPTED: 188 Bridge Guards and other anti-enumeration defenses 249 Allow CREATE cells with >505 bytes of handshake data @@ -262,6 +275,7 @@ 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 + 304 Extending SOCKS5 Onion Service Error Codes META: 000 Index of Tor Proposals 001 The Tor Proposal Process @@ -359,9 +373,11 @@ Proposals by status: 278 Directory Compression Scheme Negotiation [in 0.3.1.1-alpha] 283 Move IPv6 ORPorts from microdescriptors to the microdesc consensus [for 0.3.3.x] [in 0.3.3.1-alpha] 284 Hidden Service v3 Control Port + 289 Authenticating sendme cells to mitigate bandwidth attacks [in 0.4.1.1-alpha] 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] SUPERSEDED: 112 Bring Back Pathlen Coin Weight 113 Simplifying directory authority administration diff --git a/proposals/176-revising-handshake.txt b/proposals/176-revising-handshake.txt index c68400b..20a3ef2 100644 --- a/proposals/176-revising-handshake.txt +++ b/proposals/176-revising-handshake.txt @@ -17,7 +17,7 @@ Supersedes: 169 and authenticate the original handshake, this proposal takes an approach similar to Steven Murdoch's proposal 124 and my old proposal 169, and uses Tor cells to finish authenticating the - parties' identities once the initial TLS handshake is finished.spo + parties' identities once the initial TLS handshake is finished. I discuss some alternative design choices and why I didn't make them in section 7; please have a quick look there before diff --git a/proposals/251-netflow-padding.txt b/proposals/251-netflow-padding.txt index f1b9450..39cc795 100644 --- a/proposals/251-netflow-padding.txt +++ b/proposals/251-netflow-padding.txt @@ -5,7 +5,7 @@ Created: 20 August 2015 Status: Closed Implemented-In: 0.3.1.1-alpha -NOTE: Please look at padding-spec.txt now, not this document. +NOTE: Please look at section 2 of padding-spec.txt now, not this document. 0. Motivation diff --git a/proposals/254-padding-negotiation.txt b/proposals/254-padding-negotiation.txt index 087f060..0d14c09 100644 --- a/proposals/254-padding-negotiation.txt +++ b/proposals/254-padding-negotiation.txt @@ -367,6 +367,17 @@ When either global or machine limits are reached, padding is no longer scheduled. The machine simply becomes idle until the overhead drops below the threshold. +Finally, the consensus can also be used to specify that clients should +use only machines that are flagged as reduced padding, or disable circuit +padding entirely, with the following two parameters: + + * circpad_padding_reduced=1 + - Tells clients to only use padding machines with the + 'reduced_padding_ok' machine condition flag set. + * circpad_padding_disabled=1 + - Tells clients to stop circuit padding immediately, and not negotiate + any further padding machines. + 5.2. Overhead accounting In order to monitor the quantity of padding to decide if we should alter diff --git a/proposals/289-authenticated-sendmes.txt b/proposals/289-authenticated-sendmes.txt index 19c3b84..e09b882 100644 --- a/proposals/289-authenticated-sendmes.txt +++ b/proposals/289-authenticated-sendmes.txt @@ -1,8 +1,9 @@ Filename: 289-authenticated-sendmes.txt Title: Authenticating sendme cells to mitigate bandwidth attacks -Author: Rob Jansen, Roger Dingledine +Author: Rob Jansen, Roger Dingledine, David Goulet Created: 2016-12-01 -Status: Open +Status: Closed +Implemented-In: 0.4.1.1-alpha 1. Overview and Motivation @@ -244,12 +245,12 @@ Status: Open DIGEST [20 bytes] - If the DATA_LEN value is less then 4 bytes, the cell should be + If the DATA_LEN value is less than 4 bytes, the cell should be dropped and the circuit closed. If the value is more than 4 bytes, then the first 20 bytes should be read to get the correct value. The DIGEST is the digest value from the cell that triggered this - SENDME as mentionned above. This value is matched on the other side + SENDME as mentioned above. This value is matched on the other side from the previous cell. If a VERSION is unrecognized, the SENDME cell should be treated as version @@ -309,7 +310,7 @@ Status: Open protected from attack. It's not all bad news though, since we could flip the switches earlier than intended if we encounter a network-wide attack. - There are 5 phases to this plan and detailed in the subsections. + There are 4 phases to this plan detailed in the following subsections. 4.1. Phase One - Remembering Digests @@ -360,49 +361,28 @@ Status: Open "sendme_accept_min_version" - Minimum SENDME version that is accepted. - (It has to be two separate switches, not one unified one, because - otherwise we'd have a race where relays learn about the update before - clients know to start the new behavior.) + It has to be two separate switches, not one unified one, because otherwise + we'd have a race where relays learn about the update before clients know to + start the new behavior. - Phase three will shutdown every clients that understand protover. However, - one important case remains which is when a client not supporting verison 1 - boots up for the first time (no consensus). +4.5. Timeline - It won't be able to download a consensus and thus know that it can't join - the network making it re-try over and over again. To avoid that, we propose - to still allow v0 SENDMEs on one-hop directory circuits meaning the new - parameter above affects everything except these specific circuits. - - It will allow us to extend the period of time between Phase Four and too - old clients to bootstrap and fail properly. The last phase will then turn - this behavior off and we will be done once and for all with version 0. - -4.5. Phase Five - Turning Off v0 - - The last consensus switch to flip is the one refusing SENDME v0 on one-hop - directory circuit as described in previous phase. - - The newly proposed consensus parameter to achieve this is: - - "sendme_onehop_dir_min_version" - Minimum SENDME version that is - accepted on one-hop directory circuits. - - After this phase, any tor still not supporting v0 will retry over and over - again to bootstrap. We can't avoid that but at least we can give enough - time to minimize the amount of old clients unable to boostrap with the - proposed timeline below. + The proposed timeline for the deployment phases: -4.6. Timeline + Phase 1: - The proposed timeline for the deployment phases: + Once this proposal is merged into tor (expected: 0.4.1.1-alpha), v1 + SENDMEs can be accepted on a circuit. - Phase 1 and 2: + Phase 2: - Once this proposal is merged into tor (expected: 0.4.1.1-alpha). + Once Tor Browser releases a stable version containing 0.4.1, we + consider that we have a very large portion of clients supporting v1 + and thus limit the partition problem. - Those two phases will start roughly at the same time. The reason we - can do that is because SENDME payloads are ignored for version 0 thus - sending v1 right now will not affect Tor current behavior. + We can safely emit v1 SENDMEs in the network because the payload is + ignored for version 0 thus sending a v1 right now will not affect + older tor's behavior and will be considered a v0. Phase 3: @@ -420,11 +400,6 @@ Status: Open Considering 6 months release time frame we expect to do this phase around July 2022. - Phase 5: - - Depends on how Phase 4 goes. It could be we'll do that very quickly - or not depending on our users and also Tor situation/health in 2022. - 5. Security Discussion Does our design enable any new adversarial capabilities? diff --git a/proposals/295-relay-crypto-with-adl.txt b/proposals/295-relay-crypto-with-adl.txt index f88f3cf..cfb58a2 100644 --- a/proposals/295-relay-crypto-with-adl.txt +++ b/proposals/295-relay-crypto-with-adl.txt @@ -2,7 +2,7 @@ Filename: 295-relay-crypto-with-adl.txt Title: Using ADL for relay cryptography (solving the crypto-tagging attack) Author: Tomer Ashur, Orr Dunkelman, Atul Luykx Created: 22 Feb 2018 -Last-Modified: 1 March 2019 +Last-Modified: 10 July 2019 Status: Open @@ -54,7 +54,8 @@ Status: Open CTR Counter Mode N_I A de/encryption nonce (to be used in CTR-mode) T_I A tweak (to be used to de/encrypt the nonce) - T'_I A running digest + Tf'_I A running digest (forward direction) + Tb'_I A running digest (backward direction) ^ XOR || Concatenation (This is more readable than a single | but must be adapted @@ -71,7 +72,7 @@ Status: Open recommend DIG_KEY_LEN = 128. ENC_KEY_LEN -- The key length used for encryption (e.g., AES). We - recommend ENC_KEY_LEN = 128. + recommend ENC_KEY_LEN = 256. 2.4. Key derivation (replaces Section 5.2.2) @@ -94,8 +95,8 @@ Status: Open Length Purpose Notation ------ ------- -------- - HASH_LEN forward digest IV DF * - HASH_LEN backward digest IV DB * + HASH_LEN forward digest IV DF + HASH_LEN backward digest IV DB ENC_KEY_LEN encryption key Kf ENC_KEY_LEN decryption key Kb DIG_KEY_LEN forward digest key Khf @@ -105,7 +106,7 @@ Status: Open DIGEST_LEN nonce to use in the * hidden service protocol - * I am not sure that we need these any longer. + * I am not sure that we need this any longer. Excess bytes from K are discarded. @@ -130,6 +131,10 @@ Status: Open 3. Routing relay cells + Let n denote the integer representing the destination node. For + I = 1...n, we set Tf'_{I} = DF_I and Tb'_{I} = DB_I + where DF_I and DB_I are generated according to Section 2.4. + 3.1. Forward Direction The forward direction is the direction that CREATE/CREATE2 cells @@ -137,25 +142,22 @@ Status: Open 3.1.1. Routing from the Origin - Let n denote the integer representing the destination node. For - I = 1...n+1, T'_{I} is initialized to the 128-bit string consisting - entirely of '0's. When an OP sends a relay cell, they prepare the + When an OP sends a relay cell, they prepare the cell as follows: The OP prepares the authentication part of the message: C_{n+1} = M - T_{n+1} = Digest(Khf_n,T'_{n+1}||C_{n+1}) + T_{n+1} = Digest(Khf_n,C_{n+1}) N_{n+1} = T_{n+1} ^ E(Ktf_n,T_{n+1} ^ 0) - T'_{n+1} = T_{n+1} Then, the OP prepares the multi-layered encryption: For I=n...1: C_I = Encrypt(Kf_I,N_{I+1},C_{I+1}) - T_I = Digest(Khf_I,T'_I||C_I) + T_I = Digest(Khf_I,Tf'_I||C_I) N_I = T_I ^ E(Ktf_I,T_I ^ N_{I+1}) - T'_I = T_I + Tf'_I = T_I The OP sends C_1 and N_1 to node 1. @@ -166,10 +168,10 @@ Status: Open 'Forward' relay cell: - T_I = Digest(Khf_I,T'_I||C_I) + T_I = Digest(Khf_I,Tf'_I||C_I) N_{I+1} = T_I ^ D(Ktf_I,T_I ^ N_I) C_{I+1} = Decrypt(Kf_I,N_{I+1},C_I) - T'_I = T_I + Tf'_I = T_I The OR then decides whether it recognizes the relay cell as described below. If the OR recognizes the cell, it processes the @@ -190,10 +192,10 @@ Status: Open 'Backward' relay cell: - T_I = Digest(Khb_I,T'_I||C_{I+1}) + T_I = Digest(Khb_I,Tb'_I||C_{I+1}) N_I = T_I ^ E(Ktb_I,T_I ^ N_{I+1}) C_I = Encrypt(Kb_I,N_I,C_{I+1}) - T'_I = T_I + Tb'_I = T_I with C_{n+1} = M and N_{n+1}=0. Once encrypted, the node passes C_I and N_I along the circuit towards the OP. @@ -207,9 +209,9 @@ Status: Open For I=1...n, where n is the end node on the circuit: C_{I+1} = Decrypt(Kb_I,N_I,C_I) - T_I = Digest(Khb_I,T'_I||C_{I+1}) + T_I = Digest(Khb_I,Tb'_I||C_{I+1}) N_{I+1} = T_I ^ D(Ktb_I,T_I ^ N_I) - T'_I = T_I + Tb'_I = T_I If the payload is recognized (see Section 4.1), then: @@ -229,46 +231,30 @@ Status: Open The payload of each unencrypted RELAY cell consists of: Relay command [1 byte] - 'Recognized' [2 bytes] StreamID [2 bytes] Length [2 bytes] - Data [PAYLOAD_LEN-23 bytes] + Data [PAYLOAD_LEN-21 bytes] - The 'recognized' field is used as a simple indication that the - cell is still encrypted. It is an optimization to avoid - calculating expensive digests for every cell. When sending cells, - the unencrypted 'recognized' MUST be set to zero. - When receiving and decrypting cells the 'recognized' will always - be zero if we're the endpoint that the cell is destined for. For - cells that we should relay, the 'recognized' field will usually - be nonzero, but will accidentally be zero with P=2^-16. + The old Digest field is removed since sufficient information for + authentication is now included in the nonce part of the payload. - If the cell is recognized, the node moves to verifying the - authenticity of the message as follows(*): + The old 'Recognized' field is removed and the node always tries to + authenticate the message as follows: forward direction (executed by the end node): - T_{n+1} = Digest(Khf_n,T'_{n+1}||C_{n+1}) + T_{n+1} = Digest(Khf_n,C_{n+1}) Tag = T_{n+1} ^ D(Ktf_n,T_{n+1} ^ N_{n+1}) - T'_{n+1} = T_{n+1} - The message is authenticated (i.e., M = C_{n+1}) if - and only if Tag = 0 + The message is recognized and authenticated + (i.e., M = C_{n+1}) if and only if Tag = 0. backward direction (executed by the OP): - The message is authenticated (i.e., C_{n+1} = M) if - and only if N_{n+1} = 0 - - - The old Digest field is removed since sufficient information for - authentication is now included in the nonce part of the payload. + The message is recognized and authenticated + (i.e., C_{n+1} = M) if and only if N_{n+1} = 0. - (*) we should consider dropping the 'recognized' field - altogether and always try to authenticate. Note that this is - an optimization question and the crypto works just as well - either way. The 'Length' field of a relay cell contains the number of bytes in the relay payload which contain real payload data. The @@ -319,31 +305,30 @@ Status: Open Suppose that node I tags the ciphertext part of the message (C'_{I+1} != C_{I+1}) then forwards it to the next node (I+1). As per Section 3.1.2. Node I+1 digests C'_{I+1} to generate T_{I+1} - and N_{I+2}. Since C'_{I+2} is different than it should be, so - are the resulting T_{I+1} and N_{I+2}. Hence, decrypting C'_{I+2} + and N_{I+2}. Since C'_{I+2} is different from what it should be, so + are the resulting T_{I+1} and N_{I+2}. Hence, decrypting C'_{I+1} using these values results in a random string for C_{I+2}. Since C_{I+2} is now just a random string, it is decrypted into a - random string and cannot be 'recognized' nor - authenticated. Furthermore, since C'_{I+1} is different than what - it should be, T'_{I+1} (i.e., the running digest of the middle - node) is now out of sync with that of the OP, which means that - all future cells sent through this node will decrypt into garbage - (random strings). + random string and cannot be authenticated. Furthermore, since + C'_{I+1} is different than what it should be, Tf'_{I+1} + (i.e., the running digest of the middle node) is now out of sync + with that of the OP, which means that all future cells sent through + this node will decrypt into garbage (random strings). Likewise, suppose that instead of tagging the ciphertext, Node I - node tags the encrypted nonce N'_{I+1} != N_{I+1}. Now, when Node - I+1 digests the payload the tweak T_{I+1} is find, but using it + tags the encrypted nonce N'_{I+1} != N_{I+1}. Now, when Node + I+1 digests the payload the tweak T_{I+1} is fine, but using it to decrypt N'_{I+1} again results in a random nonce for N_{I+2}. This random nonce is used to decrypt C_{I+1} into a - random C'_{I+2} which is not recognized by the end node. Since - C_{I+2} is now a random string, the running digest of the end - node is now out of sync, which prevents the end node from + random C'_{I+2} which cannot be authenticated by the end node. Since + C_{I+2} is a random string, the running digest of the end node is + now out of sync with that of OP, which prevents the end node from decrypting further cells. 5.1.2. Backward direction In the backward direction the tagging is done by Node I+2 - untagging by the Node I. Suppose first that Node I+2 tags the + untagging by Node I. Suppose first that Node I+2 tags the ciphertext C_{I+2} and sends it to Node I+1. As per Section 3.2.1, Node I+1 first digests C_{I+2} and uses the resulting T_{I+1} to generate a nonce N_{I+1}. From this it is clear that diff --git a/proposals/302-padding-machines-for-onion-clients.txt b/proposals/302-padding-machines-for-onion-clients.txt new file mode 100644 index 0000000..4123e85 --- /dev/null +++ b/proposals/302-padding-machines-for-onion-clients.txt @@ -0,0 +1,301 @@ +Filename: 302-padding-machines-for-onion-clients.txt +Title: Hiding onion service clients using padding +Author: George Kadianakis, Mike Perry +Created: Thursday 16 May 2019 +Status: Closed +Implemented-In: 0.4.1.1-alpha + +NOTE: Please look at section 3 of padding-spec.txt now, not this document. + +0. Overview + + Tor clients use "circuits" to do anonymous communications. There are various + types of circuits. Some of them are for navigating the normal Internet, + others are for fetching Tor directory information, others are for connecting + to onion services, while others are simply for measurements and testing. + + It's currently possible for MITM type of adversaries (like tor-network-level + and local-area-network adversaries) to distinguish Tor circuit types from + each other using a wide array of metadata and distinguishers. + + In this proposal, we study various techniques that can be used to + distinguish client-side onion service circuits and provide WTF-PAD circuit + padding machines (using prop#254) to hide them against certain adversaries. + +1. Motivation + + We are writing this proposal for various reasons: + + 1) We believe that in an ideal setting MITM adversaries should not be able + to distinguish circuit types by inspecting traffic. Tor traffic should + look amorphous to an outside observer to maximize uncertainty and + anonymity properties. + + Client-side onion service circuits are an easy target for this proposal, + because we believe we can improve their privacy with low bandwidth + overhead. + + 2) We want to start experimenting with the WTF-PAD subsystem of Tor, and + this use-case provides us with a good testbed. + + 3) We hope that by actually starting to use the WTF-PAD subsystem of Tor, we + will encourage more researchers to start experimenting with it. + +2. Scope of the proposal [SCOPE] + + Given the above, this proposal sets forth to use the WTF-PAD system to hide + client-side onion service circuits against the classifiers of paper by Kwon + et al. above. + + By client-side onion service circuits we refer to these two types of circuits: + - Client-side introduction circuits: Circuit from client to the introduction point + - Client-side rendezvous circuits: Circuit from client to the rendezvous point + + Service-side onion service circuits are not in scope for this proposal, and + this is because hiding those would require more bandwidth and also more + advanced WTF-PAD features. + + Furthermore, this proposal only aims to cloak the naive distinguishing + features mentioned in the [KNOWN_DISTINGUISHERS] section, and can by no + means guarantee that client-side onion service circuits are totally + indistinguishable by other means. + + The machines specified in this proposal are meant to be lightweight and + created for a specific purpose. This means that they can be easily extended + with additional states to do more advanced hiding. + +3. Known distinguishers against onion service circuits [KNOWN_DISTINGUISHERS] + + Over the past years it's been assumed that motivated adversaries can + distinguish onion-service traffic from normal Tor traffic given their + special characteristics. + + As far as we know, there has been relatively little research-level work done + to this direction. The main article published in this area is the USENIX + paper "Circuit Fingerprinting Attacks: Passive Deanonymization of Tor Hidden + Services" by Kwon et al. [0] + + The above paper deals with onion service circuits in sections 3.2 and 5.1. + It uses the following three "naive" circuit features to distinguish circuits: + 1) Circuit construction sequence + 2) Number of incoming and outgoing cells + 3) Duration of Activity ("DoA") + + All onion service circuits have particularly loud signatures to the above + characteristics, but WTF-PAD (prop#254) gives us tools to effectively + silence those signatures to the point where the paper's classifiers won't + work. + +4. Hiding circuit features using WTF-PAD + + According to section [KNOWN_DISTINGUISHERS] there are three circuit features + we are attempting to hide. Here is how we plan to do this using the WTF-PAD + system: + + 1) Circuit construction sequence + + The USENIX paper uses the directions of the first 10 cells sent in a + circuit to fingerprint them. Client-side onion service circuits have + unique circuit construction sequences and hence they can be fingeprinted + using just the first 10 cells. + + We use WTF-PAD to destroy this feature of onion service circuits by + carefully sending padding cells (relay DROP cells) during circuit + construction and making them look exactly like most general tor circuits + up till the end of the circuit construction sequence. + + 2) Number of incoming and outgoing cells + + The USENIX paper uses the amount of incoming and outgoing cells to + distinguish circuit types. For example, client-side introduction circuits + have the same amount of incoming and outgoing cells, whereas client-side + rendezvous circuits have more incoming than outgoing cells. + + We use WTF-PAD to destroy this feature by changing the number of cells + sent in introduction circuits. We leave rendezvous circuits as is, since + the actual rendezvous traffic flow usually resembles well normal Tor + circuits. + + 3) Duration of Activity ("DoA") + + The USENIX paper uses the period of time during which circuits send and + receive cells to distinguish circuit types. For example, client-side + introduction circuits are really short lived, wheras service-side + introduction circuits are very long lived. OTOH, rendezvous circuits have + the same median lifetime as general Tor circuits which is 10 minutes. + + We use WTF-PAD to destroy this feature of client-side introduction + circuits by setting a special WTF-PAD option, which keeps the circuits + open for 10 minutes completely mimicking the DoA of general Tor circuits. + +4.1. A dive into general circuit construction sequences [CIRCCONSTRUCTION] + + In this section we give an overview of how circuit construction looks like + to a network or guard-level adversary. We use this knowledge to make the + right padding machines that can make intro and rend circuits look like these + general circuits. + + In particular, most general Tor circuits used to surf the web or download + directory information, start with the following 6-cell relay cell sequence (cells + surrounded in [brackets] are outgoing, the others are incoming): + + [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [BEGIN] -> CONNECTED + + When this is done, the client has established a 3-hop circuit and also + opened a stream to the other end. Usually after this comes a series of DATA + cell that either fetches pages, establishes an SSL connection or fetches + directory information: + + [DATA] -> [DATA] -> DATA -> DATA + + The above stream of 10 relay cells defines the grand majority of general + circuits that come out of Tor browser during our testing, and it's what we + are gonna use to make introduction and rednezvous circuits blend in. + + Please note that in this section we only investigate relay cells and not + connection-level cells like CREATE/CREATED or AUTHENTICATE/etc. that are + used during the link-layer handshake. The rationale is that connection-level + cells depend on the type of guard used and are not an effective fingerprint + for a network/guard-level adversary. + +5. WTF-PAD machines + + For the purposes of this proposal we will make use of four WTF-PAD machines + as follows: + + - Client-side introduction circuit hiding machine (origin-side) + - Client-side introduction circuit hiding machine (relay-side) + + - Client-side rendezvous circuit hiding machine (origin-side) + - Client-side rendezvous circuit hiding machine (relay-side) + + In the following sections we will analyze these machines. + +5.1. Client-side introduction circuit hiding machines [INTRO_CIRC_HIDING] + + These two machines are meant to hide client-side introduction circuits. The + origin-side machine sits on the client and sends padding towards the + introduction circuit, whereas the relay-side machine sits on the middle-hop + (second hop of the circuit) and sends padding towards the client. The + padding from the origin-side machine terminates at the middle-hop and does + not get forwarded to the actual introduction point. + + Both of these machines only get activated for introduction circuits, and + only after an INTRODUCE1 cell has been sent out. + + This means that before the machine gets activated our cell flow looks like this: + + [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [INTRODUCE1] + + Comparing the above with section [CIRCCONSTRUCTION], we see that the above + cell sequence matches the one from general circuits up to the first 7 cells. + + However, in normal introduction circuits this is followed by an + INTRODUCE_ACK and then the circuit gets teared down, which does not match + the sequence from [CIRCCONSTRUCTION]. + + Hence when our machine is used, after sending an [INTRODUCE1] cell, we also + send a [PADDING_NEGOTIATE] cell, which gets answered by a PADDING_NEGOTIATED + cell and an INTRODUCE_ACKED cell. This makes us match the [CIRCCONSTRUCTION] + sequence up to the first 10 cells. + + After that, we continue sending padding from the relay-side machine so as to + fake a directory download, or an SSL connection setup. We also want to + continue sending padding so that the connection stays up longer to destroy + the "Duration of Activity" fingerprint. + + To calculate the padding overhead, we see that the origin-side machine just + sends a single [PADDING_NEGOATIATE] cell, wheras the origin-side machine + sends a PADDING_NEGOTIATED cell and between 7 to 10 DROP cells. This means + that the average overhead of this machine is 11 padding cells. + + In terms of WTF-PAD terminology, these machines have three states (START, + OBF, END). They move from the START to OBF state when the first + non-padding cell is received on the circuit, and they stay in the OBF + state until all the padding gets depleted. The OBF state is controlled by + a histogram which specifies the parameters described in the paragraphs + above. After all the padding finishes, it moves to END state. + + We also set a special WTF-PAD flag which keeps the circuit open even after + the introduction is performed. In particular, with this feature the circuit + will stay alive for the same durations as normal web circuits before they + expire (usually 10 minutes). + +5.2. Client-side rendezvous circuit hiding machines + + The rendezvous circuit machines apply on client-side rendezvous circuits and + only after the rendezvous point has been established (REND_ESTABLISHED has + been received). Up to that point, the following cell sequence has been + observed on the circuit: + + [EXTEND2] -> EXTENDED2 -> [EXTEND2] -> EXTENDED2 -> [ESTABLISH_REND] -> REND_ESTABLISHED + + which matches the general circuit construction sequence [CIRCCONSTRUCTION] + up to the first 6 cells. However after that, normal rendezvous circuits + receive a RENDEZVOUS2 cell followed by a [BEGIN] and a CONNECTED, which does + not fit the circuit construction sequence we are trying to imitate. + + Hence our machine gets activated right after REND_ESTABLISHED is received, + and continues by sending a [PADDING_NEGOTIATE] and a [DROP] cell, before + receiving a PADDING_NEGOTIATED and a DROP cell, effectively blending into + the general circuit construction sequence on the first 10 cells. + + After that our machine gets deactivated, and we let the actual rendezvous + circuit shape the traffic flow. Since rendezvous circuits usually immitate + general circuits (their purpose is to surf the web), we can expect that they + will look alike. + + In terms of overhead, this machine is quite light. Both sides send 2 padding + cells, for a total of 4 padding cells. + +6. Overhead analysis + + Given the parameters above, intro circuit machines have an overhead of 11 + padding cells, and rendezvous circuit machines have an overhead of 4 + cpadding ells. . This means that for every intro and rendezvous circuit + there will be an overhead of 15 padding cells in average, which is about + 7.5kb. + + In the PrivCount paper [1] we learn that the Tor network sees about 12 + million successful descriptor fetches per day. We can use this figure to + assume that the Tor network also sees about 12 million intro and rendezvous + circuits per day. Given the 7.5kb overhead of each of these circuits, we get + that our padding machines infer an additional 94GB overhead per day on the + network, which is about 3.9GB per hour. + + XXX Isn't this kinda intense????? Using the graphs from metrics we see that + the Tor network has total capacity of 300 Gbit/s which is about 135000GB per + hour, so 3.9GB per hour is not that much, but still... + +7. Discussion + +7.1. Alternative approaches + + These machines try to hide onion service client-side circuits by obfuscating + their looks. This is a reasonable approach, but if the resulting circuits + look unlike any other Tor circuits, they would still be fingerprintable just + by that fact. + + Another approach we could take is make normal client circuits look like + onion service circuits, or just make normal clients establish fake onion + service circuits periodically. The hope here is that the adversary won't be + able to distinguish fake onion service circuits from real ones. This + approach has not been taken yet, mainly because it requires additional + WTF-PAD features and poses greater overhead risks. + +7.2. Future work + + As discussed in [SCOPE], this proposal only aims to hide some very specific + features of client-side onion service circuits. There is lots of work to be + done here to see what other features can be used to distinguish such + circuits, and also what other classifiers can be built using deep learning + and whatnot. + +--- + + [0]: https://www.usenix.org/node/190967 + https://blog.torproject.org/technical-summary-usenix-fingerprinting-paper + + [1]: "Understanding Tor Usage with Privacy-Preserving Measurement" + by Akshaya Mani, T Wilson-Brown, Rob Jansen, Aaron Johnson, and Micah Sherr + In Proceedings of the Internet Measurement Conference 2018 (IMC 2018). diff --git a/proposals/303-protover-removal-policy.txt b/proposals/303-protover-removal-policy.txt new file mode 100644 index 0000000..f6f30a8 --- /dev/null +++ b/proposals/303-protover-removal-policy.txt @@ -0,0 +1,62 @@ +Filename: 303-protover-removal-policy.txt +Title: When and how to remove support for protocol versions +Author: Nick Mathewson +Created: 21 May 2019 +Status: Draft + +1. Background + + With proposal 264, added support for "subprotocol versions" -- a + means to declare which features are required for participation in the + Tor network. We also created a mechanism (refined later in proposal + 297) for telling Tor clients and relays that they cannot participate + effectively in the Tor network, and they need to shut down. + + In this document, we describe a policy according to which these + decisions should be made in practice. + +2. Recommending features (for clients and relays) + + A subprotocol version SHOULD become recommended soon after all + release series that did not provide it become unsupported (within a + month or so). + + For example, the current oldest LTS release series is 0.2.9; when it + becomes unsupported in 2020, the oldest supported release series will + be 0.3.5. Suppose that 0.2.9 supports a subprotocol Cupcake=1, and + that all stable 0.3.5.x versions support Cupcake=1-3. Around one + month after the end of 0.2.9 support, Cupcake=3 should become a + _recommended_ protocol for clients and relays. + + Additionally, a feature can become _recommended_ because of security + reasons. If we believe that it is a terrible idea to run an old + protocol, we can make it _recommended_ for relays or clients or both. + We should not do this lightly, since it will be annoying. + +3. Requiring features (for relays) + + We regularly update the directory authorities to require relays to + run certain versions of Tor or later. We generally do this after a + short outreach campaign to get as many relays as possible to upgrade. + + We MAY make a feature required for relays one month after every + version without it is obsolete and unsupported, though it is better + to wait three months if possible. + + We SHOULD make a feature required for relays within 12 months after + every version without it is obsolete and unsupported. + +4. Requiring features (for clients) + + Clients take the longest time to update, and are often the least able + to fetch upgrades. Because of this, we should be very careful about + making subprotocol versions required on clients, and should only do + so for fairly compelling reasons. + + We SHOULD NOT make a feature required for clients until it has been + _recommended_ for clients for at first 9 months. + + We SHOULD make a feature required for clients if it has been + _recommended_ for clients for at least 18 months. + + diff --git a/proposals/304-socks5-extending-hs-error-codes.txt b/proposals/304-socks5-extending-hs-error-codes.txt new file mode 100644 index 0000000..56a3487 --- /dev/null +++ b/proposals/304-socks5-extending-hs-error-codes.txt @@ -0,0 +1,109 @@ +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 + +Note: We are extending SOCKS5 here but in terms, when Tor Browser supports + HTTPCONNECT, we should not do that anymore. + +0. Abstract + + We propose extending the SOCKS5 protocol to allow returning more meaningful + response failure onion service codes back to the client. + + This is inspired by proposal 229 [PROP229] minus the new authentication + method. + +1. Introduction + + The motivation behind this proposal is because we need a synchronous way to + return a reason on why the SOCKS5 connection failed. + + The alternative is to use a control port event but then the caller needs to + match the SOCKS failure to the control event. And tor provides no guarantee + that a control event will be emitted before the SOCKS failure or vice + versa. + + With this proposal, the client can get the reason on why the onion service + connection failed with the SOCKS5 returned error code. + +2. Proposal + +2.1. New SocksPort Flag + + In order to have backward compatibility with third party applications that + do not support the new proposed SOCKS5 error code, we propose a new + SocksPort flag that needs to be set in the tor configuration file in order + for those code to be sent back. + + The new SocksPort flag is: + + "ExtendedErrors" -- Tor will report new SOCKS5 error code detailed below + in section 2.2 (once merged, they will end up in + socks-extension.txt). + + It is possible that more codes will be added in the future so an + application using this flag should possibly expect unknown codes to be + returned. + +2.2. Onion Service Extended SOCKS5 Error Code + + We introduce the following additional SOCKS5 reply codes to be sent in the + REP field of a SOCKS5 message iff the "ExtendedErrors" on the SocksPort is + set (see section 2.1 above). + + The SOCKS5 specification [RFC1928] defines a range of code that are + "unassigned" so we'll be using those on the far end of the range in order + to inform the client of onion service failures: + + Where: + + * X'F0' Onion Service Descriptor Can Not be Found + + The requested onion service descriptor can't be found on the hashring + and thus not reachable by the client. + + * X'F1' Onion Service Descriptor Is Invalid + + The requested onion service descriptor can't be parsed or signature + validation failed. + + * X'F2' Onion Service Introduction Failed + + Client failed to introduce to the service meaning the descriptor was + found but the service is not anymore at the introduction points. The + service has likely changed its descriptor or is not running. + + * X'F3' Onion Service Rendezvous Failed + + Client failed to rendezvous with the service which means that the client + is unable to finalize the connection. + + * X'F4' Onion Service Missing Client Authorization + + Tor was able to download the requested onion service descriptor but is + unable to decrypt its content because it is missing client authorization + information for it. + + * X'F5' Onion Service Wrong Client Authorization + + Tor was able to download the requested onion service descriptor but is + unable to decrypt its content using the client authorization information + it has. This means the client access were revoked. + +3. Compatibility + + No new field or extension has been added. Only new code values from the + unassigned range are being used. We expect these to not be a problem for + backward compatibility. + + These codes are only sent back if the new proposed SocksPort flag, + "ExtendedErrors", is set and making it easier for backward and foward + compatibility. + +References: + +[PROP229] https://gitweb.torproject.org/torspec.git/tree/proposals/229-further-socks5-extensions.txt + +[RFC1928] https://www.ietf.org/rfc/rfc1928.txt diff --git a/proposals/305-establish-intro-dos-defense-extention.txt b/proposals/305-establish-intro-dos-defense-extention.txt new file mode 100644 index 0000000..ffa8a2c --- /dev/null +++ b/proposals/305-establish-intro-dos-defense-extention.txt @@ -0,0 +1,197 @@ +Filename: 305-establish-intro-dos-defense-extention.txt +Title: ESTABLISH_INTRO Cell DoS Defense Extension +Author: David Goulet, George Kadianakis +Created: 06-June-2019 +Status: Draft + +0. Abstract + + We propose introducing a new cell extension to the onion service version 3 + ESTABLISH_INTRO cell in order for a service operator to send directives to + the introduction point. + +1. Introduction + + The idea behind this proposal is to provide a way for a service operator to + give to the introduction points Denial of Service (DoS) defense parameters + through the ESTABLISH_INTRO cell. + + We are currently developing onion service DoS defenses at the introduction + point layer which for now has consensus parameter values for the defenses' + knobs. This proposal would allow the service operator more flexibility for + tuning these knobs and/or future parameters. + +2. ESTABLISH_INTRO Cell DoS Extention + + We introduce a new extention to the ESTABLISH_INTRO cell. The EXTENSIONS + field will be leveraged and a new protover will be introduced to reflect + that change. + + As a reminder, this is the content of an ESTABLISH_INTRO cell (taken from + rend-spec-v3.txt section 3.1.1): + + AUTH_KEY_TYPE [1 byte] + AUTH_KEY_LEN [2 bytes] + AUTH_KEY [AUTH_KEY_LEN bytes] + N_EXTENSIONS [1 byte] + N_EXTENSIONS times: + EXT_FIELD_TYPE [1 byte] + EXT_FIELD_LEN [1 byte] + EXT_FIELD [EXT_FIELD_LEN bytes] + HANDSHAKE_AUTH [MAC_LEN bytes] + SIG_LEN [2 bytes] + SIG [SIG_LEN bytes] + + We propose a new EXT_FIELD_TYPE value: + + [01] -- DOS_PARAMETERS. + + If this flag is set, the extension should be used by the + introduction point to learn what values the denial of service + subsystem should be using. + + The EXT_FIELD content format is: + + N_PARAMS [1 byte] + N_PARAMS times: + PARAM_TYPE [1 byte] + PARAM_VALUE [8 byte] + + The PARAM_TYPE proposed values are: + + [01] -- DOS_INTRODUCE2_RATE_PER_SEC + The rate per second of INTRODUCE2 cell relayed to the service. + + [02] -- DOS_INTRODUCE2_BURST_PER_SEC + The burst per second of INTRODUCE2 cell relayed to the service. + + The PARAM_VALUE size is 8 bytes in order to accomodate 64bit values + (uint64_t). It MUST match the specified limit for the following PARAM_TYPE: + + [01] -- Min: 0, Max: 2147483647 + [02] -- Min: 0, Max: 2147483647 + + A value of 0 means the defense is disabled. If the rate per second is set + to 0 (param 0x01) then the burst value should be ignored. And vice-versa, + if the burst value is 0 (param 0x02), then the rate value should be + ignored. In other words, setting one single parameter to 0 disables the + INTRODUCE2 rate limiting defense. + + The burst can NOT be smaller than the rate. If so, the parameters should be + ignored by the introduction point. + + The maximum is set to INT32_MAX meaning (2^31 - 1). Our consensus + parameters are capped to that limit and these parameters happen to be also + consensus parameters as well hence the common limit. + + Any valid value does have precedence over the network wide consensus + parameter. + + This will increase the payload size by 21 bytes: + + This extension type and length is 2 extra bytes, the N_EXTENSIONS field + is always present and currently set to 0. + + Then the EXT_FIELD is 19 bytes because one parameter is 9 bytes so for + two parameters, it is 18 bytes plus 1 byte for the N_PARAMS for a total + of 19. + + The ESTABLISH_INTRO v3 cell currently uses 134 bytes for its payload. With + this increase, 343 bytes remain unused (498 maximum payload size minus 155 + bytes new payload). + +3. Protocol Version + + We introduce a new protocol version in order for onion service that wants + to specifically select introduction points supporting this new extension. + But also, it should be used to know when to send this extension or not. + + The new version for the "HSIntro" protocol is: + + "5" -- support ESTABLISH_INTRO cell DoS parameters extension for onion + service version 3 only. + +4. Configuration Options + + We also propose new torrc options in order for the operator to control + those values passed through the ESTABLISH_INTRO cell. + + "HiddenServiceEnableIntroDoSDefense 0|1" + + If this option is set to 1, the onion service will always send to an + introduction point, supporting this extension (using protover), the + denial of service defense parameters regardless if the consensus + enables them or not. The values are taken from + HiddenServiceEnableIntroDoSRatePerSec and + HiddenServiceEnableIntroDoSBurstPerSec torrc option. + (Default: 0) + + "HiddenServiceEnableIntroDoSRatePerSec N sec" + + Controls the introduce rate per second the introduction point should + impose on the introduction circuit. The default values are only used + if the consensus param is not set. + (Default: 25, Min: 0, Max: 4294967295) + + "HiddenServiceEnableIntroDoSBurstPerSec N sec" + + Controls the introduce burst per second the introduction point should + impose on the introduction circuit. The default values are only used + if the consensus param is not set. + (Default: 200, Min: 0, Max: 4294967295) + + They respectively control the parameter type 0x01 and 0x02 in the + ESTABLISH_INTRO cell detailed in section 2. + + The default values of the rate and burst are taken from ongoing anti-DoS + implementation work [1][2]. They aren't meant to be defined with this + proposal. + +5. Security Considerations + + Using this new extension leaks to the introduction point the service's tor + version. This could in theory help any kind of de-anonymization attack on a + service since at first it partitions it in a very small group of running + tor. + + Furthermore, when the first tor version supporting this extension will be + released, very few introduction points will be updated to that version. + Which means that we could end up in a situation where many services want to + use this feature and thus will only select a very small subset of relays + supporting it overloading them but also making it an easier vector for an + attacker that whishes to be the service introduction point. + + For the above reasons, we propose a new consensus parameter that will + provide a "go ahead" for all service out there to start using this + extension only if the introduction point supports it. + + "HiddenServiceEnableIntroDoSDefense" + + If set to 1, this makes tor start using this new proposed extension + if available by the introduction point (looking at the new protover). + + This parameter should be switched on when a majority of relays have + upgraded to a tor version that supports this extension for which we believe + will also give enough time for most services to move to this new stable + version making the anonymity set much bigger. + + We believe that there are services that do not care about anonymity on the + service side and thus could benefit from this feature right away if they + wish to use it. + +5. Discussions + + One possible new avenue to explore is for the introduction point to send + back a new type of cell which would tell the service that the DoS defenses + have been triggered. It could include some statistics in the cell which can + ultimately be reported back to the service operator to use those for better + decisions for the parameters. + + But also for the operator to be noticed that their service is under attack + or very popular which could mean time to increase or disable the denial of + service defenses. + +References: + +[1] https://lists.torproject.org/pipermail/tor-dev/2019-May/013837.html +[2] https://trac.torproject.org/15516 diff --git a/proposals/306-ipv6-happy-eyeballs.txt b/proposals/306-ipv6-happy-eyeballs.txt new file mode 100644 index 0000000..a096384 --- /dev/null +++ b/proposals/306-ipv6-happy-eyeballs.txt @@ -0,0 +1,300 @@ +Filename: 306-ipv6-happy-eyeballs.txt +Title: A Tor Implementation of IPv6 Happy Eyeballs +Author: Neel Chauhan +Created: 25-Jun-2019 +Supercedes: 299 +Status: Open +Ticket: https://trac.torproject.org/projects/tor/ticket/29801 + +1. Introduction + + As IPv4 address space becomes scarce, ISPs and organizations will deploy + IPv6 in their networks. Right now, Tor clients connect to guards using + IPv4 connectivity by default. + + When networks first transition to IPv6, both IPv4 and IPv6 will be enabled + on most networks in a so-called "dual-stack" configuration. This is to not + break existing IPv4-only applications while enabling IPv6 connectivity. + However, IPv6 connectivity may be unreliable and clients should be able + to connect to the guard using the most reliable technology, whether IPv4 + or IPv6. + + In ticket #27490, we introduced the option ClientAutoIPv6ORPort which + lets a client randomly choose between IPv4 or IPv6. However, this + random decision does not take into account unreliable connectivity + or falling back to the competing IP version should one be unreliable + or unavailable. + + One way to select between IPv4 and IPv6 on a dual-stack network is a + so-called "Happy Eyeballs" algorithm as per RFC 8305. In one, a client + attempts the preferred IP family, whether IPv4 or IPv6. Should it work, + the client sticks with the preferred IP family. Otherwise, the client + attempts the alternate version. This means if a dual-stack client has + both IPv4 and IPv6, and IPv6 is unreliable, preferred or not, the + client uses IPv4, and vice versa. However, if IPv4 and IPv6 are both + equally reliable, and IPv6 is preferred, we use IPv6. + + In Proposal 299, we have attempted a IP fallback mechanism using failure + counters and preferring IPv4 and IPv6 based on the state of the counters. + However, Prop299 was not standard Happy Eyeballs and an alternative, + standards-compliant proposal was requested in [P299-TRAC] to avoid issues + from complexity caused by randomness. + + This proposal describes a Tor implementation of Happy Eyeballs and is + intended as a successor to Proposal 299. + +2. Address/Relay Selection + + This section describes the necessary changes for address selection to + implement Prop306. + +2.1. Extend Info Structure Changes + + To be able to handle Happy Eyeballs in Tor, we will need to modify the + data structures used for connections to guards, namely the extend info + structure. + + The extend info structure should contain both an IPv4 and an IPv6 address. + This will allow us to try IPv4 and the IPv6 addresses should both be + available on a relay and the client is dual-stack. + + When parsing relay descriptors and filling in the extend info data + structure, we need to fill in both the IPv4 and IPv6 address if they both + are available. If only one family is available for a relay (IPv4 or IPv6), + we should fill in the address for preferred family and leave the alternate + family null. + +2.2. Relay Selection Changes + + In Proposal 283, we have allowed microdescriptor consensus documents to + contain IPv6 addresses. As clients download microdescriptors, Prop283 + makes it possible to implement Prop306. + + When we select candidates for the entry guard, we should select at least + one relay with an IPv6 address. This makes it possible for an IPv6-only + client to bootstrap. Otherwise we would have failures if all the selected + guard candidates only have IPv4 addresses. + +3. Relay Connections + + If there is an existing authenticated connection, we should use it + similar to how we used it pre-Prop306. + + If there is no existing authenticated connection for an extend info, + we should attempt to connect using the first available, allowed, and + preferred address. + + We should also allow falling back to the alternate address. For this, + three alternate designs will be given. + +3.1. Proposed Designs + + This subsection will have three proposed designs for connecting to relays + via IPv4 and IPv6 in a Tor implementation of Happy Eyeballs. + + These proposed designs will have some tradeoffs, including: + + * Launching multiple TCP connections places up to 2x extra socket load on + dual-stack relays and authorities, because both connections may succeed. + + * Launching multiple TLS connections places up to 2x the CPU load on + dual-stack relays and authorities, because both connections may succeed. + + * Increasing the delay between connections mitigates the above issues, + but reduces perceived performance, particularly at bootstrap time + (pre-emptive circuits hide these delays after bootstrap). + + The proposed designs are as listed as follows: + + * Section 3.1.1: First Successful Authentication + + * Section 3.1.2: TCP Connection to Preferred Address On First Authenticated + Connection + + * Section 3.1.3: TCP Connection to Preferred Address On First TCP Success + +3.1.1. First Successful Authentication + + In this design, Tor will first connect to the preferred address and + attempt to authenticate. After a 1.5 second delay (based on Onionperf + data), Tor will connect to the alternate address and try to authenticate. + On the first successful authenticated connection, we close the other + connection. + + This design places the least connection load on the network, but might + add extra TLS load. + +3.1.2. TCP Connection to Preferred Address On First Authenticated Connection + + This design attempts a TCP connection to a preferred address. On a failure + or a 1.5 second delay, we try the alternative address. + + On the first successful TCP connection Tor attempts to authenticate + immediately. On the first authentication success, Tor closes the other + connection. + + This design is the most reliable for clients, but increases the connection + load on dual-stack guards and authorities. For instance, this can be used + to amplify a DoS attack on the Tor network. + +3.1.3. TCP Connection to Preferred Address On First TCP Success + + In this design, we will connect via TCP to the first preferred address. On + a failure or after a 1.5 second delay, we attempt to connect via TCP to the + alternate address. On a success, Tor attempts to authenticate and closes + the other connection. + + This design is the closest to RFC 8305 and is similar to how Happy Eyeballs + is implemented in a web browser. + +3.2. Recommendations for Implementation of Section 3.1 Proposals + + We should start with implementing and testing the implementation as + described in Section 3.1.1 (First Successful Authentication), and then + doing the same for the implementations described in 3.1.2 and 3.1.3 if + desired or required. + +3.3. Handling Connection Successes And Failures + + Should a connection to a guard succeed and is authenticated via TLS, we + can then use the connection. In this case, we should cancel all other + connection timers and in-progress connections. Cancelling the timers is + necessary so we don't attempt new unnecessary connections when our + existing connection is successful, preventing denial-of-service risks. + + However, if we fail all available and allowed connections, we should tell + the rest of Tor that the connection has failed. This is so we can attempt + another guard relay. + +3.4. Connection Attempt Delays + + As mentioned in [TEOR-P306-REP], initially, clients should prefer IPv4 + by default. The Connection Attempt Delay, or delay between IPv4 and IPv6 + connections should be 1.5 seconds. This is to avoid the overhead from + tunneled IPv6 connections. + + The Minimum Connection Attempt Delay should not be dynamically adjusted + as it adds privacy risks. This value should be fixed at 10 ms as per + RFC 8305 and could be adjusted using a proposed consensus parameter called + ConnectionAttemptDelay. ConnectionAttemptDelay should be in milliseconds. + + The Maximum Connection Attempt Delay should also not be dynamically adjusted + for privacy reasons, but the maximum should be higher than the RFC 8305 + recommendation of 2 seconds. For Tor, we should make this timeout value 30 + seconds to match Tor's existing timeout. + + We should also make it possible for users to set the Maximum Connection + Attempt value higher for slower and higher-latency networks such as dial-up + and satellite. + +4. Option Changes + + As we enable IPv6-enabled clients to connect out of the box, we should + adjust the default options to enable IPv6 while not breaking IPv4-only + clients. + +4.1. New Default Options for Prop306 + + The new default options should be: + + * ClientUseIPv4 as 1 (to enable IPv4) + + * ClientUseIPv6 as 1 (to enable IPv6) + + * ClientPreferIPv6ORPort as 0 (for load-balancing reasons so we don't + overload IPv6-only guards) + + One thing to note is that clients should be able to connect with the above + options on IPv4-only, dual-stack, and IPv6-only networks, and they should + also work if ClientPreferIPv6ORPort is 1. This means we shouldn't expect + IPv4 or IPv6 to work if ClientUseIPv4 or ClientUseIPv6 is set. + + When the majority of clients are IPv6-capable, we could set the default + value of ClientPreferIPv6ORPort to 1 in order to take advantage of IPv6. + +4.2. Prop306 Consensus Parameters + + We could have the following consensus parameters: + + * ClientUseIPv6 + + * ClientPreferIPv6ORPort (when most of the guards have IPv6 and it is fast) + + Should we have the consenus parameters, the values for these options should + be set to the values of the similarly-named options as described in Section + 4.1 including the consideration for ClientPreferIPv6ORPort. + +5. Statistics + +5.1. Relay Statistics + + Relays could measure the number of successful IPv4 and IPv6 connections. + We could also send this information to directory authorities. + + However, should we implement Section 5.1, we should consider the privacy + implications of these statistics, and whether they should be public or not. + +5.2. Client Heartbeat Messages + + In a Tor session, we should count the number of IPv4 and IPv6 connections + to ORPorts, and distinguish between authenticated (relay, authority + reachability) and unauthenticated (client, bridge) connections. These + statistics should be included in the Heartbeat logs. + +6. Deploying Prop306 + + This section describes the information necessary for deployment of Prop306 + on Tor clients and in Tor Browser. + +6.1. Initial Feasibility Testing + + We should test this proposal with the following scenarios: + + * Different combinations of values for the options ClientUseIPv4, + ClientUseIPv6, and ClientPreferIPv6ORPort on IPv4-only, IPv6-only, + and dual-stack connections + + * Dual-stack connections of different technologies, including high-bandwidth + and low-latency (e.g. fiber), moderate-bandwidth and moderate-latency + (e.g. DSL, LTE), and high-latency and low-bandwidth (e.g. satellite, + dial-up) to see if Prop306 is reliable and feasible + +6.2. Minimum Viable Prop306 Product + + The mimumum viable product for Prop306 must include the following: + + * Implementation of one of the algorithms in Section 3.1 along with the + changes described in Sections 2.1 and 2.2 + + * The Connection Success/Failure mechanism in Section 3.3 and Connection + Delay mechanism in Section 3.4 (the consensus parameter is optional) + + * A default setup capable of both IPv4 and IPv6 connections with the + options described in Section 4.1 + +6.3. Optional Features + + Some features which are optional include: + + * Consensus Parameter ConnectionAttemptDelay (Section 3.4) - We will need + this if the Minimum Connection Attempt Delay needs to be dynamically + adjusted + + * Consensus Parameters ClientUseIPv6 (Section 4.2), and + ClientPreferIPv6ORPort (Section 4.2) - We will need this if we desire + the ability for clients to prefer IPv6 when the majority of clients + and relays are IPv6-capable without changing the configuration + + * Prop306 Statistics (Section 5) - While optional, this may be useful for + debugging and reliability testing, and metrics on IPv4 vs. IPv6 + +7. Acknowledgments + + Thank you so much to teor for the discussion of the happy eyeballs proposal. + I wouldn't have been able to do this has it not been for your help. + +8. Refrences + + [P299-TRAC]: https://trac.torproject.org/projects/tor/ticket/29801 + + [TEOR-P306-REP]: https://lists.torproject.org/pipermail/tor-dev/2019-July/013919.html diff --git a/proposals/307-onionbalance-v3.txt b/proposals/307-onionbalance-v3.txt new file mode 100644 index 0000000..8716f13 --- /dev/null +++ b/proposals/307-onionbalance-v3.txt @@ -0,0 +1,180 @@ +Filename: 307-onionbalance-v3.txt
+Title: Onion Balance Support for Onion Service v3
+Author: Nick Mathewson
+Created: 03-April-2019
+Status: Draft
+
+0. Draft Notes
+
+ 2019-07-25:
+
+ At this point in time, the cross-certification is not implemented
+ correctly in >= tor-0.3.2.1-alpha. See https://trac.torproject.org/29583
+ for more details.
+
+ This proposal assumes that this bug is fixed.
+
+1. Introduction
+
+ The OnionBalance tool allows several independent Tor instances to host an
+ onion service, while clients can access that onion service without having
+ to take its distributed status into account. OnionBalance works by having
+ each instance run a separate onion service. Then, a management server
+ periodically downloads the descriptors from those onion services, and
+ generates a new descriptor containing the introduction points from each
+ instance's onion service.
+
+ OnionBalance is used by several high-profile onion services, including
+ Facebook and The Tor Project.
+
+ Unfortunately, because of the cross-certification features in v3 onion
+ services, OnionBalance no longer works for them. To a certain extent, this
+ breakage is because of a security improvement: It's probably a good thing
+ that random third parties can no longer grab a onion service's introduction
+ points and claim that they are introduction points for a different service.
+ But nonetheless, a lack of a working OnionBalance remains an obstacle for
+ v3 onion service migration.
+
+ This proposal describes extensions to v3 onion service design to
+ accommodate OnionBalance.
+
+2. Background and Solution
+
+ If an OnionBalance management server wants to provide an aggregate
+ descriptor for a v3 onion service, it faces several obstacles that it
+ didn't have in v2.
+
+ When the management server goes to construct an aggregated descriptor, it
+ will have a mismatch on the "auth-key", "enc-key-cert", and
+ "legacy-key-cert" fields: these fields are supposed to certify the onion
+ service's current descriptor-signing key, but each of these keys will be
+ generated independently by each instance. Because they won't match each
+ other, there is no possible key that the aggregated descriptor could use
+ for its descriptor signing key.
+
+ In this design, we require that each instance should know in advance about
+ a descriptor-signing public key that the aggregate descriptor will use for
+ each time period. (I'll explain how they can do this later, in section 3
+ below.) They don't have to know the corresponding private key.
+
+ When generating their own onion service descriptors for a given time
+ period, the instances generate these additional fields to be used for the
+ aggregate descriptor:
+
+ "meta-auth-key"
+ "meta-enc-key-cert"
+ "meta-legacy-key-cert"
+
+ These fields correspond to "auth-key", "enc-key-cert", and
+ "legacy-key-cert" respectively, but differ in one regard: the
+ descriptor-signing public key that they certify is _not_ the instance's own
+ descriptor-signing key, but rather the aggregate public key for the time
+ period.
+
+ Ordinary clients ignore these new fields.
+
+ When the management server creates the aggregate descriptor, it checks that
+ the signing key for each of these "meta" fields matches the signing key for
+ its corresponding non-"meta" field, and that they certify the correct
+ descriptor-signing key-- and then uses these fields in place of their
+ corresponding non-"meta" variants.
+
+2.1. A quick note on synchronization
+
+ In the design above, and in the section below, I frequently refer to "the
+ current time period". By this, I mean the time period for which the
+ descriptor is encoded, not the time period in which it is generated.
+
+ Instances and management servers should generate descriptors for the two
+ closest time periods, as they do today: no additional synchronization
+ should needed here.
+
+3. How to distribute descriptor-signing keys
+
+ The design requires that every instance of the onion service knows about
+ the public descriptor-signing key that will be used for the aggregate onion
+ service. Here I'll discuss how this can be achieved.
+
+3.1. If the instances are trusted.
+
+ If the management server trusts each of the instances, it can distribute a
+ shared secret to each one of them, and use this shared secret to derive
+ each time period's private key.
+
+ For example, if the shared secret is SK, then the private descriptor-
+ signing key for each time period could be derived as:
+
+ H("meta-descriptor-signing-key-deriv" |
+ onion_service_identity
+ INT_8(period_num) |
+ INT_8(period_length) |
+ SK )
+
+ (Remember that in the terminology of rend-spec-v3, INT_8() denotes a 64-bit
+ integer, see section 0.2 in rend-spec-v3.txt.)
+
+ If shared secret is ever compromised, then an attacker can impersonate the
+ onion service until the shared secret is changed, and can correlate all
+ past descriptors for the onion service.
+
+3.2. If the instances are not trusted: Option One
+
+ If the management server does not trust the instances with
+ descriptor-signing public keys, another option for it is to simply
+ distribute a load of public keys in advance, and use them according to a
+ schedule.
+
+ In this design, the management server would pre-generate the
+ "descriptor-signing-key-cert" fields for a long time in advance, and
+ distribute them to the instances offline. Each one would be
+ associated with its corresponding time period.
+
+ If these certificates were revealed to an attacker, the attacker
+ could correlate descriptors for the onion service with one another,
+ but could not impersonate the service.
+
+3.3. If the instances are not trusted: Option Two
+
+ Another option for the trust model of 3.2 above is to use the same
+ key-blinding method as used for v3 onion services. The management server
+ would hold a private descriptor-signing key, and use it to derive a
+ different private descriptor-signing key for each time period. The instance
+ servers would hold the corresponding public key, and use it to derive a
+ different public descriptor-signing key for each time period.
+
+ (For security, the key-blinding function in this case should use a
+ different nonce than used in the)
+
+ This design would allow the instances to only be configured once, which
+ would be simpler than 3.2 above-- but at a cost. The management server's
+ use of a long-term private descriptor-signing key would require it to keep
+ that key online. (It could keep the derived private descriptor-signing keys
+ online, but the parent key could be derived from them.)
+
+ Here, if the instance's knowledge were revealed to an attack, the attacker
+ could correlate descriptors for the onion service with one another, but
+ could not impersonate the service.
+
+4. Some features of this proposal
+
+ We retain the property that each instance service remains accessible as a
+ working onion service. However, anyone who can access it can identify it as
+ an instance of an OnionBalance service, and correlate its descriptor to the
+ aggregate descriptor.
+
+ Instances could use client authorization to ensure that only the management
+ server can decrypt their introduction points. However, because of the
+ key-blinding features of v3 onion services, nobody who doesn't know the
+ onion addresses for the instances can access them anyway: It would be
+ sufficient to keep these addresses secret.
+
+ Although anybody who successfully accesses an instance can correlate its
+ descriptor to the meta-descriptor, this only works for two descriptors
+ within a single time period: You can't match an instance descriptor from
+ one time period to a meta-descriptor from another.
+
+A. Acknowledgments
+
+ Thanks to the network team for helping me clarify my ideas here, explore
+ options, and better understand some of the implementations and challenges
+ in this problem space.
diff --git a/proposals/308-counter-galois-onion.txt b/proposals/308-counter-galois-onion.txt new file mode 100644 index 0000000..e311c0c --- /dev/null +++ b/proposals/308-counter-galois-onion.txt @@ -0,0 +1,550 @@ +Filename: 308-counter-galois-onion.txt +Title: Counter Galois Onion: A New Proposal for Forward-Secure Relay Cryptography +Authors: Jean Paul Degabriele, Alessandro Melloni, Martijn Stam +Created: 13 Sep 2019 +Last-Modified: 13 Sep 2019 +Status: Draft + + + +1. Background and Motivation + + In Proposal 202, Mathewson expressed the need to update Tor's Relay + cryptography and protect against tagging attacks. Towards this goal he + outlined two possible approaches for constructing an onion encryption + scheme that should be able to withstand tagging attacks. Later, in + Proposal 261, Mathewson proposed a concrete scheme based on the + tweakable wide-block cipher AEZ. The security of Proposal 261 was + analysed in [DS18]. An alternative scheme was suggested in Proposal 295 + which combines an instantiation of the PIV construction from [ST14] and + a variant of the GCM-RUP construction from [ADL17]. In this document we + propose yet another scheme, Counter Galois Onion (CGO) + which improves over proposals 261 and 295 in a number of ways. CGO has + a minimalistic design requiring only a block cipher in counter-mode and + a universal hash function. To take advantage of Intel's AES-NI and + PCLMULQDQ instructions we recommend using AES and POLYVAL [GLL18]. In + terms of security, it protects against tagging attacks while + simultaneously providing forward security with respect to end-to-end + authenticity and confidentiality. Furthermore CGO performs better than + proposal 295 in terms of efficiency and its support of "leaky pipes". + + +1.2 Design Overview + + CGO makes due with a universal hash function while simultaneously + satisfying forward security. It employs two distinct types of + encryption, a dynamic encryption scheme DEnc and a static encryption + scheme SEnc. DEnc is used for end-to-end encryption (layer n) and SEnc + is used for the intermediate layers (n-1 to 1). DEnc is a Forward- + Secure Authenticated Encryption scheme for securing end-to-end + communication and SEnc provides the non-malleability for protecting + against tagging attacks. In order to provide forward security, the key + material in DEnc is updated with every encryption whereas in SEnc the + key material is static. To support leaky pipes, in the forward + direction each OR first attempts a partial decryption using DEnc and + if it fails it reverts to decrypting using SEnc. The rest of the + document describes the scheme's operation in terms of the low-level + primitives and we make no further mention of DEnc and SEnc. However, + on an intuitive level it can be helpful to think of: + + a) the combinations of E(KSf_I, *) and PH(HSf_I, *) as well as + E(KDf_I, *) and PH(HDf_I, *) as two instances of a tweakable block + cipher, + + b) the operation E(Sf_I, <0>) | E(Sf_I, <1>) | E(Sf_I, <2>) | ... as a + PRG with seed Sf_I, + + c) and E(JSf_I, <IV>) | E(JSf_I, <IV+1>) | ... | E(JSf_I, <IV+31>) as + counter-mode encryption with <IV> as the initial vector. + + +2. Preliminaries + +2.1. Notation + + Symbol Meaning + ------ ------- + M Plaintext + Sf_I PRG Seed, forward direction, layer I + Sb_I PRG Seed, backward direction, layer I + Cf_I Ciphertext, forward direction, layer I + Cb_I Ciphertext, backward direction, layer I + Tf_I Tag, forward direction, layer I + LTf_I Last Tag, forward direction, layer I + Tb_I Tag, backward direction, layer I + LTb_I Last Tag, backward direction, layer I + Nf_I Nonce, forward direction, layer I + LNf_I Last Nonce, forward direction, layer I + Nb_I Nonce, backward direction, layer I + LNb_I Last Nonce, backward direction, layer I + JSf_I Static Block Cipher Key, forward direction, layer I + JSb_I Static Block Cipher Key, backward direction, layer I + KSf_I Static Block Cipher Key, forward direction, layer I + KSb_I Static Block Cipher Key, backward direction, layer I + KDf_I Dynamic Block Cipher Key, forward direction, layer I + KDb_I Dynamic Block Cipher Key, backward direction, layer I + HSf_I Static Poly-Hash Key, forward direction, layer I + HSb_I Static Poly-Hash Key, backward direction, layer I + HDf_I Dynamic Poly-Hash Key, forward direction, layer I + HDb_I Dynamic Poly-Hash Key, backward direction, layer I + ^ Bitwise XOR operator + | Concatenation + && Logical AND operator + Z[a, b] For a string Z, the substring from byte a to byte b + (indexing starts at 1) + INT(X) Translate string X into an unsigned integer + +2.2. Security parameters + + POLY_HASH_LEN -- The length of the polynomial hash function's output, + in bytes. For POLYVAL, POLY_HASH_LEN = 16. + + PAYLOAD_LEN -- The longest allowable cell payload, in bytes (509). + + HASH_KEY_LEN -- The key length used to digest messages in bytes. + For POLYVAL, DIG_KEY_LEN = 16. + + BC_KEY_LEN -- The key length, in bytes, of the block cipher used. For + AES we recommend ENC_KEY_LEN = 16. + + BC_BLOCK_LEN -- The block length, in bytes, of the block cipher used. + For AES, BC_BLOCK_LEN = 16. + +2.3. Primitives + + 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-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. + +2.4 Key derivation and initialisation (replaces Section 5.2.2) + + For newer KDF needs, Tor uses the key derivation function HKDF from + RFC5869, instantiated with SHA256. (This is due to a construction + from Krawczyk.) The generated key material is: + + K = K_1 | K_2 | K_3 | ... + + Where H(x, t) is HMAC_SHA256 with value x and key t + and K_1 = H(m_expand | INT8(1) , KEY_SEED ) + and K_(i+1) = H(K_i | m_expand | INT8(i+1) , KEY_SEED ) + and m_expand is an arbitrarily chosen value, + and INT8(i) is an octet with the value "i". + + In RFC5869's vocabulary, this is HKDF-SHA256 with info == m_expand, + salt == t_key, and IKM == secret_input. + +2.4.1. Key derivation using the KDF + + When used in the ntor handshake, for each layer I, the key material is + split into the following sequence of contiguous values: + + Length Purpose Notation + ------ ------- -------- + BC_KEY_LEN forward Seed Sf_I + BC_KEY_LEN backward Seed Sb_I + + if (I < n) in addition derive the following static keys: + + BC_KEY_LEN forward BC Key KSf_I + BC_KEY_LEN backward BC Key KSb_I + BC_KEY_LEN forward CTR Key JSf_I + BC_KEY_LEN backward CTR Key JSb_I + HASH_KEY_LEN forward poly hash key HSf_I + HASH_KEY_LEN backward poly hash key HSb_I + + Excess bytes from K are discarded. + +2.4.2. Initialisation from Seed + + For each layer I compute E(Sf_I, <0>) | E(Sf_I, <1>) | E(Sf_I, <2>) | ... + and parse the output as: + + Length Purpose Notation + ------ ------- -------- + BC_BLOCK_LEN forward Nonce Nf_I + BC_KEY_LEN forward BC Key KDf_I + HASH_KEY_LEN forward poly hash key HDf_I + BC_KEY_LEN new forward Seed Sf'_I + + Discard excess bytes, replace Sf_I with Sf'_I, and set LNf_n and LTf_I + to the zero string. + + Similarly for the backward direction, compute E(Sb_I, <0>) | E(Sb_I, <1>) + | E(Sb_I, <2>) | ... and parse the output as: + + Length Purpose Notation + ------ ------- -------- + BC_BLOCK_LEN backward Nonce Nb_I + BC_KEY_LEN forward BC Key KDb_I + HASH_KEY_LEN forward poly hash key HDb_I + BC_KEY_LEN new backward Seed Sb'_I + + Discard excess bytes, replace Sb_I with Sb'_I, and set LNb_n and LTb_I + to the zero string. + + NOTE: For layers n-1 to 1 the values Nf_I, KDf_I, HDf_I, Sf_I and their + backward counterparts are only required in order to support leaky + pipes. If leaky pipes is not required these values can be safely + omitted. + + +3. Routing relay cells + + Let n denote the number of nodes in the circuit. Then encryption layer n + corresponds to the encryption between the OP and the exit/destination + node. + + +3.1. Forward Direction + + The forward direction is the direction that CREATE/CREATE2 cells + are sent. + + +3.1.1. Routing From the Origin + + When an OP sends a relay cell, the cell is produced as follows: + + The OP computes E(Sf_n, <0>) | E(Sf_n, <1>) | E(Sf_n, <2>) | ... + and parses the output as + + Length Purpose Notation + ------ ------- -------- + 509 encryption pad Z + BC_BLOCK_LEN backward Nonce Nf'_I + BC_KEY_LEN forward BC Key KDf'_I + HASH_KEY_LEN forward poly hash key HDf'_I + BC_KEY_LEN new forward Seed Sf'_I + + Excess bytes are discarded. It then computes the n'th layer ciphertext + (Tf_n, Cf_n) as follows: + + 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 + + and updates its state by overwriting the old variables with the new + ones. + + LNf_n = Nf_n + Nf_n = Nf'_n + KDf_n = KDf'_n + HDf_n = HDf'_n + Sf_n = Sf'_n + + It then applies the remaining n-1 layers of encryption to (Tf_n, Cf_n) + as follows: + + For I = n-1 to 1: + IV = INT(Tf_{I+1}) + Z = E(JSf_I, <IV>) | E(JSf_I, <IV+1>) | ... | E(JSf_I, <IV+31>) + % 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+1} ^ X_I + Tf_I = E(KSf_I, Y_I) ^ X_I + LTf_{I+1} = Tf_{I+1} + + Upon completion the OP sends (Tf_1, Cf_1) to node 1. + + +3.1.2. Relaying Forward at Onion Routers + + When a forward relay cell (Tf_I, Cf_I) is received by OR I, it decrypts + it performs the following set of steps: + + 'Forward' relay cell: + + X_I = PH(HDf_n, (LNf_I | Cf_I)) + Y_I = Tf_I ^ X_I + if (Nf_I == D(KDf_I, Y_I) ^ X_I) % cell recognized and authenticated + compute E(Sf_I, <0>) | E(Sf_I, <1>) | E(Sf_I, <2>) | ... and parse the + output as Z, Nf'_I, KDf'_I, HDf'_I, Sf'_I + + M = Cf_n ^ Z + LNf_I = Nf_I + Nf_I = Nf'_I + KDf_I = KDf'_I + HDf_I = HDf'_I + Sf_I = Sf'_I + + return M + + else if (I == n) % last node, decryption has failed + send DESTROY cell to tear down the circuit + + else % decrypt and forward cell + X_I = PH(HSf_I, (LTf_{I+1} | Cf_I)) + Y_I = Tf_I ^ X_I + Tf_{I+1} = D(KSf_I, Y_I) ^ X_I + IV = INT(Tf_{I+1}) + Z = E(JSf_I, <IV>) | E(JSf_I, <IV+1>) | ... | E(JSf_I, <IV+31>) + % BC_BLOCK_LEN = 16 + Cf_{I+1} = Cf_I ^ Z[1, 509] + + forward (Tf_{I+1}, Cf_{I+1}) to OR I+1 + +3.2. Backward Direction + + The backward direction is the opposite direction from + CREATE/CREATE2 cells. + +3.2.1. Routing From the Exit Node + + At OR n encryption proceeds as follows: + + It computes E(Sb_n, <0>) | E(Sb_n, <1>) | E(Sb_n, <2>) | ... + and parses the output as + + Length Purpose Notation + ------ ------- -------- + 509 encryption pad Z + BC_BLOCK_LEN backward Nonce Nb'_I + BC_KEY_LEN forward BC Key KDb'_I + HASH_KEY_LEN forward poly hash key HDb'_I + BC_KEY_LEN new forward Seed Sb'_I + + Excess bytes are discarded. It then computes the ciphertext + (Tf_n, Cf_n) as follows: + + Cb_n = M ^ Z + X_n = PH(HDb_n, (LNb_n | Cb_n)) + Y_n = Nb_n ^ X_n + Tb_n = E(KDb_n, Y_n) ^ X_n) + + and updates its state by overwriting the old variables with the new + ones. + + LNb_n = Nb_n + Nb_n = Nb'_n + KDb_n = KDb'_n + HDb_n = HDb'_n + Sb_n = Sb'_n + + +3.2.2. Relaying Backward at the Onion Routers + + At OR I (for I < n) when a ciphertext (Tb_I, Cb_I) in the backward + direction is received it is processed as follows: + + X_I = PH(HSb_n, (LTb_{I-1} | Cb_I)) + Y_I = Tb_I ^ X_I + Tb_{I-1} = D(KSb_I, Y_I) ^ X_I + IV = INT(Tb_{I-1}) + Z = E(JSb_I, <IV>) | E(JSb_I, <IV+1>) | ... | E(JSb_I, <IV+31>) + % BC_BLOCK_LEN = 16 + Cb_{I-1} = Cb_I ^ Z[1, 509] + + The ciphertext (Tb_I, Cb_I) is then passed along the circuit towards + the OP. + + +3.2.2. Routing to the Origin + + When a ciphertext (Tb_1, Cb_1) arrives at an OP, the OP decrypts it in + two stages. It first reverses the layers from 1 to n-1 as follows: + + For I = 1 to n-1: + X_I = PH(HSb_I, (LTb_{I+1} | Cb_I)) + Y_I = Tb_I ^ X_I + Tb_{I+1} = E(KSb_I, Y_I) ^ X_I + IV = INT(Tb_{I+1}) + Z = E(JSb_I, <IV>) | E(JSb_I, <IV+1>) | ... | E(JSb_I, <IV+31>) + % BC_BLOCK_LEN = 16 + Cb_{I+1} = Cb_I ^ Z[1, 509] + + Upon completion the n'th layer of encryption is removed as follows: + + X_n = PH(HDb_n, (LNb_n | Cb_n)) + Y_n = Tb_n ^ X_n + if (Nb_n = D(KDb_n, Y_n) ^ X_n) % authentication is successful + compute E(Sb_n, <0>) | E(Sb_n, <1>) | E(Sb_n, <2>) | and parse the + output as Z, Nb'_n, KDb'_n, HDb'_n, Sb'_n + + M = Cb_n ^ Z + LNb_n = Nb_n + Nb_n = Nb'_n + KDb_n = KDb'_n + HDb_n = HDb'_n + Sb_n = Sb'_n + + return M + + else + send DESTROY cell to tear down the circuit + + +4. Application connections and stream management + +4.1. Amendments to the Relay Cell Format + + Within a circuit, the OP and the end node use the contents of + RELAY packets to tunnel end-to-end commands and TCP connections + ("Streams") across circuits. End-to-end commands can be initiated + by either edge; streams are initiated by the OP. + + The payload of each unencrypted RELAY cell consists of: + + Relay command [1 byte] + StreamID [2 bytes] + Length [2 bytes] + Data [PAYLOAD_LEN-21 bytes] + + The old Digest field is removed since sufficient information for + authentication is now included in the nonce part of the payload. + + The old 'Recognized' field is removed. Instead a cell is recognized + via a partial decryption using the node's dynamic keys - namely the + following steps (already included in Section 3): + + Forward direction: + + X_I = PH(HDf_n, (LNf_I | Cf_I)) + Y_I = Tf_I ^ X_I + if (Nf_I == D(KDf_I, Y_I) ^ X_I) % cell is recognized and authenticated + + Backward direction (executed by the OP): + + If the OP is aware of the number of layers present in the cell there + is no need to attempt to recognize the cell. Otherwise the OP can, for + each layer, first attempt a partial decryption using the dynamic keys + for that layer as follows: + + X_I = PH(HDb_I, (LNb_I | Cb_I)) + Y_I = Tb_I ^ X_I + if (Nb_I = D(KDb_I, Y_I) ^ X_I) % cell is recognized and authenticated + + The 'Length' field of a relay cell contains the number of bytes + in the relay payload which contain real payload data. The + remainder of the payload is padding bytes. + +4.2. Appending the encrypted nonce and dealing with version-homogenic + and version-heterogenic circuits + + When a cell is prepared to be routed from the origin (see Section + 3.1.1) the encrypted nonce N is appended to the encrypted cell + (occupying the last 16 bytes of the cell). If the cell is prepared to + be sent to a node supporting the new protocol, S is combined with other + sources to generate the layer's nonce. Otherwise, if the node only + supports the old protocol, n is still appended to the encrypted cell + (so that following nodes can still recover their nonce), but a + synchronized nonce (as per the old protocol) is used in CTR-mode. + + When a cell is sent along the circuit in the 'backward' direction, + nodes supporting the new protocol always assume that the last 16 bytes + of the input are the nonce used by the previous node, which they + process as per Section 3.2.1. If the previous node also supports the + new protocol, these cells are indeed the nonce. If the previous node + only supports the old protocol, these bytes are either encrypted + padding bytes or encrypted data. + +5. Security and Design Rationale + + We are currently working on a security proof to better substantiate our + security claims. Below is a short informal summary on the security of + CGO and its design rationale. + +5.1. Resistance to crypto-tagging attacks + + Protection against crypto-tagging attacks is provided by layers n-1 to + 1. This part of the scheme is based on the paradigm from [ADL17] which + has the property that if any single bit of the OR's input is changed + then all of the OR's output will be randomised. Specifically, if + (Tf_I, Cf_I) is travelling in the forward direction and is processed by + an honest node I, a single bit flip to either Tf_I or Cf_I will result + in both Tf_{I+1} and Cf_{I+1} being completely randomised. In addition, + the processing of (Tf_I, Cf_I) includes LTf_{I+1} so that any + modification to (Tf_I, Cf_I) at time j will in turn randomise the value + (Tf_{I+1}, Cf_{I+1}) at any time >= j . Thus once a circuit is tampered + with it is not possible to recover from it at a later stage. This helps + to protect against the standard crypto-tagging attack and variations + thereof (Section 5.2 in [DS18]). A similar argument holds in the + backward direction. + + +5.2. End-to-end authenticated encryption + + Layer n provides end-to-end authenticated encryption. Similar to the + old protocol, this proposal only offers end-to-end authentication + rather than per-hop authentication. However, CGO provides 128-bit + authentication as opposed to the 32-bit authentication provided by the + old protocol. A main observation underpinning the design of CGO is + that the n'th layer does not need to be secure against the release of + unverified plaintext (RUP). RUP security is only needed to protect + against tagging attacks and the n'th layer does not help in that regard + (but the layers below do). Consequently we employ a different scheme at + the n'th layer which is designed to provide forward-secure + authenticated encryption. + + +5.3 Forward Security + + As mentioned in the previous section CGO provides end-to-end + authenticated encryption that is also forward secure. Our notion of + forward security follows the definitions of Bellare and Yee [BY03] for + both confidentiality and authenticity. Forward-secure confidentiality + says that upon corrupting either the sender (or the receiver), the + secrecy of the messages that have already been sent (or received) is + still guaranteed. As for forward-secure authentication, upon corrupting + the sender the authenticity of previously authenticated messages is + still guaranteed (even if they have not yet been received). In order to + achieve forward-secure authenticated encryption, CGO updates the key + material of the n'th layer encryption with every cell that is + processed. In order to support leaky pipes the lower layers also need + to maintain a set of dynamic keys that are used to recognize cells that + are intended for them. This key material is only used for partial + processing, i.e. recognizing the cell, and is only updated if + verification is successful. If the cell is not recognized, the node + reverts to processing the cell with the static key material. If support + for leaky-pipes is not required this extra processing can be omitted. + + +6. Efficiency Considerations + + Although we have not carried out any experiments to verify this, we + expect CGO to perform relatively well in terms of efficiency. Firstly, + it manages to achieve forward security with just a universal hash as + opposed to other proposals which suggested the use of SHA2 or SHA3. In + this respect we recommend using POLYVAL [GLL18], a variant of GHASH + that is more compatible with Intel's PCMULQDQ instruction. Furthermore + CGO admits a certain degree of parallelisability. Supporting leaky + pipes requires an OR to first verify the cell using the the dynamic key + material and if the cell is unrecognised it goes on to process the cell + with the static key material. The important thing to note (see for + instance Section 3.1.2) is that the initial processing of the cell + using the static key material is almost identical to the verification + using the dynamic key material, and the two computations are + independent of each other. As such, although in Section 3 these were + described as being evaluated sequentially, they can in fact be computed + in parallel. In particular the two polynomial hashes could be computed + in parallel by using the new vectorised VPCMULQDQ instruction. + + We are currently looking into further optimisations of the scheme as + presented here. One such optimisation is the possibility of removing + KDf_I and KDb_I while retaining forward security. This would further + improve the efficiency of the scheme by reducing the amount of dynamic + key material that needs to be updated with every cell that is processed. + + +References + +[ADL17] Tomer Ashur, Orr Dunkelman, Atul Luykx, "Boosting Authenticated +Encryption Robustness with Minimal Modifications", CRYPTO 2017. + +[BY03] Mihir Bellare, Bennett Yee, "Forward-Security in Private-Key +Cryptography", CT-RSA 2003. + +[DS18] Jean Paul Degabriele, Martijn Stam, "Untagging Tor: A Formal +Treatment of Onion Encryption", EUROCRYPT 2018. + +[GLL18] Shay Gueron, Adam Langley, Yehuda Lindell, "AES-GCM-SIV: Nonce +Misuse-Resistant Authenticated Encryption", RFC 8452, April 2019. + +[ST13] Thomas Shrimpton, R. Seth Terashima, "A Modular Framework for +Building Variable-Input Length Tweakable Ciphers", ASIACRYPT 2013. 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 141cfa0..a3e0b0a 100644 --- a/rend-spec-v3.txt +++ b/rend-spec-v3.txt @@ -240,6 +240,11 @@ Table of contents: (TLS-over-TCP, IPv4), [02] (legacy node identity) and [03] (ed25519 identity key). + As of 0.4.1.1-alpha, Tor includes both IPv4 and IPv6 link specifiers + in v3 onion service protocol link specifier lists. All available + addresses SHOULD be included as link specifiers, regardless of the + address that Tor actually used to connect/extend to the remote relay. + We also incorporate Tor's circuit extension handshakes, as used in the CREATE2 and CREATED2 cells described in tor-spec.txt. In these handshakes, a client who knows a public key for a server sends a @@ -463,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 @@ -640,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] @@ -1189,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 @@ -1343,6 +1344,12 @@ Table of contents: The link-specifiers is a base64 encoding of a link specifier block in the format described in BUILDING-BLOCKS. + As of 0.4.1.1-alpha, services include both IPv4 and IPv6 link + specifiers in descriptors. All available addresses SHOULD be + included in the descriptor, regardless of the address that the + onion service actually used to connect/extend to the intro + point. + The client SHOULD NOT reject any LSTYPE fields which it doesn't recognize; instead, it should use them verbatim in its EXTEND request to the introduction point. @@ -1477,6 +1484,13 @@ Table of contents: First, a hidden service host builds an anonymous circuit to a Tor node and registers that circuit as an introduction point. + Single Onion Services attempt to build a non-anonymous single-hop circuit, + but use an anonymous 3-hop circuit if: + * the intro point is on an address that is configured as unreachable via + a direct connection, or + * the initial attempt to connect to the intro point over a single-hop + circuit fails, and they are retrying the intro point connection. + [After 'First' and before 'Second', the hidden service publishes its introduction points and associated keys, and the client fetches them as described in section [HSDIR] above.] @@ -1711,6 +1725,11 @@ Table of contents: in [BUILDING-BLOCKS], the "TLS-over-TCP, IPv4" and "Legacy node identity" specifiers must be present. + As of 0.4.1.1-alpha, clients include both IPv4 and IPv6 link specifiers + in INTRODUCE1 cells. All available addresses SHOULD be included in the + cell, regardless of the address that the client actually used to extend + to the rendezvous point. + The hidden service should handle invalid or unrecognised link specifiers the same way as clients do in section 2.5.2.2. In particular, services MAY perform basic validity checks on link specifiers, and SHOULD NOT @@ -1912,6 +1931,13 @@ Table of contents: this has occurred, the relay forwards the contents of the RENDEZVOUS cell to the client, and joins the two circuits together. + Single Onion Services attempt to build a non-anonymous single-hop circuit, + but use an anonymous 3-hop circuit if: + * the rend point is on an address that is configured as unreachable via + a direct connection, or + * the initial attempt to connect to the rend point over a single-hop + circuit fails, and they are retrying the rend point connection. + 4.1. Establishing a rendezvous point [EST_REND_POINT] The client sends the rendezvous point a RELAY_COMMAND_ESTABLISH_RENDEZVOUS @@ -2311,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] @@ -2320,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/tor-spec.txt b/tor-spec.txt index b2b26eb..21abfdf 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -1861,32 +1861,91 @@ see tor-design.pdf. To control a circuit's bandwidth usage, each OR keeps track of two 'windows', consisting of how many RELAY_DATA cells it is allowed to - originate (package for transmission), and how many RELAY_DATA cells - it is willing to consume (receive for local streams). These limits - do not apply to cells that the OR receives from one host and relays - to another. + originate or willing to consume. + + These two windows are respectively named: the package window (packaged for + transmission) and the deliver window (delivered for local streams). + + Because of our leaky-pipe topology, every relay on the circuit has a pair + of windows, and the OP has a pair of windows for every relay on the + circuit. These windows do not apply to relayed cells, however, and a relay + that is never used for streams will never decrement its window or cause the + client to decrement a window. Each 'window' value is initially set based on the consensus parameter - 'circwindow' in the directory (see dir-spec.txt), or to 1000 data cells - if no 'circwindow' value is given, - in each direction (cells that are not data cells do not affect - the window). When an OR is willing to deliver more cells, it sends a - RELAY_SENDME cell towards the OP, with Stream ID zero and an empty - body. When an OR receives a RELAY_SENDME cell with stream ID zero, it - increments its packaging window. (The body SHOULD be ignored.) + 'circwindow' in the directory (see dir-spec.txt), or to 1000 data cells if + no 'circwindow' value is given. In each direction, cells that are not + RELAY_DATA cells do not affect the window. + + An OR or OP (depending on the stream direction) sends a RELAY_SENDME cell + to indicate that it is willing to receive more cells when its deliver + window goes down below a full increment (100). For example, if the window + started at 1000, it should send a RELAY_SENDME when it reaches 900. + + When an OR or OP receives a RELAY_SENDME, it increments its package window + by a value of 100 (circuit window increment) and proceeds to sending the + remaining RELAY_DATA cells. + + If a package window reaches 0, the OR or OP stops reading from TCP + connections for all streams on the corresponding circuit, and sends no more + RELAY_DATA cells until receiving a RELAY_SENDME cell. + + If a deliver window goes below 0, the circuit should be torn down. + + Starting with tor-0.4.1.1-alpha, authenticated SENDMEs are supported + (version 1, see below). This means that both the OR and OP need to remember + the rolling digest of the cell that precedes (triggers) a RELAY_SENDME. + This can be known if the package window gets to a multiple of the circuit + window increment (100). + + When the RELAY_SENDME version 1 arrives, it will contain a digest that MUST + match the one remembered. This represents a proof that the end point of the + circuit saw the sent cells. On failure to match, the circuit should be torn + down. + + To ensure unpredictability, random bytes should be added to at least one + RELAY_DATA cell within one increment window. In other word, every 100 cells + (increment), random bytes should be introduced in at least one cell. + +7.3.1 SENDME Cell Format + + A circuit-level RELAY_SENDME cell always has its StreamID=0. + + An OR or OP must obey these two consensus parameters in order to know which + version to emit and accept. - Each of these cells increments the corresponding window by 100. + 'sendme_emit_min_version': Minimum version to emit. + 'sendme_accept_min_version': Minimum version to accept. - The OP behaves identically, except that it must track a packaging - window and a delivery window for every OR in the circuit. + If a RELAY_SENDME version is received that is below the minimum accepted + version, the circuit should be closed. - An OR or OP sends cells to increment its delivery window when the - corresponding window value falls under some threshold (900). + The RELAY_SENDME payload contains the following: - If a packaging window reaches 0, the OR or OP stops reading from - TCP connections for all streams on the corresponding circuit, and - sends no more RELAY_DATA cells until receiving a RELAY_SENDME cell. -[this stuff is badly worded; copy in the tor-design section -RD] + VERSION [1 byte] + DATA_LEN [2 bytes] + DATA [DATA_LEN bytes] + + The VERSION tells us what is expected in the DATA section of length + DATA_LEN and how to handle it. The recognized values are: + + 0x00: The rest of the payload should be ignored. + + 0x01: Authenticated SENDME. The DATA section MUST contain: + + DIGEST [20 bytes] + + If the DATA_LEN value is less than 20 bytes, the cell should be + dropped and the circuit closed. If the value is more than 20 bytes, + then the first 20 bytes should be read to get the DIGEST value. + + The DIGEST is the rolling digest value from the RELAY_DATA cell that + immediately preceded (triggered) this RELAY_SENDME. This value is + matched on the other side from the previous cell sent that the OR/OP + must remember. + + If the VERSION is unrecognized or below the minimum accepted version (taken + from the consensus), the circuit should be torn down. 7.4. Stream-level flow control @@ -2110,4 +2169,19 @@ see tor-design.pdf. Describes the padding capabilities of the relay. - "1" -- Relay supports circuit-level padding. + "1" -- [DEFUNCT] Relay supports circuit-level padding. This version MUST NOT + be used as it was also enabled in relays that don't actually support + circuit-level padding. Advertised by Tor versions from + tor-0.4.0.1-alpha and only up to and including tor-0.4.1.4-rc. + + "2" -- Relay supports the HS circuit setup padding machines (proposal 302). + Advertised by Tor versions from tor-0.4.1.5 and onwards. + +9.12. "FlowCtrl" + + Describes the flow control protocol at the circuit and stream level. If + there is no FlowCtrl advertised, tor supports the unauthenticated flow + control features (version 0). + + "1" -- supports authenticated circuit level SENDMEs as of proposal 289 in + Tor 0.4.1.1-alpha. |