Re: [tor-dev] User perception of onion service discovery

[dawuud]

I agree with Alec. Don't block the existing tor2web stuff,
that would be very rude. Instead just do not implement any
kind of tor2web for v3 onion services so that tor2web will
gradually fade as we migrate.

> *although speaking as a geek I believe that re-engineering T2W to
> support SSL via SNI-Sniffing would address this, it would be a gross
> and pointless hack, complicated still further by certificate issuance,
> and all reasonable use cases for which would be better addressed by
> running a local copy of Tor.

Ah yeah, Donncha wrote a tool to do that called oniongateway:

https://github.com/DonnchaC/oniongateway

Is that what you mean?


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] The Tor git master branch is now 0.3.3.x

[Nick Mathewson]

Hello!

With the opening of the new 0.3.3.x branch, the git master branch for
tor is now 0.3.3.x.  Feature patches should still be based on master.
If you are writing any bugfix patch that should go into an earlier
version, please base it on the appropriate maint branch.  For example,
if you're fixing a bug in Tor 0.3.2.x, you should base your git branch
on the "maint-0.3.2" branch.

best wishes,
-- 
Nick
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] No network-team IRC meetings this week

[Nick Mathewson]

Hi, all!

The usual network-team IRC meeting on Monday, and the usual patch
party on Tuesday, will not happen this week: almost everybody will
traveling from, or recovering from, the meeting in Montreal.

For more information about our regular meetings, please see:
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam

Remember, new contributors and external developers are always welcome!

yrs,
-- 
Nick
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] User perception of onion service discovery

[teor]

> On 15 Oct 2017, at 04:08, Alec Muffett  wrote:
> 
>> On 14 October 2017 at 19:43, dawuud  wrote:
>> Plaintext communications intermediaries like tor2web violate the end
>> to end principle and the principle of least authority. If we as the
>> Tor community are committed to human rights then it follows we would
>> abolish terrible things like tor2web or at least frown upon it's use.
> 
> 
> 
> I would recommend continuing to enable/support Tor2Web, or at least not 
> moving to make such a solution inoperable.

v2 onion service Tor2web would be easy for HSDirs to block, due to an
implementation bug. We've chosen not to block it. But we haven't spent
much time on fixing its bugs, either.

As far as I am aware, no-one is writing Tor2web for v3 onion services.

We have open tickets for protecting relays that handle onion service traffic
from knowing both the client and service IP address.

So if anyone does write v3 Tor2web, they will need to write it so it:
* uses a 3-hop path for all descriptors, because otherwise that can be used
   for a selective denial of service;
* uses a 3-hop path to connect to intro and rend when a descriptor has the
  single onion service flag;
* retry using a 3-hop path on failure (internal reachability or actual 
connection
   failure)

And I'm not sure whether we would merge this feature into core tor, due to the
user security issues that David and others have mentioned.

T___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] User perception of onion service discovery

[Alec Muffett]

On 14 October 2017 at 19:43, dawuud  wrote:
>
> Plaintext communications intermediaries like tor2web violate the end
> to end principle and the principle of least authority. If we as the
> Tor community are committed to human rights then it follows we would
> abolish terrible things like tor2web or at least frown upon it's use.
>


I would recommend continuing to enable/support Tor2Web, or at least not
moving to make such a solution inoperable.


Dawuud is absolutely right re: violation of E2E* and a bunch of other
criticisms also apply; however I have three observations on this topic:

1) Someone invented Tor2web, therefore someone else is likely to want to
reimplement it; ideas tend to persist in this way

2) (as observed above) Google *do* crawl onion sites via "onion.to", which
is a fun surprise for people who insist that "The Dark Web Is Not Indexed
And Is Therefore Spooky"

3) Making such a move to block Tor2web-like sites might engender false
trust amongst the people who set up Onion sites: "It's Okay, Google Can't
Get At Us"


I would recommend investing more effort in Tor2web/similar, because having
a permeable barrier between IP-Space and OnionSpace appears useful.

At very most I might propose that:

a) OnionSites become aware of the X-Tor2web header which (from legit T2W
instances, at least) permits the OnionSite operator to block or redirect
the user to use a "proper" Onion network connection

b) That TheTorProject consider indexing known Tor2web sites and publish
them, perhaps adding a feature to optionally block them from TorBrowser
access**, thereby to prevent stupid intra-Tor deanonymisation loops

- a


*although speaking as a geek I believe that re-engineering T2W to support
SSL via SNI-Sniffing would address this, it would be a gross and pointless
hack, complicated still further by certificate issuance, and all reasonable
use cases for which would be better addressed by running a local copy of
Tor.

**the hardcore alternative of blocking them from being accessed by exit
nodes causing a likely-intolerable argument.


-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev