<div dir="ltr">I appreciate all the suggestions!<div><br></div><div>Thanks,</div><div>Alex</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 12, 2022 at 3:59 AM <<a href="mailto:r.a@posteo.net">r.a@posteo.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey,<br>
<br>
On 21.01.22 14:57, Alexander Mages wrote:<br>
> Right now we're exploring latency-based attacks but are having trouble <br>
> achieving a particular goal: a way to “ping” an arbitrary node in a <br>
> client’s already-built (“live”) circuit. One-way timing is ideal but <br>
> round trip time would suffice. We can glean this information during <br>
> circuit construction, but what about a “live” circuit? Ideally, this <br>
> would be a periodic thing Tor already keeps track of, but as an <br>
> on-demand or as a byproduct/side-effect of a different function would <br>
> also work. We have not been able to find a way to do this within the Tor <br>
> (sub)protocol specs or the control port spec.<br>
<br>
<br>
You can measure the RTT between your client and a node by exiting <br>
through that node and intentionally violating its exit policy, such as <br>
connecting to <a href="http://127.0.0.1:80" rel="noreferrer" target="_blank">127.0.0.1:80</a>. The node will return an error, and you can <br>
measure the RTT as the time between sending the request and receiving <br>
the error. See <a href="https://naviga-tor.github.io/" rel="noreferrer" target="_blank">https://naviga-tor.github.io/</a> for an example.<br>
<br>
<br>
All the best,<br>
Robert<br>
</blockquote></div>