Age | Commit message (Collapse) | Author |
|
The clear standard is trailing "." after each numeric section. This fixes
the small handful of outliers. This makes it easy to convert these headers
to common markup formats, for example:
http://hyperpolyglot.org/lightweight-markup
|
|
|
|
|
|
This merges proposal 289 into tor-spec.txt.
Most of the circuit-level flow control section has been rewritten to be
clearer and better detail version 0 and 1.
Closes #30365
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Let's refrain from mentioning section 6.4 in here, as the format
is not exactly the same - not all address type field values from
section 6.4 make sense in NETINFO cell and NETINFO cell does not
have a TTL value at the end of each address. It's a little confusing
to suggest that there is a reuse of wire format fragment between
RELAY_RESOLVED and NETINFO cells.
|
|
|
|
|
|
|
|
Updates tor-spec for 26871
|
|
Closes 26870.
|
|
Closes #26885.
|
|
Part of 26885.
|
|
The all-zeroes special case for EXTEND/EXTEND2 cells is for relay
fingerprints/public keys, not cell crypto digests.
Closes ticket 26893.
|
|
Not all of the text describing CREATE, CREATED, EXTEND, or EXTENDED
cells was updated when the "2"-suffixed versions were added.
Closes ticket 26894.
|
|
|
|
And perhaps they never were?
|
|
|
|
Also generalised the EXTENDED to CREATED section so it covers
EXTENDED2 to CREATED2.
Closes 26859.
|
|
The section now consists of:
* forward encryption at the client
* forward decryption at ORs
* backward encryption at the end (exit)
* backward decryption at the client
Part of 26860.
|
|
Closes 26872.
|
|
In doing so, specify a general behavior for padding bytes in Section 3
and cross-reference other locations to this, to aid in future
consistency.
Also clarify a few vague parts of the prior wording.
Fixes #26860.
|
|
Fixes #26860.
|
|
Section 5.1.2 erroneously suggested that a client might send an
EXTENDED2 cell, which was probably a typo. Also change "a" to "an".
|
|
|
|
Good point from Roger and Tim on...
https://trac.torproject.org/projects/tor/ticket/25171
|
|
Our tor-spec left me pretty mystified what the 'recognized' field actually was.
It discussed what to do when it was zero, but not what the field *was* or what
non-zero meant. Thankfully Roger filled me in over tasty, tasty pizza.
|
|
|
|
|
|
|
|
Resolves 22931.
|
|
Resolves 22929.
|
|
Make sure we mention all the ciphers we use, and use the phrase
"unless otherwise specified" liberally to make sure that people
don't think that we're still RSA1024 all over.
Also rename the hybrid encryption thing to "legacy hybrid
encryption", and put it in its own section.
Closes ticket 22722.
|
|
|
|
We had been vague about what the Value fields here were.
Also, document that addresses in NETINFO don't have TTLs.
Closes ticket 22937.
|
|
In protocol <= 3 we allowed OPs to set the circID msb however they
wanted. We don't do that any more in >= 4.
Closes ticket 22882.
|
|
Instead of saying the clock skew and "your address" fields are
unused, describe the dangers of using them as unconditionally
trusted.
|
|
Closes ticket 22918.
|
|
We said that PADDING was allowed, but it wasn't.
Bug 22934.
|
|
|
|
|
|
The original was incorrect to say
"You may do A if B, C otherwise."
but it seems less clear to say
"You MUST do A if B, C otherwise."
than it is to say
"If A, you MUST B. If not A, you MUST C."
Closes ticket 22951
|
|
This is only used in TAP and old-style hidden services, and it's
half malleable. I've clarified how the code behaves by adding the
change suggested in #22987. I've also noted:
I've also noted that we don't actually reach case 1 with any usage
of this algorithm.
I've also replaced Roger's note that someday we'll add a MAC with
an admonition not to use this hybrid encryption approach for
anything new. We're not planning to add a MAC; we've migrated to
ntor instead.
|
|
|
|
Fixes bug 22862; based on patch from Teor.
|