<div dir="ltr"><div>> you might want to remove the client IP address (X-Forwarded-For) from HTTP headers </div><div><br></div><div>Agreed!  And yes we already remove x-forwarded-for.</div><div><a href="https://github.com/globaleaks/Tor2web/blob/master/tor2web/t2w.py#L701">https://github.com/globaleaks/Tor2web/blob/master/tor2web/t2w.py#L701</a></div><div><br></div><div>I recall that the very, very beginning we had a python proxy library automatically adding x-forwarded-for, but once we realized it was doing that we corrected it.  FWIW, it was actually Aaron who wrote that code ;)</div><div><br></div><div>AFAIK Tor2web hasn't leaked any privacy-invading headers for sometime.  If ones are discovered they would be fixed ASAP.</div><div><br></div><div><br></div><div>> Is the opt-out permanent, or does your server re-check every time it connects?</div><div>> I can imagine there being issues with either model - one involves storing a list, the other, regular connections.</div><div><br></div><div>I don't know.  This is Google/Bing's department.  Do we have someone on list familiar enough with either?  If I were to guess the Googley/Bingy-way of doing this, I'd imagine them storing the list, and then when crawling the site again they'd do a HEAD request to see if the /robots.txt has changed.  And if the /robots.txt has changed, to overwrite their stored list.</div><div><br></div><div><br></div><div>> I am disappointed that we have a Tor2web design where Tor2web needs to connect to a hidden service first, then check if it has given permission for Tor2web to connect to it.</div><div><br></div><div>/robots.txt isn't a permission to "connect to", it's a permission to crawl/index.  I'm aware of no standard within or outside of Tor to say whether node A has permission to connect to node B.  If such a standard or even unofficial exists I'm down for spending some weekends implementing it.</div><div><br></div><div>> I am also disappointed that this only works for HTTP onions on the default port 80.</div><div><br></div><div>I agree completely.  But if the issue is operator privacy, isn't it even *better* that tor2web only works for port 80?  As an aside, there is tor2tcp at: <a href="https://cryptoparty.at/tor2tcp">https://cryptoparty.at/tor2tcp</a></div><div><br></div><div><br></div><div>> I am also concerned about threat models where a single unwanted connection, or a number of unwanted connections, are security factors.</div><div>> For example:</div><div>> Imagine there is an (unknown) attack which can determine 1 bit of the 1024-bit RSA key per hidden service connection.</div><div>> (Some known attacks on broken crypto systems are like this, as are some side-channels.)</div><div>> Or imagine there is an attack which can determine 1 bit of the IPv4 address per connection.</div><div>> Is there an alternative to position (A) that supports threat models like this?<br></div><div><br></div><div>I don't have a good solution to this.  As stated above, I'm aware of no protocol for saying "Please don't connect to me."  The security person in me is a little skeptical how useful it would be---if someone wanted to make many connections to learn a private key, I presume she won't be obeying said requests.  However, if someone doesn't want to be connected to, upon such a standard existing I would happily abide by it.</div><div><br></div><div>> there is also the possibility of exerting social pressure to prevent people from running servers that continually connect to tor hidden services.</div><div><br></div><div>The closest things I know of for social pressure are:</div><div><br></div><div>(1) Liberal caching headers in the HTTP response:</div><div><br></div><div>```</div><div>max-age=604800<span class="" style="white-space:pre">  </span>   #can be cached by browser and any intermediary caches for up to 1 week</div><div>```</div><div><br></div><div>(2) In /robots.txt putting long crawl-delays:</div><div><br></div><div>```</div><div>User-Agent: *</div><div>Crawl-delay: 86400   #wait 1 day between each fetch.</div><div>```</div><div><br></div><div>> I believe that a technical solution to this threat model is hidden service client authentication (and the next-generation hidden service protocol, when available).</div><div><br></div><div>Agreed.</div><div><br></div><div>-V</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 7, 2016 at 1:44 PM, Tim Wilson-Brown - teor <span dir="ltr"><<a href="mailto:teor2345@gmail.com" target="_blank">teor2345@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 7 Jul 2016, at 15:24, Virgil Griffith <<a href="mailto:i@virgil.gr">i@virgil.gr</a>> wrote:<br>
><br>
> > How do you make sure that Tor2web users are anonymised (as possible) when accessing hidden services?<br>
><br>
> I make a good faith effort not to wantonly reveal personally identifying information.  But in short, it's hard.  I urge people to think of tor2web nodes as closer to Twitter where they record what links you click.  I wholly support having the "where is Tor2web in regards to user privacy" discussion (hopefully could even make some improvements to it!), but it is orthogonal to the "robots.txt on .onion" discussion.  Let's address the robots.txt issue and then we can return to Tor2web user-privacy.<br>
<br>
</span>Well, as a separate issue, you might want to remove the client IP address (X-Forwarded-For) from HTTP headers your caching proxies send to hidden services. And work out if any of the other headers are sensitive.<br>
<span class=""><br>
> On 7 Jul 2016, at 14:40, Virgil Griffith <<a href="mailto:i@virgil.gr">i@virgil.gr</a>> wrote:<br>
><br>
</span><span class="">> So now we have *three* different positions among respected members of the Tor community.<br>
><br>
> (A) isis et al: robots.txt is insufficient<br>
> --- "Consent is not the absence of saying 'no' — it is explicitly saying 'yes'."<br>
><br>
> (B) onionlink/ahmia/notevil/grams: we respect robots.txt<br>
> --- "Default is yes, but you can always opt-out."<br>
<br>
</span>Is the opt-out permanent, or does your server re-check every time it connects?<br>
I can imagine there being issues with either model - one involves storing a list, the other, regular connections.<br>
<span class=""><br>
> (C) onionstats/memex: we ignore robots.txt<br>
> --- "Don't care even if you opt-out." (see <a href="https://onionscan.org/reports/may2016.html" rel="noreferrer" target="_blank">https://onionscan.org/reports/may2016.html</a>)<br>
><br>
><br>
> Isis did a good job arguing for (A) by claiming that representing (B) and (C) are "blatant and disgusting workaround[s] to the trust and expectations which onion service operators place in the network." <a href="https://lists.torproject.org/pipermail/tor-project/2016-May/000356.html" rel="noreferrer" target="_blank">https://lists.torproject.org/pipermail/tor-project/2016-May/000356.html</a><br>
><br>
> This is me arguing for (B): <a href="https://lists.torproject.org/pipermail/tor-project/2016-May/000411.html" rel="noreferrer" target="_blank">https://lists.torproject.org/pipermail/tor-project/2016-May/000411.html</a><br>
><br>
> I have no link arguing for (C).<br>
<br>
</span>I am disappointed that we have a Tor2web design where Tor2web needs to connect to a hidden service first, then check if it has given permission for Tor2web to connect to it. I am also disappointed that this only works for HTTP onions on the default port 80.<br>
<br>
I would like to see a much better design for this.<br>
<br>
I am also concerned about threat models where a single unwanted connection, or a number of unwanted connections, are security factors.<br>
For example:<br>
Imagine there is an (unknown) attack which can determine 1 bit of the 1024-bit RSA key per hidden service connection.<br>
(Some known attacks on broken crypto systems are like this, as are some side-channels.)<br>
Or imagine there is an attack which can determine 1 bit of the IPv4 address per connection.<br>
<br>
For security, a hidden service operator decides to only allow 10 connections before rolling over their hidden service to a new key and server.<br>
<br>
There are at least 10 connections to known .onion addresses every week, because there are at least 10 Tor2web or memex or onionstats instances on the web.<br>
Therefore, every week, the operator must roll over their hidden service, and arrange to notify users of the new address in a secure fashion. Alternately, they must keep the address secret, even from the HSDir hash ring, which is not possible.<br>
<br>
Is there an alternative to position (A) that supports threat models like this?<br>
<br>
I believe that a technical solution to this threat model is hidden service client authentication (and the next-generation hidden service protocol, when available).<br>
However, there is also the possibility of exerting social pressure to prevent people from running servers that continually connect to tor hidden services.<br>
<div class="HOEnZb"><div class="h5"><br>
Tim<br>
<br>
Tim Wilson-Brown (teor)<br>
<br>
teor2345 at gmail dot com<br>
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B<br>
ricochet:ekmygaiu4rzgsk6n<br>
<br>
<br>
<br>
<br>
<br>
Tim<br>
<br>
Tim Wilson-Brown (teor)<br>
<br>
teor2345 at gmail dot com<br>
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B<br>
ricochet:ekmygaiu4rzgsk6n<br>
<br>
<br>
<br>
<br>
</div></div><br>_______________________________________________<br>
tor-project mailing list<br>
<a href="mailto:tor-project@lists.torproject.org">tor-project@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project</a><br>
<br></blockquote></div><br></div>