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@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk