Re: [tor-dev] Draft of proposal Direct Onion Services: Fast-but-not-hidden services
Date: Fri, 10 Apr 2015 15:47:23 +0300 From: George Kadianakis desnac...@riseup.net David Goulet dgou...@ev0ke.net writes: On 09 Apr (21:58:49), George Kadianakis wrote: Hello, I inline a proposal for Direct Onion Services. It's heavily based on the encrypted services proposal of Roger, but I refined it, made it more proposaley and enabled a few more optimizations. You can find the original piece here: https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-encrypted-services.txt Feedback would be greatly appreciated. [snip] - We really really need a better name for this feature. I decided to go with Direct Onion Services which is the one that the NRL people suggested here: https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.html I'm not super happy with it, but I can't think of better ones myself. Here are some candidates: 1 Way Anonymous Hidden Services Fast Onion Service Short-circuited Onion Services Fast-but-not-hidden Services Fast Onion-Space Service was proposed by pfmbot on #tor-dev. I like it because it describes pretty much what it is and the acronym is FOSS. :) It's not clear to me why acronym collisions are a plus :) - We also need a better torrc option. If the name of this feature does not portray its dangers, then the torrc option should be a bit terrifying. That's why I went 'DangerousDirectOnionService' which I actually don't like at all. BTW, it's unclear whether this mailing list is the best place to brainstorm for names. This one depends on the name quite heavily but I don't think we should have a scary name. Scary name seems to me they will simply bring more questions without context of the actual feature. What is Dangerous about this, why is it in Tor at all?... This could simply be resolved by clear and thorough documentation of the risks/benefits of the options. For instance, we could *not* put it in the default torrc file and thus will only be in the man page with *good* documentation. Like you said also in the proposal, a big warning is very important at boot. If it's off by default and not present in the torrc file, there are no reasons why someone would enable this just because it's says DirectOnionServiceEnable. (Ok I might be an optimist but still, we are not that responsible for reckless HS operator ;) Yes, I agree that the 'Dangerous' prefix is stupid. I think I'm OK with changing the proposal to use 'DirectOnionServiceEnable' but I would prefer if it's a bit more alarming. [snip] I've been hesitant to weigh in on the naming conversation for hidden services. But I am concerned about the issues raised in the previous few emails on the topic. Matt @ Speak Freely has a strong point about acronym collisions - they only serve to confuse users and dilute the search space. And usability becomes a security issue as soon as names are confusing to users. Others have also made important points about how we name things in general. So I'd like to propose some general naming principles, mostly distilled from recent conversations about names: 1. Avoid acronyms that collide with popular acronyms, particularly those in the security / software / technology spaces. 2. Names should be kept consistent across the entire Tor code base and ecosystem. 3. When selecting option, feature, and concept names: A) Names should describe the most important user-visible impact of an option, feature, or concept. B) If the feature has a serious impact on anonymity (or other typical user assumptions), the name should indicate that. C) Names should avoid specific implementation details, as these may change. D) Names should avoid giving relative opinions on performance, security, or privacy impacts, as these are often dependent on context. E) Project names are an exception to principle 3, and should have abstract names, or descriptive acronyms. My evaluation of the suggestions around hidden services / onion services based on these principles is: Onion Service Collides with OS, or Operating System, violating principle 1: no collisions. If we decide to disregard this acronym collision, and accept the usability impact, every option and the entire manual page should be changed in the same release, to satisfy principle 2. This would involve a transition period in which both HS and OS options would work. (We should also consider the usability of options with OS in the name before making the switch.) Direct Onion Service Dangerous Direct Onion Service As it's already been noted, these collide with DOS and DDOS (1), and don't describe which end is direct (3A 3B). Fast Onion Service Short-circuited Onion Services I'm concerned about the collisions with OS implied by these acronyms (1). Also, the first provides a performance goal (3D), and the second, an implementation detail (3C). Neither describes the most important user-visible
[tor-dev] Big performance improvement for meek-azure
I found and fixed a big performance limitation in the meek-azure transport. If you tried meek-azure before, but it was too slow, give it another try! meek-azure has always seemed slower than the other two backends, and I recently spent the time to figure out why. It was a lack of persistent HTTP connections between the Azure host and the Tor bridge. Every single HTTP request was doing a complete TCP and TLS handshake. This of course increased latency, but the bottleneck was actually CPU on the bridge, as it tried to cope with all those TLS handshakes. Here is the commit that causes connections to be shared and reused: https://gitweb.torproject.org/pluggable-transports/meek.git/commit/?id=e06bcf2c849075cf241addf2182dfc0125a35c92 This issue did not affect meek-google because the App Engine URL fetch API reuses HTTP connections transparently. It did not affect meek-amazon because the CloudFront CDN does its own connection reuse. Usage on meek-azure has already increased in the past few days since I started testing the change. I attached a graph that shows the all-time bandwidth history of the bridge. https://globe.torproject.org/#/bridge/AA033EEB61601B2B7312D89B62AAA23DC3ED8A34 David Fifield ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Are DAC_OVERRIDE CHOWN capabilities required for ControlSocket?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, tor will fail to startup with the current systemd service file [1] if your torrc makes use of the ControlSocket feature. To work around the issue one has to additionally allow the following capabilities: CAP_DAC_OVERRIDE CAP_CHOWN since the socket file is create as root and then changed to the tor user (chown). Is it possible to change this to not require CAP_DAC_OVERRIDE and CAP_CHOWN capabilities anymore? thanks, Nusenu [1] https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in#n 26 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVKmkiAAoJEFv7XvVCELh0Qk8QAITqZiFwp+nBIywWgLLQ5m6K CNkRa+HcNk3sCJKFWOzXqLP4Q1mIUrPWT6Mm+LbwLvo8uRnJqBNL5H0F+kDgYfyO wAsnRicwmoNfHa8hb292nj4p4eV/gQf9J94/creDl99jrtlgYBeLWY8toUZy452x QvAny7EC9Gt06/zMyNJxvVhb1SgthLsIfN6LXizH0Xe1y6m1Kh4XW/py5nvuMwmR sZg1QyUxQ8uJIs73J0KnuGZrzloJGN6IZmJ4EZ250gTUty3VtgvOTAu7W6KsGC2F dyHFqbJqHnEPLUn2ITxcmxBGduG7TWueh1+2KElVMQI9+j8IsD+9xGHUPtiywVEJ VpxaUlDqOu0tNovRPzkM01pg9KTqvydJ7BgAV0GgpoAH1rnYuEIh+kqieHvOLN96 uSuOjzTD87sHClWfIhuf645GCK+iy2Ln6f8yzxZn2DT870/yraX7eCaAK6gQt803 FMdBY2qtw3rFuGMW9ca/LTGlu04BrQb/boIEMhUMLdfAdBbJxYPuTbKbtBCbfcew NtB+5sxAuy2o8XcHsX/6gjDBi4rb7xp5QKy5xgsavE+uqyXAwCKNFF5yT7HNYX33 UMnSG1069frMXAGTYAPzQp+7dVLGs6h+xPx8aut/SoZqHjQOxQ6Qv5PtgltRvfv3 ZsOrqE5a0aly6OsspTUN =/5TL -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Are DAC_OVERRIDE CHOWN capabilities required for ControlSocket?
On Sun, 12 Apr 2015 12:46:26 + Nusenu nus...@openmailbox.org wrote: tor will fail to startup with the current systemd service file [1] if your torrc makes use of the ControlSocket feature. To work around the issue one has to additionally allow the following capabilities: CAP_DAC_OVERRIDE CAP_CHOWN since the socket file is create as root and then changed to the tor user (chown). Is it possible to change this to not require CAP_DAC_OVERRIDE and CAP_CHOWN capabilities anymore? I bet using the AF_UNIX SocksPort stuff will break as well, since the code is common. All of the listeners are launched before switching uid/gid and dropping privileges since it's common code. The way to fix this would be to change retry_listener_ports and retry_all_listeners code to additionally allow only launching service ports ( 1024), and staging the listener launch process on config (re)load to something that looks like: 1. Launch listeners that require elevated priviledges (CAP_NET_BIND_SERVICE). 2. Drop priviledges and switch the uid/gid. 3. Launch the rest of the listeners, including all of the AF_UNIX based ones (as the runtime tor user, so neither privilege is required). Patches accepted. -- Yawning Angel pgpCrZZmkj5AW.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Are DAC_OVERRIDE CHOWN capabilities required for ControlSocket?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Thanks for the reply, I added a trac entry: https://bugs.torproject.org/15659 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVKnKuAAoJEFv7XvVCELh0lLUP/0VeXYEeGOI9acQtvY0WoCP/ Qjq6i6h6bRFsmPqs3pa9qqUPKo6RChE0tM8ky+kV3b+DfuFR9oCFxokTG/C3g3Go pwkvfvh7JNP9HC/vHxLa3/a90gW1999UXz4aevqqz6GvBXKUphHWIP9T1hVSlBn3 FLMaA92PrpjaDGD8HSbgO6DQ8SAQjkaMRnrpP5fJscdpKvd3DI4uJQDmdDmcSCHP 90HffJeJcSogOhTLKE7V9oUgeIG/9glIV0fDH/pg/Z1ld5utZmNNngj8lzTJzwS6 8CtYtP8mZV+hz1IZId1aZngWBtuv78+LtuZlYG5s8OK8xr5Q2SXiyoHQSiVIYnea fF+Y7R0uSXZtzILQPXASQDo7TzfOq7tQP5Ro4ccFXNQWJ2mz+PpYUkWoswI8HJdY lc22t8OrIawknTWbmcPJeKuxjPvgeyH9tRQDiv+OrgAxAejNevHP8UgDadtuMin5 2mPtOCx72KrnEUa62IS3a9uOCGWCMadYXSPf6iWB7C9wXTSUaTDF5FBR0GZQt1fu d0vLsqzpgQG5UZp1ZY/Wo3rji5sOdJXWbghkjPIkixrx65zn10RnU/uplj9OVzUr Yhe6H60N5wNXkJS9VSFkUUfg5El5HSV0sVyedLk/e9ygQM54wg7EOBpn0lUNtjJ+ dZk6MNtRxNtT3epNomFC =rNyC -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Draft of proposal Direct Onion Services: Fast-but-not-hidden services
On Fri, 10 Apr 2015 13:59:05 + Speak Freely when2plus2...@riseup.net wrote: Half in jest, half serious, how about Peeled Onion Service? As this proposal is intended to peel away certain features... It clearly indicates that though it is an Onion Service, it is not a full fledged Onion Service with all the bells and whistles - they were peeled away! I think that is good and could also be backronymed into Public Onion Service. That would mean we'd have Hidden Onion Services and Public Onion Services and the Dangerous part could be omitted as it would be obvious what the dangers were. Sincerely, Malte ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] TSOP proposal
Hello tor-dev, I'm a master student researching computational stylometry (analyzing writing style of typed texts) in adversarial settings. Computational stylometry is a danger to the anonymity of authors who do not take appropriate precautions. A draft TSOP proposal is attached, it builds upon my academic research. I mailed tor-assistants about my TSOP proposal and Damian informed me that it might be difficult to find a mentor for this project. I am mailing tor-dev in the hope of finding someone who is willing and able to be my mentor for this TSOP project. The application that I would like to write will be my first non-web application that targets non-technical users (as opposed to academic users). A lot of machine learning and NLP will be used, but I don't need a mentor for that. Although I have mostly worked in groups (academic and professional) I have carried this research project myself and I am confident in my ability to continue to do so. If you have any questions please contact me. Hoping to find a mentor for this project, Kind regards, Rémi. TSOP.pdf Description: Adobe PDF document ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
