[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #32604 [Core Tor/Tor]: Add HiddenServiceExportRendPoint and HiddenServiceExportInstanceID directive
#32604: Add HiddenServiceExportRendPoint and HiddenServiceExportInstanceID
directive
-----------------------------------------+---------------------------------
Reporter: moonsikpark | Owner: (none)
Type: enhancement | Status: needs_revision
Priority: Medium | Milestone: Tor:
| 0.4.3.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-hs tor-dos extra-review | Actual Points:
Parent ID: #32511 | Points:
Reviewer: dgoulet, ahf, teor | Sponsor: Sponsor27-can
-----------------------------------------+---------------------------------
Comment (by teor):
Replying to [comment:21 moonsikpark]:
> OK, made CI happy by letting `circuit_free_()` free
`or_circ->build_state->chosen_exit`.
Thanks!
> Before extending the exposure range of rp fingerprint, I think there
might be other metrics we can export that can help onion services.
Potentially `circ->rend_data->nr_streams` or
`circ->hs_ident->intro_auth_pk`
Sure that seems fine.
> or `circ->hs_ident->rendezvous_cookie`.
No, I don't think we should export raw cryptographic material. If you
really want this info, you should export
`siphash(circ->hs_ident->rendezvous_cookie)`. (The cookie should not be
common across instances, unless the client is doing a replay attack across
different instances. If you want to be able to detect relay attacks, you
should do `H(CONSTANT_PREFIX|circ->hs_ident->rendezvous_cookie)`.)
> I think `INSTANCE_ID` don't have to be that long, we can change it to 1
byte and move it to the front(`fdAA` where `AA=INSTANCE_ID`).
Sure.
> And I'm curious about `dst_ipv6` fixed to `::1`. `real_addr` of
`rend_service_port_config_t` is not always `localhost`. Does backends
ignore the destination address?
I don't know who is actually using this feature right now. Maybe ahf does?
> Does it mean we can cram data in `dst_ipv6` too?
That's 16 bytes, so you could get the whole fingerprint if you wanted it.
But maybe there are more valuable things.
I'm going to suggest a way forward:
1. We decide what to do about the existing broken fields:
https://trac.torproject.org/projects/tor/ticket/32604?replyto=21#comment:19
2. We do a design for the final set of fields.
3. We land this patch with the current fields, in the positions they will
have in the final design.
4. We open a new ticket for any new fields.
This feature is getting complex enough that we might need a proposal, a
spec, or a very well-designed manual page entry.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32604#comment:22>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs