Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
Yawning Angel yawn...@schwanenlied.me writes: Cool! I added a quick try at using this in txtorcon, with an example; see the following branch: https://github.com/meejah/txtorcon/tree/yawning-feature-6411 (Most of that example code would actually end up in the endpoint.listen() code and be hidden from most users of the library, too. And would be the default instead of launch a new tor). This does not support `HiddenServiceAuthorizeClient` yet in any way (neither basic nor stealth). It may in the future, but coming up with a sane interface for it is way more pain than I am willing to self-inflict at the moment. What about a similar API: add + remove a client-key. And similarly, you could push a key yourself, or ask for a new one. The only difference would be including the onion-address. Like: ADD_EPH_HS_ADD_CLIENT_AUTH kittenmeowae41f nickname0 stealth NEW:BEST ADD_EPH_HS_ADD_CLIENT_AUTH kittenmeowae41f nickname1 basic NEW:BEST The return value would be the cookie (for basic) or both the cookie and the key-blob for stealth. Or NEW:BEST could be RSA1024:. like the other API? For deleting you'd pass the onion ID and the nickname I guess. Like: ADD_EPH_HS_DEL_CLIENT_AUTH kittenmeowae41f nickname1 * meejah suggested that ephemeral hidden services should have their lifetime tied to the originating control port connection. I think this is a good idea, but this would be the only control port command that does this sort of thing. __OwningControllerProcess is similar, I guess, but instead ties to the whole lifetime of Tor (which sounds way easier to implement ;) Questions, comments, feedback appreciated, I think it's looking quite nice! -- meejah ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
Hi Yawning, nice addition! As requested moving from irc to here. One gotcha to think about is that ADD_EPH_HS is using a variable number of positional arguments. This will limit your ability to expand this command in the future with new arguments. Also, I'd suggest renaming addrPort to addrTarget (to avoid making this sound restricted to a simple port). Other than that spec looks great. Looking forward to it! -Damian On Fri, Feb 13, 2015 at 4:45 PM, Yawning Angel yawn...@schwanenlied.me wrote: Hi, The Warning: DO NOT USE MY BRANCH YET, IT HAS HAD MINIMAL TESTING AND REVIEW. IT IS NOT DONE. IT WILL BROADCAST YOUR SECRETS TO THE NSA'S ORBITAL SPACE STATION. Trac Ticket: https://trac.torproject.org/projects/tor/ticket/6411 Branch: https://github.com/Yawning/tor/compare/feature6411 With that out of the way, I've been poking at implementing a way to add hidden services at runtime via the control port. I'm calling this ephemeral hidden services because the HS state is not written out to disk, and they disappear when the tor damon is shutdown. Yes, this means that if you run kittensomgmewmew.onion and are scared of the NSA's persistent attempts to extract your hidden service key, via ultrasonic laser beamed from their satellites, you could run your tor instance entirely in a ram disk, and load the HS key manually each time from a USB token you wear around your neck. What I've come up with looks like this: ADD_EPH_HS - Adds a new ephemeral hidden service. The syntax is: ADD_EPH_HS keytype:keyblob SP 1*(port SP addrPort) CRLF keytype = RSA1024, NEW keyblob = opaque ascii serialized key material, or an algorithm specifier, in the case of keytype == NEW. port = the VIRTPORT addrPort = the TARGET A hidden service is created using the key and list of port/targets, that will persist till configuration reload or the termination of the tor process. The currently supported keytypes and keyblobs are: RSA1024 - The keyblob contains the Base64 encoding of the PKCS#1 layout DER representation of a 1024 bit RSA private key. NEW - The tor instance should generate a key with the keytype specified in the keyblob parameter. A type of BEST will generate a key using the best supported algorithm. Returns: 250-ServiceID=serviceID - The hidden service's onion address without the .onion suffix. 250-PrivateKey=keytype:keyblob - The newly generated hidden service's private key, if a keytype of NEW was specified. 250 OK - Everything went well. Proper key management, is left as an exercise for the application invoking the controller command. DEL_EPH_HS - Removes an existing ephemeral hidden service. The syntax is: DEL_EPH_HS serviceID CRLF serviceID = the hidden service identifier, without the trailing .onion suffix The hidden service specified by the given service ID is removed, and the intro points are closed. Existing connections are left as is, and it is up to the application to close them if it wishes to do so. Examples: * Adding a new ephemeral hidden service, with a pre-generated RSA key: ADD_EPH_HS RSA1024:[Base64 blob] 80 127.0.0.1:8080 250-ServiceID=blahblahblahblah 250 OK Hidden service is reachable at blahblahblahblah.onion:80 * Adding a new ephemeral hidden service, tor generates a new RSA key: ADD_EPH_HS NEW:RSA1024 22 127.0.0.1:22 250-ServiceID=hogehogehogehoge 250-PrivateKey=RSA1024:[Base64 blob] 250 OK Hidden service is reachable at hogehogehogehoge.onion:22. At a later date, the value passed back as PrivateKey can be used to re-create the hidden service. * Add a new ephemeral hidden service, tor picks the algorithm: ADD_EPH_HS NEW:BEST 1245 192.168.1.5:23 250-ServiceID=hemohemohemohemo 250-PrivateKey=Ed25519:[Base64 blob] 250 OK Hidden service is reachable at hemohemohemohemo:23. (nb: Ed25519 key support is not actually implemented yet, and is used as an example of a better algorithm.) * Remove the hidden service configured in the first example: DEL_EPH_HS blahblahblahblah 250 OK Note: ADD_EPH_HS can take more than one VIRTPORT/TARGET pair at once, the examples only show one pair for brevity. This does not support `HiddenServiceAuthorizeClient` yet in any way (neither basic nor stealth). It may in the future, but coming up with a sane interface for it is way more pain than I am willing to self-inflict at the moment. Design question that I want feedback on, primarily from control port library maintainers, and authors of applications that use the control port: * meejah suggested that ephemeral hidden services should have their lifetime tied to the originating
Re: [tor-dev] Fwd: Orbot v15-alpha-3 with VPN and Meek!
On 14/02/15 08:58, Nathan Freitas wrote: - Original message - From: Nathan of Guardian nat...@guardianproject.info To: guardian-...@lists.mayfirst.org Subject: Orbot v15-alpha-3 with VPN and Meek! Date: Sat, 14 Feb 2015 02:57:34 -0500 More progress on Orbot VPN support, and now, thanks to our new PLUTO library (https://github.com/guardianproject/pluto), support for Meek (https://trac.torproject.org/projects/tor/wiki/doc/meek) and soon Obfs4 as well. Currently you can use Meek or you can use VPN, but you can't use both together... still working on that, as I can't get Meek to talk to the passthrough HTTP proxy I use to allow socket connections out of the VPN filter. To use Meek, just enable the Bridges button on the home screen, without using any bridge config info, and it will default to using the Meek Azure instance. If you set the bridge line to 0 it will use Google, and 1 it will use Amazon, and 2 it will use Azure. The VPN mode is just as easy, just enable VPN using the homescreen toggle button, then start/restart Orbot. All apps on your phone should now be running through Tor. Remember, Bridges and VPN don't work at the same time, for now... but please test both features separately, and let me know how well they work for you. APK: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-3.apk SIG: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-3.apk.asc Source: https://gitweb.torproject.org/n8fr8/orbot.git/log/?h=v15-dev or https://github.com/n8fr8/orbot/tree/v15-dev Hello Nathan! Glad seeing this VPN part going further! I just have concerns regarding my app compatibility (orwall): does orbot still opens ports on localhost, and are they still the same, or shall I detect orbot version and/or probe for opened ports? I'll give a try to this alpha version shortly hopefully (time is a weird thing fleeing at light speed). Cheers, C. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Fwd: Orbot v15-alpha-3 with VPN and Meek!
On Sat, Feb 14, 2015, at 03:04 AM, CJ wrote: On 14/02/15 08:58, Nathan Freitas wrote: - Original message - From: Nathan of Guardian nat...@guardianproject.info To: guardian-...@lists.mayfirst.org Subject: Orbot v15-alpha-3 with VPN and Meek! Date: Sat, 14 Feb 2015 02:57:34 -0500 More progress on Orbot VPN support, and now, thanks to our new PLUTO library (https://github.com/guardianproject/pluto), support for Meek (https://trac.torproject.org/projects/tor/wiki/doc/meek) and soon Obfs4 as well. Currently you can use Meek or you can use VPN, but you can't use both together... still working on that, as I can't get Meek to talk to the passthrough HTTP proxy I use to allow socket connections out of the VPN filter. To use Meek, just enable the Bridges button on the home screen, without using any bridge config info, and it will default to using the Meek Azure instance. If you set the bridge line to 0 it will use Google, and 1 it will use Amazon, and 2 it will use Azure. The VPN mode is just as easy, just enable VPN using the homescreen toggle button, then start/restart Orbot. All apps on your phone should now be running through Tor. Remember, Bridges and VPN don't work at the same time, for now... but please test both features separately, and let me know how well they work for you. APK: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-3.apk SIG: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-3.apk.asc Source: https://gitweb.torproject.org/n8fr8/orbot.git/log/?h=v15-dev or https://github.com/n8fr8/orbot/tree/v15-dev Hello Nathan! Glad seeing this VPN part going further! I just have concerns regarding my app compatibility (orwall): does orbot still opens ports on localhost, and are they still the same, or shall I detect orbot version and/or probe for opened ports? Everything is the same as usual. I don't think we can support both Orwall and VPN at the same time, so that will be another choice the user will have to make. The VPN doesn't fulfill the requirements of advanced users who want the level of protection provided by Orwall and what Mike Perry originally outlined. It is tricky to start on boot, there is no guarantee system services can't route around it, and it can be killed if Orbot crashes. Root and IPTables will still be required for that. VPN mode is really just for circumvention of app blocks by novice users. +n ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Fwd: Orbot v15-alpha-3 with VPN and Meek!
On Sat, Feb 14, 2015 at 12:08:10AM -0800, David Fifield wrote: An upstream HTTP proxy should work, either through torrc HTTPProxy or the --proxy option. Careful! The torrc HTTPProxy line is only for non-tunneled directory fetches. It's the HTTPSProxy line that most people want -- that causes Tor to send its TLS connections via the proxy using the CONNECT command. Unless meek does something way cool to redirect its browser requests or something. :) --Roger ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Fwd: Orbot v15-alpha-3 with VPN and Meek!
On Sat, Feb 14, 2015 at 03:22:38AM -0500, Roger Dingledine wrote: On Sat, Feb 14, 2015 at 12:08:10AM -0800, David Fifield wrote: An upstream HTTP proxy should work, either through torrc HTTPProxy or the --proxy option. Careful! The torrc HTTPProxy line is only for non-tunneled directory fetches. It's the HTTPSProxy line that most people want -- that causes Tor to send its TLS connections via the proxy using the CONNECT command. Okay, whatever it is that sets TOR_PT_PROXY, because that's what meek-client is reading. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
On 2/14/15 1:45 AM, Yawning Angel wrote: Hi, The Warning: DO NOT USE MY BRANCH YET, IT HAS HAD MINIMAL TESTING AND REVIEW. IT IS NOT DONE. IT WILL BROADCAST YOUR SECRETS TO THE NSA'S ORBITAL SPACE STATION. Trac Ticket: https://trac.torproject.org/projects/tor/ticket/6411 Branch: https://github.com/Yawning/tor/compare/feature6411 I'm fine with the proposal. That's an important part of a set of tickets designed to enable the use of a Tor integration without ever touching the filesystem within third party application and application controllers (such as TxTorCon/ORbot) . This complement the already closed #13865 (https://trac.torproject.org/projects/tor/ticket/6411) and the yet-to-be-discussed #14899 (Enable Tor to work without using filesystem for cached files https://trac.torproject.org/projects/tor/ticket/14899). When #6411 will be integrated and #14899 will be implemented: - Tor AppArmor profile can be imporved by completely disabling filesystem read/write (when integrated with a third part app) - Third party App can fully use Tor by keeping all it's configuration directive, keys (for TorHS) and caches (for descriptors/consensus) in the application database Once all of that will be possible, we'll be able to make a 100% clean Tor integration into GlobaLeaks (that's undergoing an architecture refactor to have a master/slave process). -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - https://globaleaks.org - https://tor2web.org - https://ahmia.fi ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
On Sat, 14 Feb 2015 13:46:04 -0800 Damian Johnson ata...@torproject.org wrote: One gotcha to think about is that ADD_EPH_HS is using a variable number of positional arguments. This will limit your ability to expand this command in the future with new arguments. Also, I'd suggest renaming addrPort to addrTarget (to avoid making this sound restricted to a simple port). Hmm ok. Judging by the feedback, I'm thinking the following: * Auth is still a low-ish priority, I want to get the basic ephemeral stuff done first, and I need to read up more on how it works, and how the code is structured, before I can promise things in this area. * People seem to be ok with the tying ephemeral HSes to the originating control port (and if the only major argument against is it's a bit weird, relative to other things, well, eph. HSes are weird, and this solves a bunch of problems). So this will be implemented as planned. * ADD_EPH_HS syntax changed to something like: ADD_EPH_HS keytype:keyblob 1*(SP Port= virtPort , addrTarget) CRLF So, basically, space separated instances of Port=virtPort,addrTarget entries, of which there must be at least one. This clearly indicates the argument type and should be future proof (and also has the side benefit of being easier for me to validate. Thoughts? -- Yawning Angel pgp7Nxg_N4dT5.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
