diff options
| -rw-r--r-- | address-spec.txt | 7 | ||||
| -rw-r--r-- | bandwidth-file-spec.txt | 27 | ||||
| -rw-r--r-- | bridgedb-spec.txt | 15 | ||||
| -rw-r--r-- | cert-spec.txt | 15 | ||||
| -rw-r--r-- | control-spec.txt | 89 | ||||
| -rw-r--r-- | dir-list-spec.txt | 24 | ||||
| -rw-r--r-- | dir-spec.txt | 66 | ||||
| -rw-r--r-- | ext-orport-spec.txt | 14 | ||||
| -rw-r--r-- | gettor-spec.txt | 12 | ||||
| -rw-r--r-- | glossary.txt | 21 | ||||
| -rw-r--r-- | guard-spec.txt | 35 | ||||
| -rw-r--r-- | padding-spec.txt | 20 | ||||
| -rw-r--r-- | param-spec.txt | 16 | ||||
| -rw-r--r-- | path-spec.txt | 44 | ||||
| -rw-r--r-- | proposals/321-happy-families.md | 10 | ||||
| -rw-r--r-- | socks-extensions.txt | 9 | ||||
| -rw-r--r-- | tor-spec.txt | 71 | ||||
| -rw-r--r-- | version-spec.txt | 6 |
18 files changed, 493 insertions, 8 deletions
diff --git a/address-spec.txt b/address-spec.txt index 2a6f7db..98e7068 100644 --- a/address-spec.txt +++ b/address-spec.txt @@ -2,6 +2,13 @@ Special Hostnames in Tor Nick Mathewson +Table of Contents + + 1. Overview + 2. .exit + 3. .onion + 4. .noconnect + 1. Overview Most of the time, Tor treats user-specified hostnames as opaque: When diff --git a/bandwidth-file-spec.txt b/bandwidth-file-spec.txt index 924623e..58ce83c 100644 --- a/bandwidth-file-spec.txt +++ b/bandwidth-file-spec.txt @@ -3,6 +3,33 @@ juga teor +Table of Contents + + 1. Scope and preliminaries + 1.2. Acknowledgements + 1.3. Outline + 1.4. Format Versions + 2. Format details + 2.1. Definitions + 2.2. Header List format + 2.3. Relay Line format + 2.4. Implementation details + 2.4.1. Writing bandwidth files atomically + 2.4.2. Additional KeyValue pair definitions + 2.4.2.1. Simple Bandwidth Scanner + 2.4.2.2. Torflow + A. Sample data + A.1. Generated by Torflow + A.2. Generated by sbws version 0.1.0 + A.3. Generated by sbws version 1.0.3 + A.4. Headers generated by sbws version 1.0.4 + A.5 Generated by sbws version 1.1.0 + B. Scaling bandwidths + B.1. Scaling requirements + B.2. A linear scaling method + B.3. Quota changes + B.4. Torflow aggregation + 1. Scope and preliminaries This document describes the format of Tor's Bandwidth File, version diff --git a/bridgedb-spec.txt b/bridgedb-spec.txt index a4c4708..5ccce92 100644 --- a/bridgedb-spec.txt +++ b/bridgedb-spec.txt @@ -4,6 +4,21 @@ Karsten Loesing Nick Mathewson +Table of Contents + + 0. Preliminaries + 1. Importing bridge network statuses and bridge descriptors + 1.1. Parsing bridge network statuses + 1.2. Parsing bridge descriptors + 1.3. Parsing extra-info documents + 2. Assigning bridges to distributors + 3. Giving out bridges upon requests + 4. Selecting bridges to be given out based on IP addresses + 5. Selecting bridges to be given out based on email addresses + 6. Selecting unallocated bridges to be stored in file buckets + 7. Displaying Bridge Information + 8. Writing bridge assignments for statistics + 0. Preliminaries This document specifies how BridgeDB processes bridge descriptor files diff --git a/cert-spec.txt b/cert-spec.txt index 08d754d..1782141 100644 --- a/cert-spec.txt +++ b/cert-spec.txt @@ -1,6 +1,21 @@ Ed25519 certificates in Tor +Table of Contents + + 1. Scope and Preliminaries + 1.1. Signing + 1.2. Integer encoding + 2. Document formats + 2.1. Ed25519 Certificates + 2.2. Basic extensions + 2.2.1. Signed-with-ed25519-key extension [type 04] + 2.3. RSA->Ed25519 cross-certificate + A.1. List of certificate types (CERT_TYPE field) + A.2. List of extension types + A.3. List of signature prefixes + A.4. List of certified key types (CERT_KEY_TYPE field) + 1. Scope and Preliminaries This document describes a certificate format that Tor uses for diff --git a/control-spec.txt b/control-spec.txt index 25977b9..1feb250 100644 --- a/control-spec.txt +++ b/control-spec.txt @@ -1,6 +1,95 @@ TC: A Tor control protocol (Version 1) +Table of Contents + + 0. Scope + 1. Protocol outline + 1.1. Forward-compatibility + 2. Message format + 2.1. Description format + 2.1.1. Notes on an escaping bug + 2.2. Commands from controller to Tor + 2.3. Replies from Tor to the controller + 2.4. General-use tokens + 3. Commands + 3.1. SETCONF + 3.2. RESETCONF + 3.3. GETCONF + 3.4. SETEVENTS + 3.5. AUTHENTICATE + 3.6. SAVECONF + 3.7. SIGNAL + 3.8. MAPADDRESS + 3.9. GETINFO + 3.10. EXTENDCIRCUIT + 3.11. SETCIRCUITPURPOSE + 3.12. SETROUTERPURPOSE + 3.13. ATTACHSTREAM + 3.14. POSTDESCRIPTOR + 3.15. REDIRECTSTREAM + 3.16. CLOSESTREAM + 3.17. CLOSECIRCUIT + 3.18. QUIT + 3.19. USEFEATURE + 3.20. RESOLVE + 3.21. PROTOCOLINFO + 3.22. LOADCONF + 3.23. TAKEOWNERSHIP + 3.24. AUTHCHALLENGE + 3.25. DROPGUARDS + 3.26. HSFETCH + 3.27. ADD_ONION + 3.28. DEL_ONION + 3.29. HSPOST + 3.30. ONION_CLIENT_AUTH_ADD + 3.31. ONION_CLIENT_AUTH_REMOVE + 3.32. ONION_CLIENT_AUTH_VIEW + 3.33. DROPOWNERSHIP + 3.34. DROPTIMEOUTS + 4. Replies + 4.1. Asynchronous events + 4.1.1. Circuit status changed + 4.1.2. Stream status changed + 4.1.3. OR Connection status changed + 4.1.4. Bandwidth used in the last second + 4.1.5. Log messages + 4.1.6. New descriptors available + 4.1.7. New Address mapping + 4.1.8. Descriptors uploaded to us in our role as authoritative dirserver + 4.1.9. Our descriptor changed + 4.1.10. Status events + 4.1.11. Our set of guard nodes has changed + 4.1.12. Network status has changed + 4.1.13. Bandwidth used on an application stream + 4.1.14. Per-country client stats + 4.1.15. New consensus networkstatus has arrived + 4.1.16. New circuit buildtime has been set + 4.1.17. Signal received + 4.1.18. Configuration changed + 4.1.19. Circuit status changed slightly + 4.1.20. Pluggable transport launched + 4.1.21. Bandwidth used on an OR or DIR or EXIT connection + 4.1.22. Bandwidth used by all streams attached to a circuit + 4.1.23. Per-circuit cell stats + 4.1.24. Token buckets refilled + 4.1.25. HiddenService descriptors + 4.1.26. HiddenService descriptors content + 4.1.27. Network liveness has changed + 4.1.28. Pluggable Transport Logs + 4.1.29. Pluggable Transport Status + 5. Implementation notes + 5.1. Authentication + 5.2. Don't let the buffer get too big + 5.3. Backward compatibility with v0 control protocol + 5.4. Tor config options for use by controllers + 5.5. Phases from the Bootstrap status event + 5.5.1. Overview of Bootstrap reporting. + 5.5.2. Phases in Bootstrap Stage 1 + 5.5.3. Phases in Bootstrap Stage 2 + 5.5.4. Phases in Bootstrap Stage 3 + 5.6 Bootstrap phases reported by older versions of Tor + 0. Scope This document describes an implementation-specific protocol that is used diff --git a/dir-list-spec.txt b/dir-list-spec.txt index 3557721..c2d83f4 100644 --- a/dir-list-spec.txt +++ b/dir-list-spec.txt @@ -2,6 +2,30 @@ Tor Directory List Format Tim Wilson-Brown (teor) +Table of Contents + + 1. Scope and Preliminaries + 1.1. Format Overview + 1.2. Acknowledgements + 1.3. Format Versions + 1.4. Future Plans + 2. Format Details + 2.1. Nonterminals + 2.2. List Header + 2.2.1. List Header Format + 2.3. List Generation + 2.3.1. List Generation Format + 2.4. Directory Entry + 2.4.1. Directory Entry Format + 3. Usage Considerations + 3.1. Caching + 3.2. Retrieving Directory Information + 3.3. Fallback Reliability + A.1. Sample Data + A.1.1. Sample Fallback List Header + A.1.2. Sample Fallback List Generation + A.1.3. Sample Fallback Entries + 1. Scope and Preliminaries This document describes the format of Tor's directory lists, which are diff --git a/dir-spec.txt b/dir-spec.txt index 7ba11c0..873225d 100644 --- a/dir-spec.txt +++ b/dir-spec.txt @@ -1,6 +1,72 @@ Tor directory protocol, version 3 +Table of Contents + + 0. Scope and preliminaries + 0.1. History + 0.2. Goals of the version 3 protoc + 0.3. Some Remaining questions + 1. Outline + 1.1. What's different from version 2? + 1.2. Document meta-format + 1.3. Signing documents + 1.4. Voting timeline + 2. Router operation and formats + 2.1. Uploading server descriptors and extra-info documents + 2.1.1. Server descriptor format + 2.1.2. Extra-info document format + 2.1.3. Nonterminals in server descriptors + 3. Directory authority operation and formats + 3.1. Creating key certificates + 3.2. Accepting server descriptor and extra-info document uploads + 3.3. Computing microdescriptors + 3.4. Exchanging votes + 3.4.1. Vote and consensus status document formats + 3.4.2. Assigning flags in a vote + 3.4.3. Serving bandwidth list files + 3.5. Downloading missing certificates from other directory authorities + 3.6. Downloading server descriptors from other directory authorities + 3.7. Downloading extra-info documents from other directory authorities + 3.8. Computing a consensus from a set of votes + 3.8.0.1. Deciding which Ids to include. + 3.8.0.2. Deciding which descriptors to include + 3.8.1. Forward compatibility + 3.8.2. Encoding port lists + 3.8.3. Computing Bandwidth Weights + 3.9. Computing consensus flavors + 3.9.1. ns consensus + 3.9.2. Microdescriptor consensus + 3.10. Exchanging detached signatures + 3.11. Publishing the signed consensus + 4. Directory cache operation + 4.1. Downloading consensus status documents from directory authorities + 4.2. Downloading server descriptors from directory authorities + 4.3. Downloading microdescriptors from directory authorities + 4.4. Downloading extra-info documents from directory authorities + 4.5. Consensus diffs + 4.5.1. Consensus diff format + 4.5.2. Serving and requesting diff + 4.6 Retrying failed downloads + 5. Client operation + 5.1. Downloading network-status documents + 5.2. Downloading server descriptors or microdescriptors + 5.3. Downloading extra-info documents + 5.4. Using directory information + 5.4.1. Choosing routers for circuits. + 5.4.2. Managing naming + 5.4.3. Software versions + 5.4.4. Warning about a router's status. + 5.5. Retrying failed downloads + 6. Standards compliance + 6.1. HTTP headers + 6.2. HTTP status codes + A. Consensus-negotiation timeline. + B. General-use HTTP URLs + C. Converting a curve25519 public key to an ed25519 public key + D. Inferring missing proto lines. + E. Limited ed diff format + 0. Scope and preliminaries This directory protocol is used by Tor version 0.2.0.x-alpha and later. diff --git a/ext-orport-spec.txt b/ext-orport-spec.txt index 8008c4f..ec88244 100644 --- a/ext-orport-spec.txt +++ b/ext-orport-spec.txt @@ -1,6 +1,20 @@ Extended ORPort for pluggable transports George Kadianakis, Nick Mathewson +Table of Contents + + 1. Overview + 2. Establishing a connection and authenticating. + 2.1. Authentication type: SAFE_COOKIE + 2.1.2. Cookie-file format + 2.1.3. SAFE_COOKIE Protocol specification + 3. The extended ORPort protocol + 3.1. Protocol + 3.2. Command descriptions + 3.2.1. USERADDR + 3.2.2. TRANSPORT + 4. Security Considerations + 1. Overview This document describes the "Extended ORPort" protocol, a wrapper diff --git a/gettor-spec.txt b/gettor-spec.txt index f40b298..a4959b4 100644 --- a/gettor-spec.txt +++ b/gettor-spec.txt @@ -2,6 +2,18 @@ GetTor specification Jacob Appelbaum +Table of Contents + + 0. Preface + 1. Overview + 2. Implementation + 2.1. Reference implementation + 3. SMTP transport + 3.1. SMTP transport security considerations + 3.2. SMTP transport privacy considerations + 4. Other transports + 5. Implementation suggestions + 0. Preface This document describes GetTor and how to properly implementation GetTor. diff --git a/glossary.txt b/glossary.txt index 6debe20..68de376 100644 --- a/glossary.txt +++ b/glossary.txt @@ -11,6 +11,27 @@ This glossary is not a design document; it is only a reference. This glossary is a work-in-progress; double-check its definitions before citing them authoritatively. ;) +Table of Contents + + 0. Preliminaries + 1.0. Commonly used Tor configuration terms + 2.0. Tor network components + 2.1. Relays, aka OR (onion router) + 2.1.1. Specific roles + 2.2. Client, aka OP (onion proxy) + 2.3. Authorities + 2.4. Hidden Service + 2.5. Circuit + 2.6. Edge connection + 2.7. Consensus + 2.8. Descriptor + 3.0. Tor network protocols + 3.1. Link handshake + 3.2. Circuit handshake + 3.3. Hidden Service Protocol + 3.4. Directory Protocol + 4.0. General network definitions + 0. Preliminaries The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL diff --git a/guard-spec.txt b/guard-spec.txt index 4f021b7..883c2bf 100644 --- a/guard-spec.txt +++ b/guard-spec.txt @@ -6,6 +6,37 @@ Ola Bini Nick Mathewson +Table of Contents + + 1. Introduction and motivation + 2. State instances + 3. Circuit Creation, Entry Guard Selection (1000 foot view) + 3.1 Path selection + 3.1.1 Managing entry guards + 3.1.2 Middle and exit node selection + 3.2 Circuit Building + 4. The algorithm. + 4.0. The guards listed in the current consensus. [Section:GUARDS] + 4.1. The Sampled Guard Set. [Section:SAMPLED] + 4.2. The Usable Sample [Section:FILTERED] + 4.3. The confirmed-guard list. [Section:CONFIRMED] + 4.4. The Primary guards [Section:PRIMARY] + 4.5. Retrying guards. [Section:RETRYING] + 4.6. Selecting guards for circuits. [Section:SELECTING] + 4.7. When a circuit fails. [Section:ON_FAIL] + 4.8. When a circuit succeeds [Section:ON_SUCCESS] + 4.9. Updating the list of waiting circuits [Section:UPDATE_WAITING] + 4.10. Whenever we get a new consensus. [Section:ON_CONSENSUS] + 4.11. Deciding whether to generate a new circuit. + 4.12. When we are missing descriptors. + A. Appendices + A.0. Acknowledgements + A.1. Parameters with suggested values. [Section:PARAM_VALS] + A.2. Random values [Section:RANDOM] + A.3. Why not a sliding scale of primaryness? [Section:CVP] + A.4. Controller changes + A.5. Persistent state format + 1. Introduction and motivation Tor uses entry guards to prevent an attacker who controls some @@ -771,7 +802,7 @@ A.3. Why not a sliding scale of primaryness? [Section:CVP] simple to make to the code after we implement the simpler version of the algorithm described above. -A.3. Controller changes +A.4. Controller changes We will add to control-spec.txt a new possible circuit state, GUARD_WAIT, that can be given as part of circuit events and GETINFO responses about @@ -779,7 +810,7 @@ A.3. Controller changes but we will not use it because a circuit with a better guard might become built too. -A.4. Persistent state format +A.5. Persistent state format The persistent state format doesn't need to be part of this specification, since different implementations can do it diff --git a/padding-spec.txt b/padding-spec.txt index f6356ed..825f1d7 100644 --- a/padding-spec.txt +++ b/padding-spec.txt @@ -16,6 +16,26 @@ the anonymity and load-balancing implications of their choices. "OPTIONAL" in this document are to be interpreted as described in RFC 2119. +Table of Contents + + 1. Overview + 2. Connection-level padding + 2.1. Background + 2.2. Implementation + 2.3. Padding Cell Timeout Distribution Statistics + 2.4. Maximum overhead bounds + 2.5. Reducing or Disabling Padding via Negotiation + 2.6. Consensus Parameters Governing Behavior + 3. Circuit-level padding + 3.1. Circuit Padding Negotiation + 3.2. Circuit Padding Machine Message Management + 3.3. Obfuscating client-side onion service circuit setup + 3.3.1. Common general circuit construction sequences + 3.3.2. Client-side onion service introduction circuit obfuscation + 3.3.3. Client-side rendezvous circuit hiding + 3.3.4. Circuit setup machine overhead + 3.4. Circuit padding consensus parameters + A. Acknowledgments 1. Overview diff --git a/param-spec.txt b/param-spec.txt index 4da8ee1..b2882a6 100644 --- a/param-spec.txt +++ b/param-spec.txt @@ -4,6 +4,22 @@ This file lists the recognized parameters that can appear on the "params" line of a directory consensus. +Table of Contents + + 1. Network protocol parameters + 2. Performance-tuning parameters + 3. Voting-related parameters + 4. Circuit-build-timeout parameters + 5. Directory-related parameters + 6. Pathbias parameters + 7. Relay behavior + 8. V3 onion service parameters + 9. Denial-of-service parameters + 10. Padding-related parameters + 11. Guard-related parameters + 12. Relay behavior + X. Obsolete parameters + 1. Network protocol parameters "circwindow" -- the default package window that circuits should be diff --git a/path-spec.txt b/path-spec.txt index eb7d6e6..b1c9fde 100644 --- a/path-spec.txt +++ b/path-spec.txt @@ -19,6 +19,48 @@ of their choices. "OPTIONAL" in this document are to be interpreted as described in RFC 2119. +Tables of Contents + + 1. General operation + 1.1. Terminology + 1.2. A relay's bandwidth + 2. Building circuits + 2.1. When we build + 2.1.0. We don't build circuits until we have enough directory info + 2.1.1. Clients build circuits preemptively + 2.1.2. Clients build circuits on demand + 2.1.3. Relays build circuits for testing reachability and bandwidth + 2.1.4. Hidden-service circuits + 2.1.5. Rate limiting of failed circuits + 2.1.6. When to tear down circuits + 2.2. Path selection and constraints + 2.2.1. Choosing an exit + 2.2.2. User configuration + 2.3. Cannibalizing circuits + 2.4. Learning when to give up ("timeout") on circuit construction + 2.4.1 Distribution choice and parameter estimation + 2.4.2. How much data to record + 2.4.3. How to record timeouts + 2.4.4. Detecting Changing Network Conditions + 2.4.5. Consensus parameters governing behavior + 2.4.6. Consensus parameters governing behavior + 2.5. Handling failure + 3. Attaching streams to circuits + 4. Hidden-service related circuits + 5. Guard nodes + 5.1. How consensus bandwidth weights factor into entry guard selection + 6. Server descriptor purposes + 7. Detecting route manipulation by Guard nodes (Path Bias) + 7.1. Measuring path construction success rates + 7.2. Measuring path usage success rates + 7.3. Scaling success counts + 7.4. Parametrization + 7.5. Known barriers to enforcement + X. Old notes + X.1. Do we actually do this? + X.2. A thing we could do to deal with reachability. + X.3. Some stuff that worries me about entry guards. 2006 Jun, Nickm. + 1. General operation Tor begins building circuits as soon as it has enough directory @@ -90,7 +132,7 @@ of their choices. is unknown (usually its target IP), but we believe the path probably supports the request according to the rules given below. -1.1. A relay's bandwidth +1.2. A relay's bandwidth Old versions of Tor did not report bandwidths in network status documents, so clients had to learn them from the routers' advertised diff --git a/proposals/321-happy-families.md b/proposals/321-happy-families.md index 288ba66..f9ac7b4 100644 --- a/proposals/321-happy-families.md +++ b/proposals/321-happy-families.md @@ -19,7 +19,7 @@ we can de-duplicate families which sometimes helps.) Adding or removing a server from the family requires all the other servers to change their torrc settings. -The is growth in size is not just a theoretical problem. Family +This growth in size is not just a theoretical problem. Family declarations currently make up a little over 55% of the microdescriptors in the directory--around 24% after compression. The largest family has around 270 members. With Walking Onions, 270 @@ -34,7 +34,7 @@ requirements and providing a more detailed migration plan. In this design, every family has a master ed25519 "family key". A node is in the family iff its server descriptor includes a certificate of its ed25519 identity key with the family key. The certificate -format the one in the tor-certs.txt spec; we would allocate a new +format is the one in the tor-certs.txt spec; we would allocate a new certificate type for this usage. These certificates would need to include the signing key in the appropriate extension. @@ -93,7 +93,7 @@ need to do in this event would be to move to a new private family key. A more orthodox method would be to keep the private key somewhere -offline, and using it to generate a certificate for each relay in +offline, and use it to generate a certificate for each relay in the family as needed. These certificates should be made with long-enough lifetimes, and relays should warn when they are going to expire soon. @@ -186,8 +186,8 @@ microdescriptors' family lines: digest of the microdescriptor listed in the original votes. (This calculation is deterministic.) -The problem with this approach is that authorities would have to s -to fetch microdescriptors they do not have in order to replace their +The problem with this approach is that authorities would have to +fetch microdescriptors they do not have in order to replace their family lines. Currently, voting never requires an authority to fetch a microdescriptor from another authority. If we implement vote compression and diffs as in the Walking Onions proposal, diff --git a/socks-extensions.txt b/socks-extensions.txt index 5fd1f82..0107856 100644 --- a/socks-extensions.txt +++ b/socks-extensions.txt @@ -1,6 +1,15 @@ Tor's extensions to the SOCKS protocol +Table of Contents + + 1. Overview + 1.1. Extent of support + 2. Name lookup + 3. Other command extensions. + 4. HTTP-resistance + 5. Optimistic data + 1. Overview The SOCKS protocol provides a generic interface for TCP proxies. Client diff --git a/tor-spec.txt b/tor-spec.txt index de95acb..4b2c7f2 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -4,6 +4,77 @@ Roger Dingledine Nick Mathewson +Table of Contents + + 0. Preliminaries + 0.1. Notation and encoding + 0.2. Security parameters + 0.3. Ciphers + 0.4. A bad hybrid encryption algorithm, for legacy purposes + 1. System overview + 1.1. Keys and names + 2. Connections + 2.1. Picking TLS ciphersuites + 2.2. TLS security considerations + 3. Cell Packet format + 4. Negotiating and initializing connections + 4.1. Negotiating versions with VERSIONS cells + 4.2. CERTS cells + 4.3. AUTH_CHALLENGE cells + 4.4. AUTHENTICATE cells + 4.4.1. Link authentication type 1: RSA-SHA256-TLSSecret + 4.4.2. Link authentication type 3: Ed25519-SHA256-RFC5705 + 4.5. NETINFO cells + 5. Circuit management + 5.1. CREATE and CREATED cells + 5.1.1. Choosing circuit IDs in create cells + 5.1.2. EXTEND and EXTENDED cells + 5.1.3. The "TAP" handshake + 5.1.4. The "ntor" handshake + 5.1.5. CREATE_FAST/CREATED_FAST cells + 5.2. Setting circuit keys + 5.2.1. KDF-TOR + 5.2.2. KDF-RFC5869 + 5.3. Creating circuits + 5.3.1. Canonical connections + 5.4. Tearing down circuits + 5.5. Routing relay cells + 5.5.1. Circuit ID Checks + 5.5.2. Forward Direction + 5.5.2.1. Routing from the Origin + 5.5.2.2. Relaying Forward at Onion Routers + 5.5.3. Backward Direction + 5.5.3.1. Relaying Backward at Onion Routers + 5.5.4. Routing to the Origin + 5.6. Handling relay_early cells + 6. Application connections and stream management + 6.1. Relay cells + 6.2. Opening streams and transferring data + 6.2.1. Opening a directory stream + 6.3. Closing streams + 6.4. Remote hostname lookup + 7. Flow control + 7.1. Link throttling + 7.2. Link padding + 7.3. Circuit-level flow control + 7.3.1. SENDME Cell Format + 7.4. Stream-level flow control + 8. Handling resource exhaustion + 8.1. Memory exhaustion + 9. Subprotocol versioning + 9.1. "Link" + 9.2. "LinkAuth" + 9.3. "Relay" + 9.4. "HSIntro" + 9.5. "HSRend" + 9.6. "HSDir" + 9.7. "DirCache" + 9.8. "Desc" + 9.9. "Microdesc" + 9.10. "Cons" + 9.11. "Padding" + 9.12. "FlowCtrl" + Note: This document aims to specify Tor as currently implemented, though it may take it a little time to become fully up to date. Future versions of Tor may implement improved protocols, and compatibility is not guaranteed. diff --git a/version-spec.txt b/version-spec.txt index 63782b6..615f6f2 100644 --- a/version-spec.txt +++ b/version-spec.txt @@ -1,6 +1,12 @@ HOW TOR VERSION NUMBERS WORK +Table of Contents + + 1. The Old Way + 2. The New Way + 3. Version status. + 1. The Old Way Before 0.1.0, versions were of the format: |