[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #17605 [Core Tor/Tor]: Tell caches to remove X-Your-Address-Is from Tor Directory documents
#17605: Tell caches to remove X-Your-Address-Is from Tor Directory documents
-------------------------------------------------+-------------------------
Reporter: teor | Owner: jryans
Type: defect | Status:
| needs_revision
Priority: High | Milestone: Tor:
| 0.3.0.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-auth, isaremoved, | Actual Points:
tor-03-unspecified-201612, review-group-15 |
Parent ID: | Points: 2
Reviewer: nickm | Sponsor:
-------------------------------------------------+-------------------------
Comment (by teor):
Replying to [comment:23 arma]:
> If you stop sending x-your-address-is headers, then all of the relays
that haven't upgraded yet will be sol. So we shouldn't stop sending them
for a good while, right?
Yes. Even on unencrypted connections, sadly.
> Teor suggests "relays which don't know their own IP address make a
begindir connection to an authority to discover that IP address", but one
of the goals here is to detect if the IP address has *changed*, not just
to learn it the first time. So if relays only do begindir when they don't
know any IP address for themselves, and they stop believing the naked http
header, then we lose the functionality to learn when the address changed.
>
> ...Unless there is some periodic relay handshake that the relay does,
which would let it learn about a new address from the netinfo cell. And
I've got just the one -- the periodic reachability tests by the directory
authorities -- *except*, if the IP address changes, the relays will stop
being reachable anymore, so they're going to have to notice on their own
that something changed, in order to generate a new descriptor with the new
address in it, and only then will the authorities try reaching them on the
new address. Bummer.
The preemptive (client) circuits that each relay makes elicit netinfo
cells in response, as do bandwidth self-testing and ORPort and DirPort
reachability checks.
> Ok. To summarize:
>
> * Directory servers shouldn't stop giving out the header yet, or it'll
break existing relays.
>
> * We can teach new relays to listen to the address they find in the
netinfo cell. Probably we should only believe it when we're interacting
with a directory authority. But that change by itself won't be enough,
because we also need to make relays do periodic outbound connection
handshakes with directory authorities, or they won't reliably get the
netinfo cells they need. That step probably requires at least some design,
and makes an 030 target less likely.
How about a design where the relay uses the netinfo cells from any circuit
to detect if the address *might* have changed, and then contacts a
directory authority to confirm?
> * Right now if anything caches directory objects at the middlebox, I
fear they cache the http headers too. So I think Nick's statement that
"cacheing should probably happen on URLs that are cacheable (ie,
consensuses)" is not true yet, because *every* url will have the x-your-
address-is header in it, and we shouldn't take that header out yet. Does
that mean we should add the no-cache / no-store lines for now, while we
still serve the x-your-address-is header?
Yes, we should add the cache lines, there's no way of escaping that.
(Well, 0.2.8 and later clients don't need them, because they all use
begindir.)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17605#comment:24>
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