Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
Also see #23019 for the code patch.
|
|
|
|
|
|
- Revise author list and acknowledgements list.
- Write list of prop224 improvements
- Kill a spare TODO.
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
Intro points don't care about the contents of the INTRO1 cell as long as
the first 20 bytes are correctly formatted, so we don't need to have a
special cell for legacy intros. Remove all references to it.
|
|
See replay_cache_rend_cookie in the codebase.
|
|
|
|
The onion key for the ntor handshake is missing in the descriptor in order
for the client to extend to it.
Ticket #22979
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
As part of our work in #23387, we figured out that there are some edge
cases where clients cannot connect to services if they are using
different live consensuses. That was because the overlap period was only
covering clients with a newer consensus than the service.
We are now extending the overlap period to be permanent, and alter its
logic so that it also covers clients with older consensus than the
service.
Now services always have two active descriptors at any given time.
This spec patch is a companion to the code branch of #23387.
|
|
|
|
|
|
Turns out that it was implemented with period_num first and then
period_length.
Like asn said, let us consider that as an interesting engineering artifact
and change the spec instead of the code that has been tested like that for a
while now.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Section 3.3.2 is showing the layout of an INTRODUCE1 cell but was missing a
field that we need to do the MAC computation.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Fixes #22993
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
We don't need KH anymore since we do a MAC check anyway.
|
|
Also simplify that part of the spec sincedgoulet felt it was too obscure
and people might miss it or consider it a side note.
|
|
See review point:
https://gitlab.com/dgoulet/tor/merge_requests/27#note_27696937
|
|
|
|
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>
|
|
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>
|
|
G_LEN and H_LEN were undefined.
|
|
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
|
|
Reported-by: isis <isis@torproject.org>
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
- AUTH_KEYID is actually AUTH_KEY these days
- Make it more clear that the result of the ntor handshake includes a MAC.
|
|
|
|
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|
|
|
|
Current implementation added that status to indicate to the client that the
IP can't relay the INTRODUCE cell to the service.
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
It was unclear whether this was βthe epoch at <time>β or
β(X seconds after the epoch) at <time>β.
|
|
|
|
Closes #19133
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Authorized clients need a x25519 key to decrypt the descriptor anyway,
so having username/password method for the intro-layer authorization is
not very helpful, since they will need to remember the x25519 key anyway.
Perhaps in the future we can reinstate the username/password method, by
having x25519/ed25519 keypairs be generated from the low-entropy
username/password pair.
|
|
In the past prop224 used to embed the client authorization key in the
subcredential. The problem here is that if we wanted to revoke a client,
we would have to change the whole subcredential of the service, which
means that we would have to announce it to all clients.
This patch makes it so that every client has an x25519 and an ed25519
which are used to perform client authorization.
To achieve this on the descriptor level, we change the descriptor format
to a double-layer encryption where the first layer protects against
entities who don't know the public key of the HS, and the second layer
protects against unauthorized clients who don't know the x25519 key.
The intro level authorization remains as is and uses ed25519 for authentication.
Thanks to special for noticing this issue.
Thanks to Nick for sketching out the x25519 descriptor auth scheme.
|
|
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
|