[tor-dev] use tor in my app
I've written an Windows 7 Visual Basic application that downloads info from a website, that I'd like to use tor with. I've downloaded tor browser, and if I open the browser it establishes a connection to the tor network and my application runs just fine. However, if I instead run tor via tor.exe, my app gives the exception " No connection could be made because the target machine actively refused it 127.0.0.1:9150" which is the same message I get if I run the app without first starting tor. I confirmed that tor.exe is running as a process in Task Manager. I've tried multiple versions of torrc. My current one is: # This file was generated by Tor; if you edit it, comments will not be preserved # The old torrc file was renamed to torrc.orig.1 or similar, and Tor will ignore it AvoidDiskWrites 1 Log notice stdout #Log debug file c:/program files/tor/debug.log DataDirectory C:\Users\Terry\Desktop\Tor Browser\Browser\TorBrowser\Data\Tor DirReqStatistics 0 GeoIPFile C:\Users\Terry\Desktop\Tor Browser\Browser\TorBrowser\Data\Tor\geoip GeoIPv6File C:\Users\Terry\Desktop\Tor Browser\Browser\TorBrowser\Data\Tor\geoip6 SocksPort 9150 ControlPort 9151 CookieAuthentication 1 ## fteproxy configuration ClientTransportPlugin fte exec TorBrowser\Tor\PluggableTransports\fteproxy --managed ClientTransportPlugin flashproxy exec TorBrowser\Tor\PluggableTransports\flashproxy-client --register :0 :9000 ## meek configuration ClientTransportPlugin meek exec TorBrowser\Tor\PluggableTransports\terminateprocess-buffer TorBrowser\Tor\PluggableTransports\meek-client-torbrowser --exit-on-stdin-eof -- TorBrowser\Tor\PluggableTransports\meek-client I can't figure out what configuration settings the tor browser is using that are different from what's in the torrc. I've searched the documentation, and requested help from h...@rt.torproject.org, who tell me that my problem is outside the scope of the help desk, and suggested I try here. Any help/suggestions greatly appreciated. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Distributing TBB and Tails via Torrents
* Chuck Peters: > I have been trying to download the new Tails the past week via torrent > and the tracker seems to be broken. > > I know it isn't a good idea to use torrents over tor, but why doesn't > torproject.org distribute the TBB, Tails and other tor related software > with torrents? We discussed this in the past [0] and Moritz wrote a script [1] that generates the torrent files for the bundles. The only issue was that with a public tracker, it's trivial to find out who is participating in the download, and therefore, who is downloading the bundles. (You can also request bundles from GetTor which is back in operation [2], or using Satori.) [0] - https://bugs.torproject.org/9071 [1] - https://lists.torproject.org/pipermail/tor-talk/2011-March/019809.html [2] - https://blog.torproject.org/blog/say-hi-new-gettor -- Sukhbir ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] high latency hidden services
On Thu, Dec 11, 2014 at 8:26 AM, Michael Rogers wrote: > * Which links should carry chaff? First you need it to cover the communicating endpoints entry links at the edges. But if your endpoints aren't generating enough traffic to saturate the core, or even worse if there's not enough talking clients to multiplex each other through shared entry points densely enough, that's bad. So all links that any node has established to any other nodes seem to need chaffed. > We can't send chaff between every > pair of relays, especially as the network grows. Right, a full mesh is not necessary, only chaff the established links. Whether that includes today's idle prebuilt paths, or only upon actual user traffic, no idea yet. > * How much chaff should we send on each link? Today, all nodes have an idea that the most bw you're ever going to get out of the system anyways is up to your pipe capacity, whether you let it free run, or you set a limit... all within your personal or purchased limits. So you just decide how much you can bear, set your committed rate, and fill it up. > At present, relays don't > divide their bandwidth between links ahead of time - they allocate > bandwidth where it's needed. > The bandwidth allocated to each link > could be a smoothed function of the load This sounds like picking some chaff ratio (even a ratio function) and scaling up the overall link bandwidth as needed to carry enough overall wheat within that. Not sure if that works to cover the 'first, entries, GPA watching there' above. Seems too user session driven bursty at those places, or the ratio/scale function is too slow to accept fast wheat demand. So you need a constant flow of CAR to hide all style wheat demands in. I scrap the ethernet thinking and recall clocked ATM. You interleave your wheat in place of the base fixed rate chaff of the link as needed. You negotiate the bw at the switch (node). > but then we need to make > sure that instantaneous changes in the function's output don't leak > any information about instantaneous changes in its input. This is the point of filling the links fulltime, you don't see any such ripples. (Maybe instantaneous pressure gets translated into a new domain of some nominal random masking jitter below. Which may still be a bit ethernet-ish.) > That isn't trivial. What needs work is the bw negotiation protocol between nodes. You've set the CAR on your box, now how to divide it among established links? Does it reference other CARs in the consensus, does it accept subtractive link requests until full, does it span just one hop or the full path, is it part of each node's first hop link extension relative to itself as a circuit builds its way through, are there PVCs, SVCs, then the recalc as nodes and paths come and go, how far in does the wheat/chaff recognition go, etc? Do you need to drop any node that doesn't keep up RX/TX at the negotiated rate as then doing something nefarious? > * Is it acceptable to add any delay at all to low-latency traffic? My > assumption is no - people already complain about Tor being slow for > interactive protocols. No fixed delays, because yes it's annoyingly additive, and you probably can't clock packets onto the wire from userland Tor precisely enough for [1]. Recall the model... a serial bucket stream. Random jitter within an upper bound is different from fixed delay. Good question. [1 There was something I was trying to mask or prevent with jitter, I'll try to remember.] > So we'd still need to mark certain circuits as > high-latency, and only those circuits would benefit from chaff. High latency feels more like a class of service... not tied to selective chaffing on/off. I'll try to reread these parts from you. > Once you fill in those details, the chaffing approach looks pretty > similar to the approach I suggested: the relay treats low-latency > circuits in the same way as now, allocates some bandwidth to > high-latency traffic, and uses that bandwidth for data or padding > depending on whether it has any data to send. >> I can't see any other way to have both low latency and hide the >> talkers other than filling bandwidth committed links with talkers. >> And when you want to talk, just fill in your voice in place of the >> fake ones you'd otherwise send. That seems good against the GPA >> above. > > The alternative to filling the link with talkers is mixing the talkers > - - i.e. preventing the adversary from matching the circuits entering a > relay with the circuits leaving it. Well, there's the packet switched routing approach (mixed talking in that regard) vs. circuit switched. You can do chaff with either. But as way at the top, when you are the last hop and/or the net's not busy, you've no one to mix with, and must flood chaff. > But as I said above, when you get > down to the details these approaches start to look similar - perhaps > they're really just different ways of describing the same thing. Perhaps. > Some papers on this topi
Re: [tor-dev] Proposal draft: Better hidden service stats from Tor relays
On 11/12/14 15:45, Karsten Loesing wrote: Sorry for double-posting! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal draft: Better hidden service stats from Tor relays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/12/14 14:31, A. Johnson wrote: >> Can you be more explicit with regard to privacy guarantees of the >> obfuscation schema that is currently implemented: 1) binning, >> 2) add Laplace noise, 3) no second binning. > > I’ll discuss this in terms of attacks on the stats of the number > of HS descriptors. > > Binning: Suppose an adversary knows that the number of HS > descriptors stays constant over a week. He knows when all > descriptors are being published except for one. By binning he won’t > know when that one is published unless the number of other > descriptors exactly fills a bin. > > Laplace noise: To provide cover in the case that all other > descriptors exactly fill a bin, we add some noise so that > sometimes an adjacent bin is reported instead, or (less likely) a > bin two distant, etc. Then the adversary can’t immediately know > whether an unknown descriptor is indeed published in any given > period. However, he can eventually figure this out by making enough > observations and looking at the resulting empirical distribution. > But it’s better than not protecting it at all. Sounds good. George, maybe these explanations should go into the proposal, too. >> If you think 3) should be changed, can you explain why that >> leads to better privacy guarantees? > > I don’t think that 3 should be changed, but if you removed it, it > wouldn't affect the privacy argument. > >> I can see how the Laplace distribution doesn't add much noise to >> the second case. And your suggestion is to change the second >> delta_f to 8? > > Yes. Great. Changed the second delta_f to 8 in the code, and I think George will change it in the proposal. Thanks! All the best, Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJUia4mAAoJEJd5OEYhk8hImnYIAJD/TLsTRhL5UGYEMBoOnq+X gcOzVhrEg+fTHm1a6YSHPn0iPZvTDmg3w97XXl/IZg5L4Y84AAcHeuT6EXkmATT5 V52w5A1fdzOQ4Ef3f6wL0ZNPPG3qsFdv+nNRiiOuI1ASb0+5ML7hdU033up8l1zB 7CocU5rgACy2a6DMHPn4wPmXjlCPYcQ3ZUr/1xts63vxfQFes/D2ynUVEk6I/IUO YVz62WBg857RXWn8eIsdCF6TkRAJetyiIijPe5+Gs8r7XT+btINg7mS9SDynBWOB ee34vz/VqeczrAZZwq+yNTjENbsJCtyM5U8zHAiYarGnACmAYy50nnofhPjQ1/I= =3F1E -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] Proposal draft: Better hidden service stats from Tor relays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/12/14 14:31, A. Johnson wrote: >> Can you be more explicit with regard to privacy guarantees of the >> obfuscation schema that is currently implemented: 1) binning, >> 2) add Laplace noise, 3) no second binning. > > I’ll discuss this in terms of attacks on the stats of the number > of HS descriptors. > > Binning: Suppose an adversary knows that the number of HS > descriptors stays constant over a week. He knows when all > descriptors are being published except for one. By binning he won’t > know when that one is published unless the number of other > descriptors exactly fills a bin. > > Laplace noise: To provide cover in the case that all other > descriptors exactly fill a bin, we add some noise so that > sometimes an adjacent bin is reported instead, or (less likely) a > bin two distant, etc. Then the adversary can’t immediately know > whether an unknown descriptor is indeed published in any given > period. However, he can eventually figure this out by making enough > observations and looking at the resulting empirical distribution. > But it’s better than not protecting it at all. Sounds good. George, maybe these explanations should go into the proposal, too. >> If you think 3) should be changed, can you explain why that >> leads to better privacy guarantees? > > I don’t think that 3 should be changed, but if you removed it, it > wouldn't affect the privacy argument. > >> I can see how the Laplace distribution doesn't add much noise to >> the second case. And your suggestion is to change the second >> delta_f to 8? > > Yes. Great. Changed the second delta_f to 8 in the code, and I think George will change it in the proposal. Thanks! All the best, Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJUia4mAAoJEJd5OEYhk8hImnYIAJD/TLsTRhL5UGYEMBoOnq+X gcOzVhrEg+fTHm1a6YSHPn0iPZvTDmg3w97XXl/IZg5L4Y84AAcHeuT6EXkmATT5 V52w5A1fdzOQ4Ef3f6wL0ZNPPG3qsFdv+nNRiiOuI1ASb0+5ML7hdU033up8l1zB 7CocU5rgACy2a6DMHPn4wPmXjlCPYcQ3ZUr/1xts63vxfQFes/D2ynUVEk6I/IUO YVz62WBg857RXWn8eIsdCF6TkRAJetyiIijPe5+Gs8r7XT+btINg7mS9SDynBWOB ee34vz/VqeczrAZZwq+yNTjENbsJCtyM5U8zHAiYarGnACmAYy50nnofhPjQ1/I= =3F1E -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] Proposal draft: Better hidden service stats from Tor relays
> Can you be more explicit with regard to privacy guarantees of the > obfuscation schema that is currently implemented: 1) binning, 2) add > Laplace noise, 3) no second binning. I’ll discuss this in terms of attacks on the stats of the number of HS descriptors. Binning: Suppose an adversary knows that the number of HS descriptors stays constant over a week. He knows when all descriptors are being published except for one. By binning he won’t know when that one is published unless the number of other descriptors exactly fills a bin. Laplace noise: To provide cover in the case that all other descriptors exactly fill a bin, we add some noise so that sometimes an adjacent bin is reported instead, or (less likely) a bin two distant, etc. Then the adversary can’t immediately know whether an unknown descriptor is indeed published in any given period. However, he can eventually figure this out by making enough observations and looking at the resulting empirical distribution. But it’s better than not protecting it at all. > If you think 3) should be changed, can you explain why that leads to > better privacy guarantees? I don’t think that 3 should be changed, but if you removed it, it wouldn't affect the privacy argument. > I can see how the Laplace distribution doesn't add much noise to the > second case. And your suggestion is to change the second delta_f to 8? Yes. Best, Aaron ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] high latency hidden services
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/12/14 00:14, grarpamp wrote: > Guilty of tldr here, yet similarly, with the easily trackable > characteristics firstly above, I'm not seeing a benefit to > anything other than filling all links with chaff which then hides > all those parameters but one... I'm not opposed to this approach, but "filling all links" isn't as simple as it sounds: * Which links should carry chaff? We can't send chaff between every pair of relays, especially as the network grows. * How much chaff should we send on each link? At present relays don't divide their bandwidth between links ahead of time - they allocate bandwidth where it's needed. The bandwidth allocated to each link could be a smoothed function of the load - but then we need to make sure that instantaneous changes in the function's output don't leak any information about instantaneous changes in its input. That isn't trivial. * Is it acceptable to add any delay at all to low-latency traffic? My assumption is no - people already complain about Tor being slow for interactive protocols. So we'd still need to mark certain circuits as high-latency, and only those circuits would benefit from chaff. Once you fill in those details, the chaffing approach looks pretty similar to the approach I suggested: the relay treats low-latency circuits in the same way as now, allocates some bandwidth to high-latency traffic, and uses that bandwidth for data or padding depending on whether it has any data to send. > I can't see any other way to have both low latency and hide the > talkers other than filling bandwidth committed links with talkers. > And when you want to talk, just fill in your voice in place of the > fake ones you'd otherwise send. That seems good against the GPA > above. The alternative to filling the link with talkers is mixing the talkers - - i.e. preventing the adversary from matching the circuits entering a relay with the circuits leaving it. But as I said above, when you get down to the details these approaches start to look similar - perhaps they're really just different ways of describing the same thing. Some papers on this topic that I haven't read for a while: http://acsp.ece.cornell.edu/papers/VenkTong_Anonymous_08SSP.pdf http://www.csl.mtu.edu/cs6461/www/Reading/08/Wang-ccs08.pdf https://www.cosic.esat.kuleuven.be/publications/article-1230.pdf Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUiZt+AAoJEBEET9GfxSfMYsQH/iMCSvmQYxjGFZC5lzvpT06Z Ggjk+mflVkEDCKPt8e8ucQ7dp1URi9BS0wgxvo1PtSvEaO1C6m9NgyWHsNTXAMEn otpjn9szudJP1YV2vzWUrr32gWHK8ZLiji9JBlKW2fZXwkliSM9nltqgvRUeIXvD 9r/T5S5VDNFoow++05XASHCUjoQmj2baEO3H8xag+MEcy4vEMPby9Yf5pPVbEoEv uDwkRvRqqttUl7KC7A04M60214/LE/UCwKPlMzZRLjEo2dKPcnXxY5GWLz19OZ31 tawt8y8I/QRgn6l6R/W059eJkJKze1IqhEC8z5+IQD8SaTmY9Lxs10CqB9JGhMs= =BW/U -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] Proposal draft: Better hidden service stats from Tor relays
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/12/14 15:37, A. Johnson wrote: >> But I don't see the value of binning the result once more. In a >> sense, we're already binning signal + noise by cutting off the >> float part. I don't see what we gain by reducing resolution >> even more. It seems just unnecessary. > > In principle releasing the number could result in different > differential-privacy guarantees than releasing the bin. However, > the way I had in mind to set the Laplace parameters this wouldn’t > be an issue, because the Laplace distributions themselves would > satisfy the desired differential privacy guarantee (and not just > the resulting distribution on bins). > > So I guess this could be viewed as a post-processing step that is > useful for clarity rather than privacy: namely, that the output > should be interpreted as a range. But we could leave this to the > data consumer to apply without a privacy issue. Can you be more explicit with regard to privacy guarantees of the obfuscation schema that is currently implemented: 1) binning, 2) add Laplace noise, 3) no second binning. If you think 3) should be changed, can you explain why that leads to better privacy guarantees? > Also, I believe that the parameters we had discussed should > change. To see why, observe that the Laplace distributions for two > adjacent values that cross a bin barrier are now very far apart > after being recentered within the appropriate bins. Thus, \delta_f > should increase if it is smaller than the maximum number of bins > that can be crossed within that \delta_f multiplied by the bin > size. With our previous numbers, the new \delta_f for rendezvous > cell counts doesn’t change (still 2048), but the new \delta_f for > HS descriptors counts is 8. The current parameters are: * delta_f = 2048 * epsilon = 0.3 * bin_size = 1024 and * delta_f = 1 * epsilon = 0.3 * bin_size = 8 I can see how the Laplace distribution doesn't add much noise to the second case. And your suggestion is to change the second delta_f to 8? Thanks! All the best, Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJUiZFPAAoJEJd5OEYhk8hIJU8IAJNTNMuElPh96vTVWrEn9Sjt 811c2uF3I4jJIpcXGdGPfWNLuTAufXCVl+WBricccte04zYRCVzLy6Ww1JPDcQIr y7NkOwwZ2bbww2SMeHXllW1XKZcCVf72Oqt3YFLuUInPs68X3/20YzNKY+e7tVnJ 8EsH3zhgnHAMsEPBAZjG21gopfNJySPGgx2OAgLfur5WVu3VmiKUkEpqSreGyu8c MUsP8SFWWP9/Ninwq3MDZJmEDt+sux7dRn69Q6A8CDKnmVuJu/ilELOaioQ9bkZy 27N0/PQ8pE+dQBUIF89XyoedJ93/GptiNjRNwE1Wbjy53rnkpPeG7GdsusgO5yI= =MTG2 -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] contribute to org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/12/14 19:02, Ayush Jhunjhunwala wrote: > I am ayush jhunjhunwala. I am interested in the contributing to > the project - "Rewrite Tor Weather". I have read through the ideas > page given in the website. As I am new to this it will be grateful > if someone can guide me. Hello Ayush, thanks for wanting to contribute, but it's unclear whether Tor Weather is the best place to start. There's little activity on that project lately, and even if you'd want to change that, we'd need to find a person to review your patches and be your mentor of some sort. Maybe take another look at the volunteer page and pick a project with at least "light" or "moderate" activity: https://www.torproject.org/getinvolved/volunteer.html.en#Projects All the best, Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJUiV5HAAoJEJd5OEYhk8hI1qcH/RIMjmZhQNYpzZI+sVEX1u2P NkUGfhGC2hCc5kgT4b65tAwbOi0vg6WoWJTeuZHg15tdrNS4JpeEjM88wrRl6CB7 P1yIW5XeR4WEO102FJBBb1l+OmSWFGjlSRDVaZlcQk/gEo/L87eNElDXFlFd2gxE lvZWp1G5lq7grE0ArnUrDoqZI9qjCxMWNBdpmTx8c3XwyOdZk/UNpgrmBai7ZnH/ ftjm877KDQmyPf8B09uFWvqZXD452vKUEbhVIikoCr05dmEUszN9BvPiUAQMyJVS q0zFZxPZC3ey+CcNB2breBG49+hA4JPkgjBS1w9ip2MQ5l+DMr9BKFGajS6mnTM= =7Kv4 -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
