Re: [tor-talk] hidden services 2.0 brainstorming

[proper <torbox@xxxxxxxxxx>]

Fabio Pietrosanti (naif):
> Yo,
> 
> i really appreciate such discussion about empowering TorHS, a lot of
> work still have to be done to make proper leverage of the capabilities
> that TorHS provide.
> 
> On 7/11/12 5:36 PM, proper wrote:
>> I think the concept of hidden services has a lot potential. Not only
>> because they are hidden. Let's face it:
>> - You get a free domain for live.
>> - You get transparent, free end to end encryption. No flawed root CA system.
>> - That's something remarkable, isn't it?
>>
>> With some modifications/improvements they could be potentially used for
>> any website, such as as e-commerce, google, twitter, facebook etc.
> 
> Don't exaggerate, it still need a software client to access them, so the
> usability is heavily impacted.

If the software is good it can be integrated into any operating system,
just like direct x is on any recent windows or gpg is in any recent
linux distro.

> This imply that TorHS are not for general uses in the context of mutual
> anonymity .

I didn't mean this.

>>
>> hidden services "1.0" as of July 2012 features:
>> - "optional" [1] client anonymity
> Standard Tor Client are always anonymous.

Of course, I just wanted to say, may be deactivated.

>> - "optional" [2] server anonymity
> Server is always anonymous.

Of course, I just wanted to say, may be deactivated.

>> - somewhat slow both, when client anonymity and server anonymity are active
>> - free live time domain
>> - no domain registrar can mess up
>> - somewhat [3] secure
>> - very few useful legitimate hidden services exist [4]
>>
>> ideas for hidden services "2.0":
>> - Marketing: Free domain for live!
>> - Marketing: Safer than SSL!
> It's not a replacement to SSL, it provide some good end-to-end crypto
> but does not provide you the same feature of SSL (like
> identification/authentication of a trust chain, client side
> authentication, certificate protection, etc).

Optional client authentication could be also added for hidden services
2.0. There are some use cases. For what would we need a trust chain?
Certificate protection depends on local security.

>> - "optional" [1] client anonymity
> Standard Tor Client are always anonymous.

Of course, I just wanted to say, may be deactivated.

>> - "optional" server anonymity
> Server is always anonymous.

Of course, I just wanted to say, may be deactivated.

>> - add an option to let the server and/or client connect non-anonymously [6]
>> - somewhat slow both, client anonymity and server anonymity are active
> Please consider that most of the issues with TorHS are not related to
> bandwidth but are related to responsiveness (round-trip).
>> - fast if only one uses anonymity
>> - very fast if none use anonymity
>> - establish new human friendly name system [7]
>> - improved stability, reachability, performance and dos protection features
>>
>> advantages:
>> - More legitimate hidden services. Better reputation for Tor.
>> - Real solution for the flawed root CA system.
>> - Say goodbye to the DNS hierarchy system, DNS spoofing etc. Free
>> domains, domain security depends on local security, not on registrar /
>> DNS system.
>> - Tor gets more known and gets more relay / bridge contributors.
>> - Safes exit bandwidth.
>>
>> [1] Optional because if Tor2webMode is set to 1: Tor connects to hidden
>> services non-anonymously. As far I know it connects to the rondevouz
>> point directly, server of course stays anonymous.
> That's something only for tor2web uses, where it's explained that there
> is NO anonymity for the client.
> As a safeguard tor2web mode need to be enabled at build-time and it's
> not generally available in publicly available Tor binaries.

I was just stating the technical possibilities.

>> [2] There are exit enclaves. The server acts as exit and allows to exit
>> to it's own IP.
> The Tor exit enclaves are not based on Tor HS.
> As far as i remember Tor Exit Enclaves are "dead".

I was just stating the technical possibilities.

>> [3] Please don't make that the topic here. What I mean is the domain
>> name may not be long enough, weak sha1 hash and the encryption keys are
>> not the most up to date, strongest ones.
> There's still no way to secure the TorHS key provided by Tor.
> I'd love if someone would take on
> https://trac.torproject.org/projects/tor/ticket/5976 .
> 
>> [4] Depends on opinion, anyway, much more legitimate and useful servers
>> can not hurt. Let's not make this the topic here.
>> [5] One hop circuit or can you even make a 0 hop circuit, i.e. direct
>> connection?
>> [6] Non-anonymous domains could use something else, not .onion.
>> [7] There is already at least one proposal, pet name system.
> I would love if someone would implement something like that, we got some
> ideas to work.
> 
> Imho we may have to discuss / and/or formalize better a concept to make
> a Tor2web network grow exponentially and with somehow automatic network
> joining/leaving/adaptation with NO manual intervention.

Feel free to start a wiki site. Discuss, in-cooperate unclear points. I
should also do this after discussing this proposal.

> That way it may be possible to create a big Tor2web network, acting as a
> public access backbone to TorHS (always inviting the client to download
> and use Tor, explaining with a big warning they are not anonymous)
> 
> If many very cool service on TorHS starts, it would operate as an
> stimulus to use TorHS, exposing that Websites over the internet
> (client-free = maximum usability).
> 
> -naif
> _______________________________________________
> tor-talk mailing list
> tor-talk@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
> 


_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk