- May 15, 2017
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
- May 14, 2017
-
-
Roger Dingledine authored
unless it was meant to be this way, and I'm the one who got confused?
-
- May 12, 2017
-
-
Yawning Angel authored
"406 Not Acceptable" is the status code that implementations are supposed to return when a request cannot be serviced due to `Accept-*` headers.
-
- May 11, 2017
-
-
Nick Mathewson authored
-
- May 10, 2017
-
-
Roger Dingledine authored
-
- May 09, 2017
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
- May 08, 2017
-
-
Nick Mathewson authored
-
- May 07, 2017
-
-
Chelsea H. Komlo authored
-
- May 04, 2017
-
-
Nick Mathewson authored
-
- May 03, 2017
-
-
Alexander Hansen Færøy authored
-
Alexander Hansen Færøy authored
Rename LZMA2 to LZMA in the proposal and rename x-lzma2 to x-tor-lzma.
-
Nick Mathewson authored
-
Nick Mathewson authored
The problem was that clients would, when contacting caches, identify consensuses by the sha3 digest of the entire consensus, including signatures. But there are multiple valid encodings for a set of signatures, meaning that a malicious cache could serve each client a different encoding, and recognize the clients using the sha3 digests in their requests. The first part of the solution is to fetch consensuses diffs based only on the consensus's digest-as-signed: the digest of the consensus with no signatures on it. The second part of the solution is to generate diffs using the <n>,$d format to first remove all trailing signatures, so that the diffs will apply to any valid consensus, no matter how the signatures are encoded.
-
Nick Mathewson authored
-
It is possible that a descriptor fetch fails because there are no suitable HSDir that the client can pick. In this case, return the QUERY_NO_HSDIR reason which makes HsDir to become "UNKNOWN" both in the HS_DESC and HS_DESC_CONTENT event. Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
- May 02, 2017
-
-
Roger Dingledine authored
-
- Apr 25, 2017
-
-
David Goulet authored
We've rendered this option obsolete in 0.3.1.0-alpha. Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
- Apr 19, 2017
-
-
David Goulet authored
Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
David Goulet authored
Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
David Goulet authored
Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
David Goulet authored
Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
- Apr 16, 2017
-
-
Roger Dingledine authored
-
- Apr 07, 2017
-
-
David Goulet authored
Every intro point, legacy or not, needs a ntor encryption key. However, in the case of a legacy introductin point, we need an extra RSA key so the IP can relay the INTRODUCE1 cell on the right circuit. We now only need the cross certificate for the encryption key because the signing-key extention make sure we have the actual key encoded in that certificate. The legacy key cross certificate doesn't support that extention so we need both the RSA key and the crosscert. Fixes #21871 Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
Alexander Hansen Færøy authored
-
Alexander Hansen Færøy authored
-
Alexander Hansen Færøy authored
-
- Mar 29, 2017
-
-
George Kadianakis authored
-
George Kadianakis authored
-
- Mar 17, 2017
-
-
Nick Mathewson authored
-
- Mar 13, 2017
-
-
George Kadianakis authored
G_LEN and H_LEN were undefined.
-
George Kadianakis authored
It was recently changed to include the key len as first argument, but the spec was never updated. See the following gitlab review comment for more info: https://gitlab.com/asn/tor/merge_requests/7#note_19342504
-
- Mar 09, 2017
-
-
David Goulet authored
Reported-by:
isis <isis@torproject.org> Signed-off-by:
David Goulet <dgoulet@torproject.org>
-
- Mar 08, 2017
-
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-
Nick Mathewson authored
-