| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | | | | |
|
| |/ / /
| | |
| | |
| | |
| | | |
we stopped requiring it sometime between 2003 and now, and also we
stopped adding it sometime between 2003 and now. closes ticket 6879.
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | | |
See https://lists.torproject.org/pipermail/tor-dev/2017-May/012263.html .
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
i don't think i broke anything, but it would be worth somebody
looking over it to be sure.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
please do feel free to look through and make sure i didn't break anything
though :)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
the only exciting one is that we don't use guards to defend against
"enumeration attacks" -- i'm not quite sure what an enumeration attack
is, but it sounds like something where the guard is able to make a list
of users, and where having that list is bad news in itself. that's not
quite what guards are for.
|
| | | | | |
|
| |/ / / |
|
| | | |
| | |
| | |
| | |
| | | |
Mike informs me that prop151 got merged into path-spec and 161 got
split into dir-spec and a spec file in the bwauth code.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
According to Karsten, 121 has long been merged into rend-spec.txt,
and 155 is implementation-specific stuff that doesn't affect the
protocol itself.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \ |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
unless it was meant to be this way, and I'm the one who got confused?
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
"406 Not Acceptable" is the status code that implementations are
supposed to return when a request cannot be serviced due to `Accept-*`
headers.
|
| |\ \ \ \
| |_|_|/
|/| | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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>
|
| | | | | |
|
| |\ \ \ \
| |_|/ /
|/| | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We've rendered this option obsolete in 0.3.1.0-alpha.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
| | | | | |
|
| |\ \ \ \ |
|
| | | | | | |
|
| |\ \ \ \ \
| |/ / / /
|/| | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Baby steps. Crawl before you can walk. Walk before you can run.
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Rename LZMA2 to LZMA in the proposal and rename x-lzma2 to x-tor-lzma.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| |\ \ \ \ \ |
|
| | | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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>
|
| |/ / / / |
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
| | | | |
| | | |
| | | |
| | | | |
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
| | | | | |
|
| | | | | |
|
