Re: [tor-talk] Thoughts on proxy setup wrt insecure connections
On Mon, 28 Feb 2011 15:02:40 -0500 thecarp wrote: > After the whole discussion about "gatereloaded" and "badexits" I was > thinking a bit about the discussion and wondering if there is a way to > add a bit more protection to people who are, well, newbs. As one article > pointed out: > > "many who use Tor mistakenly believe it is an end-to-end encryption > tool. As a result, they aren't taking the precautions they need to take > to protect their web activity. " > > This is a similar, but not exactly the same problem. Clearly blocking > all port 80 would be pretty harmful to a lot of use. However, for > protocols like pop3 or imap, the case for allowing them is clearly not > as strong, though, the case for banning them completely or requiring > exit nodes to carry both is... pretty dubious (especially given that > some people will run things on non-standard ports anyway). Connections to the plaintext POP3 and IMAP ports may be secured using the STARTTLS command. > So here is my thought, what do people think of a configuration item in > tor, setup to be "on" by default, which blocks attempts to go to certain > ports at the proxy level, but allows users to turn this "protection" off > if they wish to? Maybe make the list of blocked ports configurable. This enables attacks against users' anonymity -- for example, a web page at <http://evil-site.example.com:80/> could include <http://evil-site.example.com:110/foo.png> as an inline image to distinguish users who have configured their Tor client to allow connections to port 110 from those who have not. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Stricter NEWNYM?
On Fri, 04 Mar 2011 13:21:22 +0100 anonym wrote: > While I've been developing the LiveCDs Incognito and Tails I've got my > fair share of feature requests/bug reports that really are about Tor. > One recurring feature request is to make NEWNYM stricter. > > Users have observed that issuing a NEWNYM doesn't necessarily stop using > the previous circuits, which is obviously the case for truly long lived > connections like IRC and SSH, but I don't think that is what bothers > them; web browsing connections also keep using the old circtuits, at > least with certain web browser and intermediate proxy configurations > that makes them "kinda" long lived (think http keep-alive timeouts). > This confuses users when they get the same exit node after a NEWNYM (for > instance by refreshing check.torproject.org afterwards). This can happen even on a new circuit. Tor does not try to select a different exit node after a NEWNYM has been issued, as that would make users' streams before a NEWNYM more linkable to their streams after the NEWNYM. > Conclusion: NEWNYM doesn't do what the users expect. > > That's no good. Why don't we make NEWNYM ruthlessly kill all circuits, > even the ones handling live connections, long lived or not? I strongly > believe this stricter NEWNYM behaviour is (at least closer to) what the > user expects from it. See the attached patch for a quick and dirty > implementation -- a patch says more than a thousand words, I suppose. > > Of course, to use NEWNYM requires some caution from the user, e.g. > clearing cookies, session id etc. if revisiting the same site, but that > also affects the old NEWNYM approach. Maybe it's even the case that > NEWNYM gives a false sense of a new identity, given all application > level problems that Tor cannot (or at least shouldn't) do anything > about, and thus we should give a shite? Torbutton would also need a 'new identity' button. See <https://trac.torproject.org/projects/tor/ticket/523> for some discussion of what that would involve. If you want to close all web-browsing streams while switching to a 'new identity', the best currently possible options are to toggle Torbutton off, then back on, or to quit Firefox entirely and restart it. (This also requires that you restart Polipo or not be using it.) Perhaps that should be documented better. Alternatively, a user could use Vidalia's 'Network Map' to close all open web-browsing streams. > In any case, are there any new > problems introduced by this more brutal approach that I haven't thought > of which would make it worse than the previous one? This approach would make it impractical for a user to use IRC or SSH on a LiveCD while browsing without linking the IRC/SSH session to his/her/its browsing activities. Please separate the 'kill all streams' command from the NEWNYM command. A 'kill all streams' command would be more useful if it came with an implementation of proposal 171 and ended all streams sent by one application (as determined by the application-separation criteria in that proposal). Unfortunately, that won't become possible until proposal 171 is implemented. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] can't get tor to work :(
On Sun, 6 Mar 2011 14:11:57 +0100 Tolas Anon wrote: > Hi, i downloaded the tor browser bundle today, and tried to get it to run. > > In the default mode, it will hang on "connecting to a relay directory > failed (no route to host)" All of the directory authorities crashed between 2011-03-06T10:00 and 2011-03-06T11:00 UTC. Newly started Tor clients will not work until the directory authorities are running again. > If i put in bridge settings, it will hang on "authenticating to the > tor network". The message Vidalia displays is "Authenticating to Tor", and it means that Vidalia has not yet connected to the control port of your Tor client. Tor clients never authenticate themselves to the Tor network. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Stricter NEWNYM?
On Tue, 8 Mar 2011 20:01:52 -0500 grarpamp wrote: > > Please separate the 'kill all streams' command from the NEWNYM command. > > Yes, I would make that separate too. I would think a NEWNYM should only > cause truly TCP new connections to use a new exit. > > While this is being examined, please have a look at my > NEWNYM buckets proposal of 6 jan 2011... > > == > I've commonly seen exits (or paths) reused within a certain period > of time after issuing a NEWNYM. > > For the users that have such a need, it would be nice if Tor could > optionally keep a historical bucket of configurable entry length > (whether based upon time and/or number of prior nodes/paths used). > Such that any such nodes or paths would not be reused so long as > they remained in the bucket according to its expiry rules. This will harm user anonymity. Circuit path selection must be independent of the circuits and exit nodes which a client has previously used. > And as an aside, to the extent it is not already done, different > ports on the same host should not necessarily be aggregated over > the same circuits. I'd wager that they should not, so as to appear > separate to the observer. Mostly for efficiency. Think of > checking/writing multiple email accounts on the same provider... > via IMAP/POP/HTTP/SMTP... without exposing too much relatedness > due to using the same exit for all at once. See proposal 171 (and its surrounding discussion). Separating streams by destination port will not help separate users' web-browsing activities from their Internet mail connections. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Making TOR exit-node IP address configurable
On Wed, 09 Mar 2011 19:23:15 +0100 "Fabio Pietrosanti (naif)" wrote: > i've been thinking and playing a lot about the various possible risk > mitigation scenarios for TOR exit node maintainer. > > Now i need to be able to pass all web traffic trough a transparent proxy > in order to implement some kind of filters to prevent specific > web-attacks, web-bruteforce, etc, etc > > One very interesting feature that's now missing from TOR and that would > need to implement such kind of proxying is to be able to bind the > TOR-exit traffic to a specific IP address. > That way would be possible to "mark" with iptables the TOR exit traffic > and just mangle this. > > That kind of added feature would also allow a TOR exit node to re-route > the TOR exit traffic go away trough multiple interface in round-robin > for example, for multi-homed TOR routers. > > Sounds to me like a small patch, but frankly speaking i'm not a c-coder. > Some volunteer? Try running "man tor |grep -C5 OutboundBindAddress". But I'm not surprised that someone who wants to perform content censorship on a Tor exit node is too clueless to find that Tor configuration option, or to find out that iptables can apply different rules to the user ID under which Tor is running. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Making TOR exit-node IP address configurable
On Wed, 09 Mar 2011 23:29:16 +0100 "Fabio Pietrosanti (naif)" wrote: > On 3/9/11 11:20 PM, Robert Ransom wrote: > > Try running "man tor |grep -C5 OutboundBindAddress". > > You didn't got the technical need, the need is to redirect only TOR-exit > traffic. > > OutboundBindAddress make *all*, including intra-tor, communications go > trough that IP address: > "Make all outbound connections originate from the IP address specified. > This is only useful when you have multiple network interfaces, and you > want all of Tor’s outgoing connections to use a single one." > > I've been thinking about a settings for TOR-Exit only traffic. > > > > > But I'm not surprised that someone who wants to perform content > > censorship on a Tor exit node is too clueless to find that Tor > > configuration option, or to find out that iptables can apply different > > rules to the user ID under which Tor is running. > Yes but that's more complex, with iptables you can redirect TCP ports, > but from your TOR node not all traffic going for example to port 80 is > http, but a lot of it it's TOR. > > If you redirect it to a transparent proxy you'll break intra-tor > communications, and so you can't just make an easy redirect with iptables. Ah! Now I get it. You want to censor non-HTTP connections on port 80, and probably Google searches for "Robert'); DROP TABLE Students;--" (a quote from one popular web comic) as well. I've opened a relevant enhancement ticket. See <https://trac.torproject.org/projects/tor/ticket/2697>. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Cannot upgrade tor-devel
On Thu, 10 Mar 2011 19:56:26 + Orionjur Tor-admin wrote: > When I run `portupgrade -a` on my server under FreeBSD 8.1-STABLE, I > have the next message of thesystem: > "---> Upgrading 'tor-devel-0.2.2.22.a' to 'tor-devel-0.2.2.22.a_2' > (security/tor-devel) > ---> Building '/usr/ports/security/tor-devel' > ===> Cleaning for tor-devel-0.2.2.22.a_2 > ===> License BSD accepted by the user > ===> Found saved configuration for tor-0.2.1.25 > > ===> tor-devel-0.2.2.22.a_2 conflicts with installed package(s): > libevent-1.4.14b_2 > > They will not build together. > Please remove them first with pkg_delete(1)." > > Why the older version works with it and new don't want to work? And > whether I really need to deleate my "libeent"? The new version will still work with libevent-1.4.14b_2 installed, but the FreeBSD tor-devel port has been changed to link Tor against libevent-2.0.10 now that it has been released, and if you build Tor with both versions of libevent installed, Tor will be compiled with the include files from libevent 2 and linked to libevent 1, which won't work. To install the tor-devel port, * uninstall libevent-1.4.14b_2 temporarily (the portupgrade tools should include something that will create a 'backup' package of a port while uninstalling it), * install the tor-devel port, * then reinstall libevent-1.4.14b_2 (preferably from your package). Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Cannot upgrade tor-devel
On Fri, 11 Mar 2011 03:27:27 + Orionjur Tor-admin wrote: > Very thanks. > After removing libevent-1.4.14b_2 it installs libevent-2.0.10 when > running `portupgrade`. > Does it need to me to downgrade libevent-2.0.10 to libevent-1.4.14b_2 > after upgrading tor-devel? No. Just reinstall the libevent-1.4.14b_2 package you created when you uninstalled libevent-1.4.14b_2 . Both versions of libevent can be installed at the same time (and they must both be installed if you want to use both Tor 0.2.2.x and tmux, for example). Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
On Sun, 20 Mar 2011 17:58:06 -0700 Mike Perry wrote: > So, the question for the bikeshed discussion then is what should the > default state of this collection be? Our thought is to provide > HTTPS-Everywhere users with this dialog on first-run > https://trac.torproject.org/projects/tor/wiki/HTTPSEverywhere/SSLObservatorySubmission#ClientUIandconfigurationVariables > > However, I'm not sure that this is going to work for Tor Browser > Bundle users (which ships with HTTPS Everywhere) who may have the TBB > on readonly USB keys or live cds. They may end up being asked each > time they start. > > Is this a decent compromise? The other option is to not even bother to > ask users who have a working tor installed, on the assumption that > since we can submit certs through tor, it is always safe to do so. We > may end up doing this instead of always asking them. Is this wrong? If > so, why? This ‘phone-home’ behaviour is not safe for users who browse the web over Tor until proposal 171 is implemented in Tor. At best, it would *only* fragment the anonymity set of Tor users. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
On Mon, 21 Mar 2011 09:05:30 -0400 Joseph Lorenzo Hall wrote: > It strikes me that I'd want notice (or the option to get notice) > before submitting rare certs to the database... say a dialog like: > "We're about to submit the certificate for the following site, [x] ok, > [ ] no, do not submit this certificate. ([ ] remember this preference > for this certificate)." My reasoning is that I should usually have a > good idea when I'm expecting a rare/self-signed cert, and if I'm not > expecting it, I'd probably want to submit it. Does that make sense? > best, Joe No. 1. The extension cannot determine whether you have a ‘rare’ certificate without querying the database. 2. If users do not report self-signed certificates that they expect to see, the database cannot be used to detect man-in-the-middle attacks on sites that use self-signed certificates. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
On Mon, 21 Mar 2011 17:09:38 -0700 Mike Perry wrote: > Thus spake Robert Ransom (rransom.8...@gmail.com): > > > On Sun, 20 Mar 2011 17:58:06 -0700 > > Mike Perry wrote: > > > > > However, I'm not sure that this is going to work for Tor Browser > > > Bundle users (which ships with HTTPS Everywhere) who may have the TBB > > > on readonly USB keys or live cds. They may end up being asked each > > > time they start. > > > > > > Is this a decent compromise? The other option is to not even bother to > > > ask users who have a working tor installed, on the assumption that > > > since we can submit certs through tor, it is always safe to do so. We > > > may end up doing this instead of always asking them. Is this wrong? If > > > so, why? > > > > This ???phone-home??? behaviour is not safe for users who browse the web > > over Tor until proposal 171 is implemented in Tor. At best, it would > > *only* fragment the anonymity set of Tor users. > > The problem with 171 (SOCKS username/password to split streams across > different circuits, for those playing at home) is that Firefox also > lacks username and password fields in the proxy APIs for SOCKS, so we > cannot do this for anyone except for TBB users. Could you include a native-code SOCKS client library in the extension? > But, if the EFF runs an exit enclave at observatory.eff.org, shouldn't > this solve the same-circuit correlation problem? Tor should prefer > using that exit enclave in all cases when it is up in this case. This won't work if an exit node lies about the IP address of ‘observatory.eff.org’ (and it won't work reliably in any case). Using an EFF-run hidden service would fix that problem if we can make hidden services work reliably again. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
On Tue, 22 Mar 2011 21:19:46 -0700 Mike Perry wrote: > > > But, if the EFF runs an exit enclave at observatory.eff.org, shouldn't > > > this solve the same-circuit correlation problem? Tor should prefer > > > using that exit enclave in all cases when it is up in this case. > > > > This won't work if an exit node lies about the IP address of > > ???observatory.eff.org??? (and it won't work reliably in any case). Using > > an EFF-run hidden service would fix that problem if we can make hidden > > services work reliably again. > > Yeah, we need to start issuing requests for the IP, because the DNS > request itself is an anonymity set fragmentation issue (since it won't > go to the enclave, but will be mixed with other tor traffic). The EFF > says using the IP for submission should be doable: the IP address they > plan to use should be stable in the medium term. Will you be able to get a certificate valid for that IP address (rather than hostname)? Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] GSOC Ideas.
On Fri, 1 Apr 2011 17:12:20 -0700
Ian Foster wrote:
> I've created a simple python parser for Tor that will generate a csv
> file from Tor's cached-descriptors and cached-consensus files.
> It does not get all the data it should but it is only a first revision.
> The purpose of this was to more familiarize myself with Tor for the
> Google Summer of Code, Hope it is useful!
> Get it here: https://github.com/mrlanrat/TorExport
>
> grarpamp, I hope this helps you a little, If I can I will expand the
> data that this script will collect.
>
> Moritz Bartl, your script was very useful, I used it s a base, but
> modified it a bit so that it would run on python 3.
No shit. Your substantive contribution to TorExport consists of less
than 10 new lines near the end -- diff attached. (I normalized the
leading whitespace in both files with ‘expand -t 4’ first.)
Robert Ransom
--- moba-tormap.py 2011-04-01 20:00:56.0 -0700
+++ mrlanrat-torexport.py 2011-04-01 20:01:15.0 -0700
@@ -1,41 +1,46 @@
#!/usr/bin/env python
# encoding: utf-8
-
-'''
- quick and dirty hack Moritz Bartl mor...@torservers.net
- 13.12.2010
-
- let me know and send me your changes if you improve anything
-
- requires:
- - pygeoip, http://code.google.com/p/pygeoip/
- - geoIP city database, eg. http://www.maxmind.com/app/geolitecity
-
- This program is free software: you can redistribute it and/or modify
- it under the terms of the GNU Lesser General Public License (LGPL)
- as published by the Free Software Foundation, either version 3 of the
- License, or any later version.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU Lesser General Public License for more details.
-
- http://www.gnu.org/licenses/
'''
+Script to parse torfiles for nodes and export csv
+4/1/2010
+Ian Foster
-FAST = 100
+requires python 3
+
+Built using code from:
+https://github.com/moba/tormap/blob/master/tormap.py
+
+TorExport is free software: you can redistribute it and/or modify it under the terms
+of the GNU General Public License as published by the Free Software Foundation,
+either version 3 of the License, or (at your option) any later version.
+
+TorExport is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
+PARTICULAR PURPOSE. See the GNU General Public License for more details.
+
+http://www.gnu.org/licenses/.
+'''
-import base64, shelve, pygeoip, cgi, re
-from operator import attrgetter, itemgetter
-from string import Template
+import base64
+import cgi
+import csv
+import sys
+
+try:
+sys.argv[1]
+except IndexError:
+print('Creates a CSV of all online nodes')
+print('Please Pass folder containing cached-descriptors and cached-consensus files')
+print('usage: torexport.py /path/to/tor/data')
+exit()
+FAST = 100
cachedRelays = dict()
currentRouter = dict()
# parse cached-descriptors to extract uptime and announced bandwidth
-with open('cached-descriptors') as f:
-for line in f:
+with open(sys.argv[1]+ '/cached-descriptors') as f:
+for line in f:
line = line.strip()
if line.startswith('router '):
[nil,name,ip,orport,socksport,dirport] = line.split()
@@ -48,13 +53,13 @@
currentRouter['version']=line[9:]
if line.startswith('opt fingerprint'):
fingerprint=line[16:]
-currentRouter['fingerprint'] = fingerprint.replace(' ','').lower()
+currentRouter['fingerprint'] = str(fingerprint.replace(' ','').lower())
if line.startswith('uptime '):
currentRouter['uptime']=line[7:]
if line.startswith('bandwidth '):
currentRouter['bandwidth'] = line[10:]
try:
-currentRouter['bw-observed'] = int(line.split()[3])
+currentRouter['bw-observed'] = int(line.split()[3])
except:
pass
bandwidth = line[10:]
@@ -65,8 +70,6 @@
cachedRelays[fingerprint] = currentRouter
currentRouter = dict()
-# parse cached-consensus for flags and correlate to descriptors
-
badRelays = dict() # Bad in flags, eg. BadExit, BadDirectory
exitFastRelays = dict() # Exit flag, >= FAST
exitRelays = dict() # Exit flag, slower than FAST
@@ -74,57 +77,56 @@
stableRelays = dict() # Stable flag, but not Exit
otherRelays = dict() # non Stable, non Exit
-count = 0
-with open('cached-consensus') as f:
-for line in f:
Re: [tor-talk] Google disable web-access to gmail for Tor-users?
On Sat, 02 Apr 2011 19:53:51 + James Brown wrote: > On 02.04.2011 19:29, James Brown wrote: > > On 02.04.2011 17:11, Matthew wrote: > >> > > > >> > >> I am wondering if you are using Torbutton and, if so, whether you are > >> using 1.3.2pre-alpha3? > >> > >> With extensions.torbutton.xfer_google_cookies as true and with the xpi > >> downloaded (see below) I no longer received the error you have quoted. > >> > >> --- > >> > >> Can you please try the .xpi from this bug: > >> https://trac.torproject.org/projects/tor/ticket/2377#comment:3 and let > >> me know if it behaves ok for Google logins now? It may need a few > >> tries, iirc, this bug is random. > >> torbutton-1.3.2pre-alpha3.xpi > >> Be sure to go back in toabout:config and reset > >> extensions.torbutton.xfer_google_cookies back to*true* before running > >> your tests. > >> > >> > >> > >> > >> > >> ___ > >> tor-talk mailing list > >> tor-talk@lists.torproject.org > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > > > > Hi, Matthew, > > > > Very thanks, I'll try it in the nearest time. > > But I cannot find the file of digital sign of this file (such as > > torbutton-1.3.2pre-alpha3.xpi.asc): > > https://trac.torproject.org/projects/tor/attachment/ticket/2377/torbutton-1.3.2pre-alpha3.xpi > > Where can I get it? > > Strange, bad signature. > It seems to me, that there are different versions of the TB-1.3.2. > But what of them do I need to use? From here > https://www.torproject.org/dist/torbutton/ or from here > https://trac.torproject.org/projects/tor/attachment/ticket/2377/torbutton-1.3.2pre-alpha3.xpi > ? > As I can see the latest version is from February 13 and the first - from > March 21. > And if I need to use the latest version when I can get the file of its > digital sign for it's verifying? Use the released version of Torbutton 1.3.2-alpha from <https://www.torproject.org/dist/torbutton/>. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Torbutton problem
On Wed, 20 Apr 2011 17:41:12 -0400 and...@torproject.org wrote: > On Wed, Apr 20, 2011 at 05:51:54PM -0300, javierba...@gmail.com wrote 0.7K > bytes in 16 lines about: > : The problem is that there might be a situation in which you are using > : tor network without knowing. It's ok for the plugin to modify settings > > Are you using the same firefox profile with both browsers? Yes, he is. Both versions of Firefox default to using the same profile. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] no country flags in Vidalia 2.10
On Thu, 28 Apr 2011 02:00:32 -0300 Javier Bassi wrote: > On Wed, Apr 27, 2011 at 11:34 PM, wrote: > > Did you install tor-geoipdb package? > > I have just added torproject urls to sources.list and installed > tor-geoipdb from deb.torproject.org (lucid). It still doesn't work > when I open vidalia. I think the problem could be that I didn't > install vidalia from the package manager. I downloaded a tar.bz file, > extracted it and I'm using it from my /home. Was the .tar.bz2 file a Tor Browser Bundle? > Anyway I wanted the flags some days ago to see if there was any Tor > Exits from Argentina with the Tor Exit message on port 80 and email > address to contact them and ask them if they had any trouble with ISPs > here. About a month ago I started running an exit node from home and > wanted to know if there was any history here. So I check with > TorStatus and it seems I'm the only one using "This is a Tor Exit > Router" message on :80. You can also check for a contact address in the relay descriptor. TorStatus web sites show a relay's contact address in the relay information page that appears when you click on a relay's name, and they can show relays' contact information in a column on a relay list as well. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor 0.2.3.1-alpha w/o traffic
On Sun, 08 May 2011 21:53:38 +0200 Olaf Selke wrote: > after two days all blutmagie routers appear to have been dropped from > the consensus. Does v0.2.3.1 trigger an old "extra-info descriptor > exceeding 50k" bug again? Today the my stats directories grew beyond 50k. 0.2.3.1-alpha will remove items from its extra-info descriptor or drop its e-i descriptor entirely (and still publish a relay descriptor) if the e-i descriptor would otherwise exceed the 50-kiB limit. That's not the problem this time. (But we don't know what the problem is yet.) Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Source code modifying for testing
On Wed, 11 May 2011 10:11:07 +0200 NGUYEN Quoc Viet wrote: > I'm now researching an attack against Tor. > > *Resume of Attack*: We control exit node and entry node. Upon receiving a > RELAY BEGIN cell,the exit node will forger a malicious webpage to client. > The webpage contains some empty gif files. The entry node will be able to > detect a distinctive pattern of the connection to that malicious webpage, > basing on number of relay cells backward and forward. If you can control both the entry and exit nodes, you don't even need to perform an active attack -- a purely passive timing attack will identify the client. That's why each Tor client selects a few relays to use as ‘entry guards’ -- see <https://www.torproject.org/docs/faq#EntryGuards> and <http://freehaven.net/anonbib/#hs-attack06>. > For implementation, it's needed to modify a piece of Tor source code at the > exit node, to forger a malicious webpage to client. Notice that this is not > modifying webpage response from the server, but forger attacker's webpage to > the client. Could some one please give a hint about where I need to modify. No. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Cannot upgrade tor-devel under FreeBSD
On Wed, 11 May 2011 13:57:03 + James Brown wrote: > > mv -f .deps/test-child.Tpo .deps/test-child.Po > > cc -O2 -pipe -fno-strict-aliasing -Wall -fno-strict-aliasing -ltcmalloc > > -L/usr/local/lib/event2 -rpath=/usr/local/lib -z relro -z now -o test-child > > test-child.o -pthread > > /usr/bin/ld: cannot find -ltcmalloc > > *** Error code 1 > What is that and how I can fix it? You seem to have turned on the TCMALLOC configuration option in the FreeBSD tor-devel port, and for some reason the ports system didn't install the ‘google-perftools’ package which that option requires. Turn off the TCMALLOC option and try again. (The easiest way to change the port's options is to move your current /var/db/ports/tor-devel/options file to some other directory and try installing the port again.) Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How to select the path using the weights?
On Sun, 15 May 2011 22:17:50 -0400 katmagic wrote: > On Thu, 2011-05-12 at 21:42 -0400, Lu Yu wrote: > > I know how these weights (Wgg, Wgm .) are calculated. But then what? > > > > How to choose the path using the weights? My understanding is to > > calculate the weighted sum of the bandwidth of each possible circuits > > (Isn't the computation too much?). And then choose the path with the > > maximum bandwidth (Then every one would choose the same path)? Or using > > the bandwidth to build some probability distribution? > > > > I am totally confused. > The bandwidths are used to build a probability distribution. See path-spec.txt in https://gitweb.torproject.org/torspec.git . Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] 504 Proxy loop detected by Polipo
On Tue, 17 May 2011 13:51:42 -0500 David Carlson wrote: > I am using Tor 0.2.2.25-alpha with Vidalia Bundle 0.2.12. I received > the following error message when trying to access > www.stcharlessingers.com. I was able to access the site when I used > TorButton to bypass Tor with my Firefox 4.0.1 browser > > > The following error occurred while trying to access > http://pdfforge.mybrowserbar.com/cgi/errors.cgi?q=http://pdfforge.mybrowserbar.com/cgi/errors.cgi%3fq%3dhttp://pdfforge.mybrowserbar.com/cgi/errors.cgi%253fq%253dhttp://pdfforge.mybrowserbar.com/cgi/errors.cgi%25253fq%25253dhttp://www.stcharlessingers.com/%252526type%25253ddns%252526ISN%25253d40AD95D2A57C4BEFA9F88CA3549305CA%252526ccv%25253d133%252526cnid%25253d971163%252526cco%25253dUS%252526ct%25253d3%252526sc%25253d504%2526type%253ddns%2526ISN%253d40AD95D2A57C4BEFA9F88CA3549305CA%2526ccv%253d133%2526cnid%253d971163%2526cco%253dUS%2526ct%253d3%2526sc%253d502%26type%3ddns%26ISN%3d40AD95D2A57C4BEFA9F88CA3549305CA%26ccv%3d133%26cnid%3d971163%26cco%3dUS%26ct%3d3%26sc%3d504&type=dns&ISN=40AD95D2A57C4BEFA9F88CA3549305CA&ccv=133&cnid=971163&cco=US&ct=3&sc=504: > > Is this the correct place to report this problem? This looks to me like a problem caused by Polipo's configuration in the Tor bundle you are using -- specifically, I suspect that Polipo dropped the Referer header on at least one request, and possibly all of the requests in this loop. The proper place to report this bug would be as a Trac ticket on <https://trac.torproject.org/> in the ‘Tor bundles/installation’ component, but we plan to remove Polipo from as many of our bundles as possible as soon as possible, so we might just ignore a Trac ticket for this issue. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor 0.2.2.26-beta and 0.2.2.27-beta are out
On Thu, 19 May 2011 11:51:34 +0200 Olaf Selke wrote: > On 19.05.2011 08:54, Roger Dingledine wrote: > > > > o Major features: > > - Set SO_REUSEADDR on all sockets, not just listeners. This should > > help busy exit nodes avoid running out of useable ports just > > because all the ports have been used in the near past. Resolves > > issue 2850. > > > Roger, you made my day! > > Does this also help to reduce cpu load and will this feature be > introduced in the 0.2.3.x tree, too? This change has already been merged to the 0.2.3.x tree (the ‘master’ branch in our Git repo). I have no information on whether this change will reduce CPU load on large relays and exits, but I would not expect it to reduce CPU load. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] password...
On Tue, 31 May 2011 09:46:07 +0330 kamyar fils wrote: > Does anybody know what kind of Encryption TOR uses for encrypting the data? See tor-spec.txt in <https://gitweb.torproject.org/torspec.git/tree>. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 04 Jun 2011 12:37:14 +0200 tagnaq wrote: > >> Someone running this (SSLObservatorySubmission) in a non-public network > >> (i.e. an internal corporate network) with Internet access will probably > >> disclose internal hostnames including IP addresses, if that is the case > >> I would identify this as an issue. What do you think about it? > > > > We're going to try really hard to avoid this by default. See the first > > two options in the client UI section under "advanced options": > > https://trac.torproject.org/projects/tor/wiki/HTTPSEverywhere/SSLObservatorySubmission#ClientUIandconfigurationVariables > > These two options will prevent disclosure in many scenarios but I don't > think it will avoid the problem in a common scenario (internal hosts use > a valid FQDN and a valid cert). > > IP address and hostname (and cert.) of intranet-server1.example.com > using a valid certificate *.example.com will be published even if the > first two options in the "advanced options" are enabled. Is that correct? > In such scenarios I'm not worried about the certificate being submitted > but the hostname and IP address (domain and server_ip arguments). > > > I'm not sure if I understand "private DNS domains" correct. > "[x] Do not check/submit certificates for private DNS domains" > > Are private DNS domains just non-existing TLDs? Something like > "foobar.localnet"? My understanding was that EFF would query DNS for a hostname, and if the hostname does not exist, assume that it's private. (This should scare you even more.) Robert Ransom -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJN6g6FAAoJENmcrTGPJVyVilYH/iVcZd4GbSA19BIYUWCWJwah tImYDiS+5v1ai2fXgPLabvSrNHdxqrfgoUnXOaaHMiZiSqJx8ekVOe5ah5rfd67E d+ONg5NWX9qyB+wpEtCJ0hHooMuBt9jcUlrVZAYNkyRy1BoyjB4PkqkXBh8S3mF1 xEtC/SDAoDU3g6hWC3q5OW3USykETKH2lI0WF0QFt4lY9GnUz8cn+l+HV9uCU/0C sMo9Q0BhhoSwyzr10VBLyuSm2HG1AzbJfS2eT2UPtitBbxNPjaCni/abvRlfzRxn CcOjl79oQ+xaM7qJrQt/tmMnD0t2LbkRdEbSM8vU5XAe4nPB7HmZ5+lV+VM3/BQ= =cCCI -END PGP SIGNATURE- ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
On Sat, 4 Jun 2011 12:09:52 -0700 Mike Perry wrote: > Thus spake Robert Ransom (rransom.8...@gmail.com): > > My understanding was that EFF would query DNS for a hostname, and if > > the hostname does not exist, assume that it's private. (This should > > scare you even more.) > > EFF only needs to do this query if the browser could not (because it > was using an HTTP proxy without a SOCKS proxy). Does this scare you > less or more? I'm getting confused by the reactions in this thread. If EFF needs to perform a DNS query on each hostname it receives a certificate for, EFF will leak information to an attacker watching its servers. If EFF tries to not log hostnames which do not exist, EFF will leak a user's request time *every time* that it receives a certificate associated with a non-existent hostname. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
On Sat, 4 Jun 2011 12:56:15 -0700 Mike Perry wrote: > Thus spake Robert Ransom (rransom.8...@gmail.com): > > > On Sat, 4 Jun 2011 12:09:52 -0700 > > Mike Perry wrote: > > > > > Thus spake Robert Ransom (rransom.8...@gmail.com): > > > > > > My understanding was that EFF would query DNS for a hostname, and if > > > > the hostname does not exist, assume that it's private. (This should > > > > scare you even more.) > > > > > > EFF only needs to do this query if the browser could not (because it > > > was using an HTTP proxy without a SOCKS proxy). Does this scare you > > > less or more? I'm getting confused by the reactions in this thread. > > > > If EFF needs to perform a DNS query on each hostname it receives a > > certificate for, EFF will leak information to an attacker watching its > > servers. If EFF tries to not log hostnames which do not exist, EFF > > will leak a user's request time *every time* that it receives a > > certificate associated with a non-existent hostname. > > I think you missed the first half of my email where I explicitly said > EFF shouldn't need to do this under normal circumstances. It only > needs to do this when the browser fails to do so itself. Do you expect > this to be common? Firefox cannot resolve hostnames to IP addresses when it is using *any* proxy. Anyone who uses an SSH tunnel as a SOCKS to connect to an intranet will risk this leakage, and SSH tunnels can be made fairly easy to use. I have no information on how widely used that configuration is. > The observatory itself could also be running a tor client for these > resolutions, just in case they do end up being common. That would be a Good Thing, just to decrease the incentive for attackers to monitor EFF's Internet connection. > P.S. When the browser does attempt to do these resolutions, should > they be done via Tor or via whatever local resolver/proxy was used to > access the domain? Doing it via Tor exposes potentially private names > to exits, but doing it locally will fail to detect attacks where the > MITM is able to operate on the user's own infrastructure (because they > can just make sure that the domains they MITM resolve to RFC1918). Either way, the attacker wins -- if you resolve hostnames over Tor, the attacker can use a homoglyph or near-homoglyph of a target hostname for its attack, and simply not allow DNS servers accessible outside its victim network to see the attack hostname. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] how many users?
On Sun, 5 Jun 2011 13:13:29 +0200 Jerzy Łogiewa wrote: > so how many users is estimated tor has around the world? https://metrics.torproject.org/users.html > is a stats site made? https://metrics.torproject.org/ Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] 4 hops in tor?
On Mon, 6 Jun 2011 16:16:57 -0400 (EDT) whereis...@lavabit.com wrote: > was looking at Vidalia's Tor Network Map, and rather than the usual > 3 link chain, I saw a 4 link chain. > > Did they change something, is this an anomaly? What's going on with > this? I thought Tor was hard-coded with a 3 link chain? This can happen when Tor ‘cannibalizes’ a normal three-hop circuit (most often, it has circuits pre-built to exit nodes that allow exiting to ports you have used recently, and you try to connect to an IP address and port that none of the pre-built circuits' exit nodes allow access to), or when Tor connects to an ‘exit enclave’ (a Tor relay running on a server you are trying to connect to). Tor also often builds four-hop circuits while connecting to hidden services. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] unbound, ttdnsd and DNSPort config
On Thu, 09 Jun 2011 02:00:23 +0200 intrigeri wrote: > Hi, > > Anders Sundman wrote (06 Jun 2011 14:24:12 GMT) : > > Used individually, the addr directives work fine and resolve using > > their respective mechanism. Used together, it looks like ttdnsd > > never gets a chance after tor has failed (e.g. when resolving a SRV > > or MX record). > > > Any ideas? > > I've just had a look, by attempting to implement the same in Tails > (i.e. query first the Tor resolver, and fallback to ttdnsd in case the > former is not able to answer the query) as we planned to do for quite > some time. I've seen the same results as you have, using the DNS > frontend caching proxy Tails already ships (pdnsd) instead of unbound. > > A few dig commands learned me that the Tor resolver sends an empty > reply (status: NOERROR, QUERY: 1, ANSWER: 0) rather than an error when > it does not support the type of the query (e.g. MX). The obvious > consequence of it is: the caching frontend DNS proxy (be it unbound, > pdnsd or whatever) has thus no way to know it should fallback to > ttdnsd in such a case, and it actually never does so, which confirms > what you've observed in the first place. > > => In the current state of the Tor DNS resolver, we're forced to use > ttdnsd by default, and only use the Tor resolver for .onion/.exit... > unless I missed something. > > So I'm curious what the rationale for the "empty reply" behavior is. > Any ideas? This looks like a bug. Please open a Trac ticket for it. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] rend-spec.txt HS stuff
On Tue, 21 Jun 2011 06:30:50 -0400 grarpamp wrote: > https://gitweb.torproject.org/torspec.git/blob/HEAD:/rend-spec.txt > > I think there are some errors in this document... > > === item 1 === > > line 251: > "time-period" changes periodically as a function of time and > "permanent-id". This is correct. > === item 2 === > > The paragraph around line 262 gets weird in places... > > - The document fails to declare Bob's 'permanent identifier' > that was used for the example. ie: abcdefghijklmnop.onion That is not the permanent identifier used in the example in that paragraph. But I see no reason to specify a whole permanent identifier for that example. > - line 262, I show: > > (13753 * 86400 - 1188241957) * 256 / 86400 = 51.0903703703 > (1188241957 + 51 * 86400 / 256) / 86400 = 13752.9996469907 > > So the '143' on that line seems bogus. Am I missing something? Where > did it come from? The calculations in that paragraph are correct. “/” is used to indicate integer division. > === item 3 === > > Should at least one of the eight dir-source's be running the stable > train (0.2.1.30), to be able to respond to v0 descriptor requests > (/tor/rendezvous/)? At least for testing until client-versions > forces said clients (and testers) and their v0 queries out. tor26 is configured as a v0 hidden-service authority. > === item 4 === > > Remove blank line at 252 and rewrap :) No. That blank line was intentional. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Access blocked by Baracuda Content filter
On Tue, 21 Jun 2011 14:28:45 +0200 andr...@fastmail.fm wrote: > At a free wifi hotspot I encountered something called Baracuda Content > filter which blocks me from accessing my webmail and a bunch of websites > like youtube and godaddy. > > Is there any way around this filter nonsense? Use Tor. If it blocks Tor, use Tor bridges. If it blocks Tor bridges, we would like to probe that filter. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How evil is TLS cert collection?
On Tue, 21 Jun 2011 11:20:07 -0700 Mike Perry wrote: > Thus spake tagnaq (tag...@gmail.com): > > > Well, after all I guess we can acknowledge that there are scenarios > > where information disclosures will happen. > > Ok, I probably should recap these scenarios here. I realized I forgot > to reply to you. > > To make sure we understand one another (and everyone else understands > us): the remaining information disclosure scenarios we're talking > about are limited to two: > > 1. User has a private network whose DNS is set to resolve private > names to public IP addresses which normally would not have been > reachable in the IPv4 scan, and whose TLS certs are also signed by a > public trusted root CA. This is a weird setup, but it's a big world. > I guess it could exist somewhere. > > 2. User has private network on RFC 1918 space, yet uses an HTTP proxy > to access it (which means we can't tell that it is private IP space). > Said user is also using TLS certs signed by a public trusted root CA. > This config is less weird, and detectable by us. It makes me think we > should handle this user specially somehow? This could occur with a SOCKS proxy, too (such as that run by ‘ssh -D’), since there is no standard way to ask a SOCKS proxy to resolve a hostname to an IP address. (Tor allows this using a non-standard extension to SOCKS.) > Your point is that in these two cases, with the default protection > mechanisms defined in > https://trac.torproject.org/projects/tor/wiki/doc/HTTPSEverywhere/SSLObservatorySubmission > these two users could still end up sending their public-yet-private > certs to EFF. Yes. > Should we somehow warn the HTTP proxy user about the possibility of > private TLS certs being submitted if they try to opt-in to the > feature? Maybe. I doubt that users with configuration 2 will opt in to SSL certificate submission without reading all of the documentation they can find, and configuration 1 seems more likely to occur during an attack than in a deployed intranet. > > To give users the possibility to contribute while preventing leaks for > > specific domains they are concerned it would be great if the submission > > addon would have a blacklist feature where one could say > > never submit anything for *.example.com. > > This seems to be a reasonable option to me. I've added this to our > spec page above. > > But is there a better option? Do you think it might be likely that > either of these users will disable OCSP for these certs, or otherwise > indicate anything about these public-yet-private certs that we can > detect in their config? There is no better option than a user-specified domain blacklist. Any attempt to automatically detect these private certificates and avoid submitting them will defeat the most important purpose of the distributed SSL observatory project: detecting SSL MITM attacks. Robert Ransom signature.asc Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Reason Firefox version in TBB is so far behind?
On 2011-08-05, Joe Btfsplk wrote: > On 8/2/2011 7:41 PM, Joe Btfsplk wrote: >> On 8/2/2011 7:10 PM, Andrew Lewman wrote: >>> On Tuesday, August 02, 2011 19:55:48 Joe Btfsplk wrote: >>>> Are there specific reasons for not using latest (or late-er) Firefox >>>> versions in Tor Browser Bundle? Is it primarily because the latest >>>> version doesn't always work w/ Tor& fixes must be developed for Tor to >>>> deal w/ that? >>> It's the latest udpated Firefox 3.6 branch. FF4 branch has been >>> killed and >>> replaced with 5. We have FF5 testing bundles. See >>> https://blog.torproject.org/blog/new-tor-browser-bundles-3. >> Thanks. I realize the latest stable TBB has FF 3.6. Is the reason >> for delay in updating to latest FF version always for testing - to see >> if Tor works properly? >> Firefox versions used in stable TBB have always run behind the latest >> FF release - sometimes several versions. This may well be unavoidable >> for TBB developers. My original question - how does this affect the >> security of TBB users? >> ___ >> > No comments on security implications of using a Firefox version in TBB, > that isn't up to date with security fixes (sometimes not even close)? > I'm grateful for the work done to create TBB, but the mantra of security > experts has always been, "ALWAYS keep your browser / OS updated w/ > security patches." That is why we ship the latest version of Firefox on the 3.6 branch in our stable TBBs. Mozilla is still releasing security updates on the Firefox 3.6 branch. As you can see from https://blog.torproject.org/blog/new-tor-browser-bundles-3 , Firefox 3.6.19 and Firefox 5.0.1 were released on the same day. That is because Firefox 3.6.19 and Firefox 5.0.1 are security-fix releases that fix the same security bug. (Firefox 4.0, 4.0.1, and 5.0 are no longer safe to use, even though their version numbers are greater than 3.6.19.) > As said, it may be unavoidable (currently) for TBB developers to > integrate new FF versions quickly, but surely I'm not the 1st to wonder > about security issues of using old browser versions. > The testing bundles Andrew mentioned are fine for, well... testing, but > not for general users. It's a long way & many fixes, from Firefox 3.6 > to 5.0 / 5.0.1. There are some bugfixes in Firefox 5.0.1 that aren't in Firefox 3.6.19 -- notably, Mozilla finally applied our patch to fix Firefox's hard-coded timeout when using a SOCKS proxy, so Firefox 5.0 and 5.0.1 no longer require an HTTP proxy such as Polipo between the browser and Tor -- but the main difference between Firefox 3.6.x and Firefox 5.0.x is that Firefox 5.0.x contains many new features. And those features introduced a crapload of bugs which have security implications for Tor users -- mainly WebGL security bugs, but there were a few nasty surprises in the new JavaScript interpreter (see https://trac.torproject.org/projects/tor/ticket/2819 , https://trac.torproject.org/projects/tor/ticket/2873 , and https://trac.torproject.org/projects/tor/ticket/2874 ). There were plenty of other changes to audit as well; look through Tor's bug tracker if you're interested. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Problem with Linux Version
On 2011-08-07, kamyar fils wrote: > Hi all, > just DLed "Linux Bundle" version of TOR ,when running bundle in my Linux , > getting "Unexpectedly error" and the following is generated log: > Aug 07 14:48:12.863 [Notice] Tor v0.2.2.30-rc (git-085c9754ccae6cae). This > is experimental software. Do not rely on it for strong anonymity. (Running > on Linux i686) > Aug 07 14:48:12.943 [Notice] Initialized libevent version 2.0.12-stable > using method epoll. Good. > Aug 07 14:48:12.943 [Notice] Opening Socks listener on 127.0.0.1:9050 > Aug 07 14:48:12.944 [Notice] Opening Control listener on 127.0.0.1:9051 > Aug 07 14:48:12.944 [Warning] ./Data/Tor is not owned by this user (root, 0) > but by (2011). Perhaps you are running Tor as the wrong user? Do not extract or run Tor Browser Bundle as root. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] I've yet to understand attacks on hidden services
On 2011-08-20, hi...@safe-mail.net wrote: > I've read a lot about it, but I'm hoping for a simplified explanation for a > simplified guy. ;) > > If my hidden service server has a clock that is 5 minutes wrong, how can > anyone use that to locate me? They can only use that to locate your server if they can either connect to it directly (not through Tor) or accept a non-Torified connection from it, and determine what your server thinks is the current time based on information it receives on that connection. The obvious ways that your server could leak its current time include running a web server and sending e-mail messages. The less obvious ways include opening an outbound TLS connection and running a cron job with externally observable effects (e.g. an automatic update downloader). Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] observation: Browser bundle & secure files deletion
On 2011-10-04, Joe Btfsplk wrote: > I've thought about TBB & it insecurely deleting files such as cache when > closing TBB Firefox. I assume this is what happens - I've investigated > - a BIT - & seems that's what it does. If you have evidence that TBB-Firefox stores sensitive information to disk without a user asking it to, please file a bug report. One of the main design goals of Torbutton was to prevent Firefox from ever writing sensitive information to disk (unless a user has specifically asked it to, e.g. by changing Torbutton's configuration or adding a bookmark to Firefox). See section 1.2 of https://www.torproject.org/torbutton/design/ . > *Is this correct?* I can't tell because you didn't tell us what files you think TBB-Firefox writes which contain sensitive information. > If true, there's no opportunity to securely wipe the files, rather than > them being insecurely deleted - unless I'm mistaken. AFAIK, Tor has no > secure wiping capability built in. Neither Tor nor TBB attempts to securely erase files, because most filesystems in use on most operating systems (and many modern storage devices) make securely erasing files infeasible. > Don't remember reading in documentation, either that users should be > aware of this & take appropriate action, or that TBB already handles it > securely. Also, no mention of a list of files TBB deletes on shut down, > that users might consider the possibility of data being recoverable. TBB should never write sensitive information to disk. TBB must assume that it is safe to create and delete temporary files which do not contain sensitive information within the TBB directory. > If true, the only way to wipe any sensitive info (Ex.: so a repressive > gov't can't recover info from HDD), would be use a prgm to wipe free > space on the partition containing TBB. If it is installed on a flash > drive, that could be wiped, but principal is still the same. Programs that wipe free space are rarely able to wipe enough information to be worthwhile. Flash drives cannot be erased reliably at all. > Since many users install most everything to C:\ - esp. in Windows (in > TBB case, unzip to a folder), then wiping free space process on the OS > partition - which MAY be the whole HDD for some users, ALWAYS involves > some risk to file(s) corruption. I've never had a disaster wiping free > space, but forums like Eraser, CCleaner & others are full of posts about > the process (apparently) severely damaging the OS. > > If my assumptions are correct, > 1) Have TBB developers considered the issue of some deleted info from > sessions, being recoverable? We have. That's why we try hard to not write sensitive information to disk. > 2) Other than wiping free space, (which takes time) are there other > suggestions for avg users to realistically deal w/ this? It doesn't > affect me so much, but in repressive countries, it may warrant > consideration. We assume that erasing data written to disk is impossible, because it is infeasible on most filesystems and operating systems and many storage devices. > I'd think for users wanting to securely wipe free space, it'd be best to > use TBB on flash drive or a small partition on HDD. It's possible ? w/ > a proper list of files, the files in question MIGHT be securely deleted > BEFORE closing TBB, but many wiping prgms would have problems wiping > active files. It probably can be done w/ enough knowledge & right > tools, but most users aren't aware of steps needed, and would not > regularly go to that trouble (or forget). We assume that erasing data written to disk is impossible, because it is infeasible on most filesystems and operating systems and many storage devices. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Browser Bundle: PGP encryption built-in?
On 2011-10-10, Fabio Pietrosanti (naif) wrote: > is anyone evaluating whenever to include PGP encryption support into the > default Tor Browser Bundle as a Firefox extension? No. > I looked at the implementation and: > > * FireGPG it's discontinued http://getfiregpg.org/s/install > It also seems it was using a "bad design" practice for the IPC > communications between various modules. > > * NPAPI based GPG is just released (by old FirePGP contributor) > https://github.com/kylehuff/webpg-npapi > > Having a support for GPG encryption into a generic browser, with PGP > operations usable from Javascript/XUL, could open a lot of improvements > and opportunities to secure Webmail and other web applications. No. See https://tails.boum.org/bugs/FireGPG_may_be_unsafe/ , but beware -- I'm sure katmagic and I missed a few dozen attacks. > At http://globaleaks.org we'll most probably need such kind of support > into the browser and we're wondering if this could accomodate a standard > "requirement" of the Tor Project for the Tor Browser Bundle. No. > It would be also possible to easily make very simple "XUL" interfaces to > handle basic PGP based file encryption operations, de-facto bundling a > GPG client (with a Browser UI) into the TorBrowserBundle. This sounds reasonable, except for the parts about the XUL interface and the browser-based UI. It also sounds rather like GPG4Win, except for those parts. > What do you think about it? No. > We're going to make some experiment in trying to build > https://gitweb.torproject.org/torbrowser.git + GPG + > https://github.com/kylehuff/webpg-npapi . Ugh. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Fwd: Tor Browser Bundle: PGP encryption built-in?
On 2011-10-10, Fabio Pietrosanti (naif) wrote: > Hi Kyle and Aaron, > > let me answer to you by making in Cc the tor-talk mailing lists where > there is an on-going discussion about it. > > It has been suggested that FireGPG is unsafe > (https://tails.boum.org/bugs/FireGPG_may_be_unsafe/), your approach by > design sounds very nice. You seem to have missed the point of that page -- the problem with FireGPG is what it allows, not how it was implemented. > I am wondering whether it would be possible to add another simple > security mechanism so that the user is "alerted" anytime a GPG related > operation is going to be executed. > > Something like: > "The website blahblah.com would like to use PGP to [encrypt|sign|cipher] > web-data, do you want to allow it?" > > Ransom, what do you think about Kyle and Aaron approach? (Eventually > including a "pre-warning" for any sensitive operation to the end-user)? A warning before JavaScript enumerates your keyring isn't sufficient. Users must, at a minimum, be able to block all further attempts by a page or website to use GPG features. And even that won't help most users -- a request-for-permission dialog can only protect users who read messages before clicking 'Allow', and who understand that allowing a website to use a GPG plugin is dangerous. > By embedding a GPG support into TorBrowserbundle, the Tor Project would > eventually provide a "Trusted PGP Key lookup server" on a Tor Hidden > Service that forward the PGP key lookup to public internet key servers. No we wouldn't. > I mean, today everything goes over HTTP, but our browsers are capable of > doing end-to-end encryption only by using Javascript. > Why not try to "enable" the best of Anonimity (Tor) + best of Web > Browsing (Firefox) with best of encryption (GPG) ? I don't consider Firefox the 'best of Web Browsing' or GPG the 'best of encryption'. They are only the crap tools we're stuck with for now. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Ideas to securely implement PGP encryption/decryption
On 2011-10-10, Fabio Pietrosanti (naif) wrote: > Hi all, > > i understand all the doubt from Mike and Ransom about the possible > exposure of user's security trough the exposure of functionality that > can be "called by a remote web-application". > > This is an idea to mitigate most possible security issues: > * Put the encryption functionality into the hands of user actions > * Provide minimal interaction between Javascript/XUL functionalities > > Basically a user would like to encrypt/decrypt/sign: > - text form > - file uploaded/downloaded > > That kind of actions could be implemented like explicit actions that the > user have to take. > * Text form Encryption > - Right click on web/text form -> Encrypt/Decrypt You missed the point of https://tails.boum.org/bugs/FireGPG_may_be_unsafe/ entirely. >From the first section title (in BIG letters) on that page: "Decrypted text can be stolen though JavaScript" And from the short paragraph right under the BIG box containing katmagic's sample exploit code: "A similar approach should also work for stealing a plaintext written in a text box before it's encrypted." > * File Encryption > - Upload Box can provide an option (in the file browsing window) to Encrypt > - Download Box can detect if it's encrypted, and provide an option to > Decrypt (in the file download box) This sounds like a feature that someone who understands how to write secure Firefox extensions might be able to implement safely. Make sure whoever implements it warns users that files' names will be sent in the clear, because they will be sent in the clear (and/or exposed to JavaScript). > This would work without any server-side > invocation/manipulation/whatsoever trough client-side code that could > expose vulnerabilities. > > That way there will be a "user firewall" between the encryption > functionality and the possible active content coming from the server > mitigating the risks of possible XUL/XSS and other attacks coming from > active-javascript calling XUL. Asking the user for permission does not block many attacks, even if the user understands the implications of granting permission to perform a GPG operation. > Also Key Management functionality could stay off protected by making a > proper section (XUL) under Firefox options/menu that the user can use. XUL is the reason Firefox has so many code-exec bugs. It would be easier and safer to ship one of the existing GPG key management GUIs written using a real GUI toolkit. > No code coming from the web would be allowed to interact with the > plug-in but the end-user will still have all the encryption features > under his power, usable in a modern web-based world. No code coming from the web needs to interact with the GPG plugin in order to grab the plaintext of a GPG message. > What do you think? I think you've found a feature (encryption of files to be uploaded) which could be implemented securely, and which might actually be useful to a few users. I'm not convinced that feature is worth the trouble of implementing and auditing a browser extension that would provide it. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor compromised?
On 2011-10-14, torvlnt...@fastmail.fm wrote: > A guess is that there might be a link between the bridges > enumeration attack mentioned in that article and the recent spike > in bridge use, for which one of the hypotheses was a botnet > (https://lists.torproject.org/pipermail/tor-talk/2011-September/0 > 21347.html). > > Creating many circuits through the bridges is a way to make them > visible to a large proportion of relays, including potentially > malicious ones. You can only create many circuits through a bridge if you already know its TCP address. > A possible countermeasure might be something similar to the > "Entry Guards" mechanism for circuits that go though bridges. We plan to make bridges direct their clients' circuits through their entry guards. See https://svn.torproject.org/svn/projects/misc/rransom/2011/dev-meeting-photos-2011-07-25-01/orig/100_2373.jpg for the few notes we have online from when we discussed bridge concealment at the Tor developer meeting this summer. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor compromised?
On 2011-10-14, Mansour Moufid wrote: > On Thu, Oct 13, 2011 at 5:30 AM, George-Lopez wrote: >> French students were able to exploit a vulnerability in Tor network >> Details here (french): >> http://www.itespresso.fr/securite-it-la-confiance-dans-le-reseau-d-anonymisation-tor-est-ebranlee-47287.html/2 > > More information: > > http://www.h2hc.com.br/palestrantes.php#Speaker7 > http://twitter.com/#!/efiliol/status/124427936001564672 > > Sounds to me like a cryptographic attack (among others) -- the virus > modifies the crypto upstream and there is an observable effect > downstream. Could holding a CTR nonce constant in RAM (combined with > plaintext injection) have a ripple effect in the Tor network? We already use a fixed (all-zero) counter-mode nonce, since we never use the same AES key for more than one counter-mode stream. A change to an Tor relay's RNG or relay encryption can only affect the connections (both circuits and TLS connections) between that relay and the clients connecting to it. If the later relays on a circuit are behaving correctly, there is nothing an entry node can do to modify the data sent on a circuit without causing that circuit to fail completely (with high probability); if the exit node on a circuit *is* compromised, the entry node doesn't need to muck with the circuit data -- logging circuit-extension times is sufficient to trace the circuit. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] still problems - update available
On 2011-10-14, Joe Btfsplk wrote: > Someone said the problem of inaccurate notices from TBB that an update > was available was fixed. This morning, I'm still getting the notice. Have you restarted TBB since you were told that message was fixed? I just restarted one of my TBBs, and it performed the update check again and didn't show the ‘your TBB is out of date’ message. (Yes, the update check is only done on startup. Yes, this makes it rather useless to many (most?) TBB users, who keep their TBBs running for a long time. No, we can't just repeat the update check periodically; it's bad enough that the update check makes a TBB's first circuit recognizable at the exit node, and that every time a user opens a new window, the exit node can tell that the user is opening a new window and can tell whether TBB is asking check.tpo to send the out-of-date warning message. (I don't think we realized that was a problem before we deployed this update notifier and shouted ‘Wolf! Wolf!’ at our users.)) Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Browser Bundle: PGP encryption built-in?
On 2011-10-10, Arturo Filastò wrote: > On 10/10/11 9:44 AM, Robert Ransom wrote: >> On 2011-10-10, Fabio Pietrosanti (naif) wrote: >>> is anyone evaluating whenever to include PGP encryption support into the >>> default Tor Browser Bundle as a Firefox extension? >> No. >> > I actually think it would be a great idea to include PGP encryption > support into the browser. > I remember discussing this with Jake some time ago of maybe in the > future having a bundle for Thunderbird and enigmail. I don't see why it > it a bad idea to move one step closer into that direction by including > PGP in the TBB. Adding GPG to a web browser does not move us any steps closer to having a mail user agent audited and packaged for use with Tor. >>> I looked at the implementation and: >>> >>> * FireGPG it's discontinued http://getfiregpg.org/s/install >>> It also seems it was using a "bad design" practice for the IPC >>> communications between various modules. >>> >>> * NPAPI based GPG is just released (by old FirePGP contributor) >>> https://github.com/kylehuff/webpg-npapi >>> >>> Having a support for GPG encryption into a generic browser, with PGP >>> operations usable from Javascript/XUL, could open a lot of improvements >>> and opportunities to secure Webmail and other web applications. >> No. See https://tails.boum.org/bugs/FireGPG_may_be_unsafe/ , but >> beware -- I'm sure katmagic and I missed a few dozen attacks. >> > Well that attack proposed there is pretty basic, I really think this is > a useful idea and it should not be discarded with no thought. There are two attacks on that page. When I thought of the keyring-enumeration attack listed there, I hadn't heard of the plaintext-leak attack yet, so I thought that only FireGPG's API was dangerous, and then only to Tor users who might be trying to remain anonymous or pseudonymous. (I have since realized that I really don't want an attacker to be able to read my keyring, even if They know who I am already.) Then katmagic told us about the plaintext-leak attacks on FireGPG, and I thought ‘Oh crap, that's *scary*.’. And *then* I discarded the idea of GPG-in-a-browser. These are not attacks on easily-avoided flaws in FireGPG's implementation. These are attacks on FireGPG's *purpose* -- *any* browser extension that did what FireGPG was *designed* to do would be vulnerable to these attacks. The Mikes and katmagic are trying to come up with new designs that could, in theory, be implemented safely. In practice, if you try to let users enter text to be encrypted into something that looks like a web form, an attacker *will* find a way to fool users into entering their plaintext into something that JavaScript can read from (or intercept key-press events for...), because a web form can be made to look like your GPG plaintext-entry area. So the only option is to have users enter plaintext into something that is clearly a separate window, and clearly not under the control of any web page -- and that defeats most of the purpose of putting GPG in a browser. >>> At http://globaleaks.org we'll most probably need such kind of support >>> into the browser and we're wondering if this could accomodate a standard >>> "requirement" of the Tor Project for the Tor Browser Bundle. >> No. >> > I must also here disagree, but I think I am a bit biased . > > Anyways as I said, it would be of great use for people to be able to > user PGP built into the browser, at least for sending encrypted email. > > It should not be implemented in a rush, but the gain that can be drawn > from such a feature is not slim. The gain is slim compared to the difficulty of designing a secure GPG browser extension and implementing it securely. Auditing a real MUA for use with Tor would be less difficult and *far* more useful. Also, we don't have room left in TBB for a GPG distribution at the moment. Firefox and Qt are too bloated. > Instead of having people download and install complicated software to > send me and an encrypted message I can point them to the TBB and they > are all set. Not at all a badi dea. It's a bad idea if an attacker is very likely to succeed at grabbing users' plaintexts. >>> It would be also possible to easily make very simple "XUL" interfaces to >>> handle basic PGP based file encryption operations, de-facto bundling a >>> GPG client (with a Browser UI) into the TorBrowserBundle. >> This sounds reasonable, except for the parts about the XUL interface >> and the browser-based UI. It also sounds rather like GPG4Win, except >> for those parts. >> >>> What
Re: [tor-talk] since today check.torproject.org states "you are not using tor"
On 2011-10-15, Andreas Bader wrote: > On 15.10.2011 22:16, Andrew Hall wrote: >> I've been using the TBB 2.2.33-2-Windows for the past week or so. >> >> Since this morning when the browser goes to the home page - >> check.torproject.org - it says "Sorry. You are not using Tor" and states >> my >> "...IP address appears to be: 38.229.70.31". >> >> This IP is always the same no matter how many re-starts of TBB I make. I >> notice the IP resolves to sergii.torproject.org >> >> I have also tried checking "My ISP blocks connections to the Tor network" >> but this makes no difference. >> >> Should I be concerned about this ? No. We tried setting up an 'exit enclave' on check.torproject.org, which causes Tor clients to open their TCP streams to a server over a circuit built to a Tor relay on that same server. This should make it harder for a malicious exit node to notice that you are opening a new Firefox window in your Tor Browser Bundle, among other things. Unfortunately, a bug in one of the services behind check.torproject.org caused it to not realize that connections made through the exit enclave were in fact coming from Tor. That issue should be fixed soon. > just do a reinstall of OS and TOR. > Or use it on a live disc, would be most secure. Malicious bullshit like this is not helpful. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Suggestion: make _hidden services_ choose random entry nodes often!
On 2011-10-21, hi...@safe-mail.net wrote: > Since hidden services don't need to stick to the same entry nodes, the > Tor developers should really consider making the Tor client randomly > choose entry nodes, just as with middle and exits, for hidden service > usage. It should be easy to add and it will increase the security of > hidden services greatly by adding lots of randomness. Bullshit. See http://freehaven.net/anonbib/#hs-attack06 for the main reason Tor uses entry guards. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor client pushing large amounts of data?
On 2011-11-03, Sebastian Lechte wrote: > My local tor client runs 0.2.3.7-alpha. Just now I stumbled upon this: > > Heartbeat: Tor's uptime is 2 days 6:00 hours, with 0 circuits open. I've > sent 48.04 GB and received 992.41 MB. > > > I don't run a bridge and don't run hidden services. Nothing in my usage > makes me expect the large 'sent' value. Is the counter wrong or do I > want to investigate further? This looks like a mostly-harmless integer overflow bug. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] New Browser Bundle
On 2011-11-09, Andrew Lewman wrote: > On Tuesday, November 08, 2011 08:56:47 Christian Siefkes wrote: >> Does that work? As I understand it, clicking the "Use a new identity" >> button in Vidalia tells Tor to build new circuits for subsequent >> connections, but it doesn't seem to affect Aurora -- all the cookies that >> have assembled since the start of the session are still there. (At least >> on Linux, using the current version.) >> >> Or is there a different 'new identity' feature I missed? > > There is a 'new identity' button in vidalia which does both clear caches and > such in aurora and send new identity command to tor. No. The ‘New Identity’ command in Torbutton's popup menu clears state in the browser; Vidalia's ‘New Identity’ command does not. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] variable speed limits on ports ...
On 2011-12-14, John Case wrote: > > Let's say I run an exit node, and I have a 10 Mb/s connection. > > I join up, run for a while, get qualified as a good exit, speed checks out > at 10, and so on. All is well. > > But then let's say that, at the OS level, I rate limit one of the TCP > ports I allow to exitto a much lower level - let's say I allow: > > 22,80,443,6667 > > and 22,80,443 go full bore at 10 Mb/s, but I rate limit 6667 to 1 Mb/s. > > How does this get categorized by the Tor network ? Do I continue to show > as a 10 Mb/s exit node ? Do I get labeled as a bad exit ? Perhaps lots > of exits do this and it is an accepted practice ? I expect that no one would ever notice that per-port rate-limiting configuration. > I *think* the speed is tested via Tor network relay operations, and not on > a per-exit-port basis, so I suspect as long as I keep my intra-Tor traffic > running at 10, I get labeled as 10. Correct ? The ‘bandwidth authority’ currently measures exits' available bandwidth by exiting to a test HTTPS server on port 443. See https://gitweb.torproject.org/torflow.git/blob/HEAD:/NetworkScanners/BwAuthority/README.spec.txt for more information. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [tor-announce] Tor 0.2.2.35 is released (security patches)
On 2011-12-16, intrigeri wrote: > Hi, > > Roger Dingledine wrote (16 Dec 2011 18:19:10 GMT) : >> Tor 0.2.2.35 fixes a critical heap-overflow security issue in Tor's >> buffers code. Absolutely everybody should upgrade. > >> the attacker would need to either open a SOCKS connection to >> Tor's SocksPort (usually restricted to localhost), or target a Tor >> instance configured to make its connections through a SOCKS proxy > > My understanding of the flaw makes me think users of Tails 0.9 are not > at risk: an attacker who is able to connect to the Tor's SocksPort in > Tails is likely to be in a position to run arbitrary code already; and > Tails does not configure Tor to use another SOCKS proxy. > > Please correct me if needed. Your understanding is correct. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] On verifying security of Tor Routers idea
On 2011-12-21, Chris wrote: > I think the best approach is to send off an email with the new proposal to > all node operators. See what the response is from the node operators. Let > node operators know if they do not explicitly opt out they may be included > by default in the scans if the percentage of nodes that respond is not > sufficient. What we want is a response from every node operator either way > though so we can judge. DO NOT mass-mail relay operators about this. There may be valid reasons to send mail to some or many relay operators, but this idiotic port-scan idea is not one of them. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Automatic vulnerability scanning of Tor Network?
On 2011-12-21, Chris wrote: >>> So please, don't bother with that justification, a scan like that would >>> probably just be one scan of 1 you receive every week. >> >> The scan which happened yesterday was enough to get the attention of both >> the >> university network security team, and the sys-admins of the department >> which >> hosts my Tor server. The last time this happened was 2009. >> >> It's already difficult enough to host a Tor server, but triggering >> institutional >> IDS is only going to make justifying the benefit of running a node harder. >> > > This is a dumb policy although that being said if this is going to have a > significant negative impact on the Tor network from a bandwidth or > security (loss of nodes could impact security too) then what about having > the Tor software do a check on the system? This would bypass the network > and avoid intrusion detection systems in place on the network. I imagine > anyway. All of these ideas about removing allegedly ‘insecure’ or ‘vulnerable’ relays from the network ignore the fact that someone who wants to compromise Tor relays and use them to attack Tor users will just make the relays appear to not be vulnerable, so that they can stay in the network. I'm amazed at how many people want us to remove relays which have definitely not been compromised from the Tor network. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] No tor bridges
On 2011-12-27, andr...@fastmail.fm wrote: > Can't get Tor bridges anymore through the Vidalia Network setting or the > bridges.torproject web page. > > Any chance that'll be fixed? Yes, it's fixed now. Thanks for the report! Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] What is going on with /var/run/tor?
On 2011-12-29, Matthew R wrote: > I am becoming increasingly perplexed about my Tor setup. > > Tor does not appear to run on start-up. I assume this because I cannot see > it using ps aux | grep tor. > > My torrc is in /etc/tor/torrc with user and group set as 'root'. > > I run 'sudo tor' and receive the following errors: > > Dec 29 20:12:55.076 [notice] Tor v0.2.2.35 (git-73ff13ab3cc9570d). This is > experimental software. Do not rely on it for strong anonymity. (Running on > Linux i686) > Dec 29 20:12:55.079 [notice] Initialized libevent version 1.4.13-stable > using method epoll. Good. > Dec 29 20:12:55.079 [notice] Opening Socks listener on 127.0.0.1:9050 > Dec 29 20:12:55.079 [warn] Directory /var/run/tor does not exist. > Dec 29 20:12:55.079 [warn] Before Tor can create a control socket in > "/var/run/tor/control", the directory "/var/run/tor" needs to exist, and to > be accessible only by the user and group account that is running Tor. (On > some Unix systems, anybody who can list a socket can conect to it, so Tor > is being careful.) > Dec 29 20:12:55.079 [notice] Closing partially-constructed listener Socks > listener on 127.0.0.1:9050 > Dec 29 20:12:55.080 [warn] Failed to parse/validate config: Failed to bind > one of the listener ports. > Dec 29 20:12:55.080 [err] Reading config failed--see warnings above. > > It is correct that /var/run/tor does not exist. I then create /var/run/tor > with user and group as 'root' and run 'sudo tor' again: [snipped] > I don't understand why I get this error because I am 'root' not > 'debian-tor'. Su-ing into root then running tor provides the same error > message: See /usr/share/doc/tor/README.Debian . /var/run/tor needs to be owned by the debian-tor user and group. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Differences between real exit traffic and exit-generated traffic ?
On 2011-12-30, John Case wrote: > > Let's say I have an exit node handling average traffic and number of > connections (whatever that is). Let's also say that port 22 is included > in my exit policy. > > Now let's say that I, as the administrator, log onto the exit node and: > > ssh u...@host.com > > I understand that a global observer with traffic analysis blah blah blah. > > But what about someone just watching the exit node ? Is there anything at > all about my ssh connection generate from within the exit node that would > distinguish it from "real" exiting Tor traffic ? Someone watching all traffic to and from the exit node would be able to distinguish that connection from Tor traffic because traffic on the SSH connection would not be relayed over any OR connection (in either direction). Someone watching only that SSH connection (e.g. a sniffer at host.com) would be able to distinguish that SSH connection from an exiting Tor stream because your SSH client would respond to messages from the server immediately after they reach the exit node, whereas an SSH client connecting over Tor would not be able to respond until data from the server reached the other end of a Tor circuit. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] problem with blutmagie network status site after upgrading to tor-0.2.3.10-alpha
Add "UseMicrodescriptors 0" to your torrc. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] tor out of date
On 2012-01-19, Praedor wrote: > I KNEW this would happen as people suggested it. I do NOT want the tor > browser bundle, I want to run a tor relay. I installed my linux distro's > tor package and, just as I knew it would be, it is out of date. I go to the > tor website and it no longer offers tor standalone, doesn't even provide for > tor sourcecode. See https://www.torproject.org/download/download . (The easy download page (https://www.torproject.org/download/download-easy) provides a link to that: “Looking For Something Else? View All Downloads”) > TBB is NOT setup for running fulltime relays or exits. You MUST provide the > basic tor package too! We do. See https://www.torproject.org/docs/debian and https://www.torproject.org/docs/rpms for instructions for Debian, Ubuntu and some RPM-based distributions; if we don't provide a package for your distribution, you can still build from source. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] hidden files in tbb/linux directories, are these common files or rogue?
On 2012-01-22, m...@tormail.net wrote: > I located some hidden files in the extracted tbb/linux, current version, > directories, are these common files or rogue and what generates these > files? > > Within the Lib directory: > > size / name / sha1sum > > 1264 .shared-library-name-list > d43f3c1d4d213f8a911d3eb8725182d0f3dc61f0 > > 808 .shared-library-rename-action-list > 8db99e99f31310b3f8e7dd9cab341090fc30b88d > > Within the Lib/libz directory: > > size / name > > 83 .shared-library-name-list > 18e05ed73a6531d3f0e097ce9d562788fe50cd86 > > 56 .shared-library-rename-action-list > 258051374c38f7d8c1a38648e3116ada648df1b4 > > Contents of the Lib hidden files: [omitted] > Do other tor user's tbb/linux extracted directories contain these, too? > What are they? Those files are generated by one of the TBB-for-Linux build scripts (https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/remove-shared-lib-symlinks#l182), so that if that script ever misbehaves, I (or whoever else has to debug it) can find out what it did and what it was trying to do without having to rebuild all of TBB. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Fwd: ANONdroid
On 2012-01-25, Nathan Freitas wrote: > Anyone have an opinion of JonDonym? JonDonym (or whatever they called themselves at the time) backdoored its service in order to deanonymize a user. Their centralized design makes it likely that their service will be backdoored again. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Aurora only build
On 2012-01-27, AK wrote: > Actually, the Tor Browser bundle is built from Firefox Portable binaries. > > From README.dev: >> Using build-scripts/Makefile it is possible to create a working USB >> Tor bundle. It's limitations include: >> - It uses the FirefoxPortable binaries README.dev has not been updated since it was split out of the README file in April 2009. That statement is no longer true. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] irc clients and Tor
On 2012-02-09, Jacob Appelbaum wrote: > Hi, > > Recently my main IRC bounce went down and I decided to redo things. I'd > like to help save people some time and also to give some advice for > people who want to use irssi or similar clients to connect to the Tor > development channels. > > Basically using Tor and irssi is intolerable - it doesn't work with > privoxy chained to Tor if you want to use SSL/TLS. As far as I can tell, > it's not possible to use any SOCKS proxy safely if at all without major > pain. torsocks doesn't work for reasons that I can't easily debug and so > I took the kernel filter path... I suspect that the breakage in irssi+torsocks is that irssi uses non-blocking sockets, and the version of torsocks shipped in Debian Squeeze doesn't handle non-blocking sockets correctly. I've heard that a later version of torsocks does work correctly on programs which use non-blocking sockets. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] hidden service
On 2012-02-10, Flaubert izivyose wrote: > Hey I am trying to configure my tor for hidden services, but when I go to > change my torrc file it only has this in it > > # If non-zero, try to write to disk less frequently than we would otherwise. > AvoidDiskWrites 1 > # Store working data, state, keys, and caches here. > DataDirectory .\Data\Tor > GeoIPFile .\Data\Tor\geoip > # Where to send logging messages. Format is minSeverity[-maxSeverity] > # (stderr|stdout|syslog|file FILENAME). > Log notice stdout > # Bind to this address to listen to connections from SOCKS-speaking > # applications. > SocksListenAddress 127.0.0.1 > > > what do I to be able to change it to go into hidden service? See https://www.torproject.org/docs/tor-hidden-service and https://www.torproject.org/docs/tor-manual . Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Help users in Iran reach the internet
On 2012-02-10, kolo...@gmail.com wrote: > You will need the send the new IP:Port to Tor-asssitants. Maybe you could > Cron Job it? Please don't. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Ars Technica on Iran's latest strategy
https://bugs.torproject.org/4927 seems to have been effective. We just need to hunt down and fix some obfsproxy (server-side) crash bugs and get a good list of very-high-bandwidth obfsproxy bridges before we tell everyone where to find a Tor+obfsproxy client bundle. On 2012-02-10, Watson Ladd wrote: > http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars > I'm not sure what we can do in response to something like this. > Obviously this is a pretty extreme move with high costs, > so Iran doesn't have the ability to do anything else, and by making > the choice shutting down e-commerce or tolerating tor, > we do a lot. But what countermeasures can we envision against this? > Sincerely, > Watson Ladd > ___ > 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
Re: [tor-talk] Trying to help
On 2012-02-11, Anne Magarey wrote: > Please excuse my extreme ignorance, but does this mean my bridge isn't > working? > "Feb 11 17:44:09.219 [Notice] Have tried resolving or connecting to > address '[scrubbed]' at 3 different places. Giving up." No, it doesn't. This means that you (or a program on your computer) tried to use that Tor instance as a client to connect to a server which wasn't running at the time. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Trying to build the TOR Obsfproxy
On 2012-02-12, Duncan Patton a Campbell wrote: > > Howdy? I just started in trying to build this and am > getting errors that indicate problems with SSL: > > $ git clone https://git.torproject.org/obfsproxy.git > Cloning into obfsproxy... > error: SSL certificate problem, verify that the CA cert is OK. Details: > error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify > failed while accessing https://git.torproject.org/obfsproxy.git/info/refs > > Similarly with libevent: > $ wget > https://github.com/downloads/libevent/libevent/libevent-2.0.16-stable.tar.gz > --2012-02-12 16:05:44-- > https://github.com/downloads/libevent/libevent/libevent-2.0.16-stable.tar.gz > Resolving github.com (github.com)... 207.97.227.239 > Connecting to github.com (github.com)|207.97.227.239|:443... connected. > ERROR: cannot verify github.com's certificate, issued by `/C=US/O=DigiCert > Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV CA-1': > Unable to locally verify the issuer's authority. > To connect to github.com insecurely, use `--no-check-certificate'. > > I'm running OpenBSD 4.9 on this system, sooon to be upgraded to 5.x. Install a CA certificate bundle. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] glibc's DNS lookups fail
On 2012-02-14, douglastskill...@lavabit.com wrote: > Hello List, > > I am experiencing a strange problem for about two weeks or so. > > I am using GNU/Liux (Debian 6 x86-64) and Tor 0.2.2.35 built from source. > I forward all my tcp traffic and udp traffic on port 53 to my tor instance > via netfilter. Are you using the iptables rules shown on https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy ? Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Installer for obfsproxy as a Windows service available
On 2012-02-18, awgh wrote: >A couple of important notes: > 1) I have only tested this with TCP mode. I don't expect UDP to > work through Socks proxy, but haven't yet tried it. obfsproxy does not support UDP. > 2) Once, obfsproxy died on me and I had to go to Control > Panel->Administrative Tools->Services and restart the obfsproxy service. > This seems to be a one-time crash, though. It's probably https://bugs.torproject.org/5156 , which is quite reproducible. (Fortunately, Roger reproduced it on Linux, where it was able to give us some information which might let us debug it.) >I am planning on adding some additional features to the installer > bundle, to allow the configuration of shared secrets and the importation > of existing config files. I don't think obfsproxy supports that yet. (Patches welcome!) Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] irc clients and Tor
On 2012-02-09, intrigeri wrote: > Robert Ransom wrote (09 Feb 2012 13:14:46 GMT) : >> I've heard that a later version of torsocks does work correctly on >> programs which use non-blocking sockets. > > torsocks 1.2-3 from Debian unstable should be installable as is on > a Squeeze system. If someone confirms it fixes this problem, I'll > upload a backport to the official Squeeze backports archive once it > has migrated to testing, i.e. in one week from now. torsocks 1.2-3 just hit wheezy/testing, and it works on irssi (at least as shipped in wheezy). Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Obfsproxy Documentation/Help?
On 2012-02-20, Low-Key² wrote: > I'm having trouble coming across documentation for the possible arguments > that can be used with Obfsproxy. My question specifically is whether or not > there is a way to open Obfsproxy on a specific port via the > ServerTransportPlugin call in the torrc file? Yes, there is. Oh, you want to know *how* to do that? Look at/edit/copy the line beginning with “TransportProxy” in the ‘state’ file in Tor's DataDirectory. That file is not user-friendly; edit it as little as you can. You may need to use a text editor which can handle Unix-style line endings. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] What is the new signature of new TBB?
On 2012-02-20, James Brown wrote: > Hello, friends! > > I have got a new TBB file > tor-browser-gnu-linux-x86_64-2.2.35-7.2-dev-en-US.tar.gz for the site of > the Torproject and have tried to verify it. > I have had the next result: > $ gpg --verify > tor-browser-gnu-linux-x86_64-2.2.35-7.2-dev-en-US.tar.gz.asc > tor-browser-gnu-linux-x86_64-2.2.35-7.2-dev-en-US.tar.gz > gpg: Signature made Mon Feb 20 12:45:15 2012 UTC using RSA key ID 140C961B > gpg: Can't check signature: public key not found > > As I can the the previous version was signed by Erinn Clark: > gpg --verify tor-browser-gnu-linux-x86_64-2.2.35-7-dev-en-US.tar.gz.asc > tor-browser-gnu-linux-x86_64-2.2.35-7-dev-en-US.tar.gz > gpg: Signature made Sat Feb 18 19:53:24 2012 UTC using RSA key ID 63FEE659 > gpg: Good signature from "Erinn Clark " > gpg: aka "Erinn Clark " > gpg: aka "Erinn Clark " > > > Is the sign of tor-browser-gnu-linux-x86_64-2.2.35-7.2-dev-en-US.tar.gz > right sing? See: https://blog.torproject.org/blog/new-tor-browser-bundles-linux Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Let's make Onion Addresses Meaningful To Humans
On 2012-02-24, Ahmed Hassan wrote:
> Hello Folks,
>
> I have a cool idea to make onion addresses memorable. That will have no
> effect on its authenticity and security.
>
>
> First, I need to define some terms I will use in this email.
>
> Σ*_{e}: is any English (or any other language) word.
>
> D*: is a set of all English words (or any other language again) in
> dictionary.
Which languages do you want us to ship a dictionary for in every Tor
client? (Please specify the exact dictionaries you want us to use as
well.)
How large are these dictionaries (in bytes)?
> D*_{N}: N means the location of element Σ* in D*.
>
> For example, if D* = { 'cat', 'hat' ,'rat' }.
> D*_{0} returns 'cat', and D*_{'cat'} returns 0
>
> max(D*): is a total number of words in a dictionary D*.
>
> I hope you didn't get confused at this point.
>
>
> Onion address needs to be converted to decimal instead of base 32 to
> make it easier to implement.
No. Computers do not operate efficiently on numbers represented in base 10.
> Let's say I have already have a value of onion address converted to a
> decimal. That number is 2025107508922.
>
> I will take that number and convert it to number in base max(D*).
>
> If we have 51236 words in English dictionary, the result of that
> conversion will be only 3 digits numbers. The numbers after conversion
> are the following:
>
> 771-22133-48918
>
> Here is a wolframalpha conversion link
> http://www.wolframalpha.com/input/?i=2025107508922++convert+to+base
> +51236
>
> I used dash "-" instead of colons ":" to separate the converted digits.
> It's easier to make it work with the URL (URL uses colon to separate
> address from port) , and easier to convert to the original value.
>
>
> We will take 711, 22133 and 48918 and return the Σ*_{e} from D*. Where
> Σ*_{e} is an English word, and D* is a dictionary.
>
> So, D*_{771}: returns Σ*_{e}', and D*_{22133}: returns different
> Σ*_{e}'' and so on.
>
> At the end we will have something like that:
>
> Σ*_{e}' - Σ*_{e}'' - Σ*_{e}^(3).onion
>
> If Σ*_{e}' is equal to 'cat', Σ*_{e}'' ( '' means another word) is
> equal to 'rat' and Σ*_{e}^(3) is equal to 'hat'. The final result will
> be something like this
>
> cat-rat-hat.onion.
Have you tried this using the actual dictionaries that you want us to
use? Are the resulting addresses really memorable? How long are the
resulting addresses? Can they be entered into a computer as
efficiently as addresses in the current format? Can a human proofread
addresses in this form for errors as efficiently as addresses in the
current format?
Robert Ransom
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Let's make Onion Addresses Meaningful To Humans
On 2012-02-24, Andreas Krey wrote: > Which node interprets the .onion names to hashes, anyway? Tor clients themselves interpret hidden service hostnames, so every Tor client would need to include every dictionary. (Dictionaries couldn't be kept in an optional extra package, because clients which do not have a particular dictionary would be easily distinguishable from those which do have it.) Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] log notice & warn
Please open a Trac ticket. On 2012-02-25, eliaz wrote: > [TBB -7.1 on Vista x64] When I overwrite log notice in torrc to warn, I > get only info lines, no others. My reading of the manual is that with > log warn I should get only warn & err lines. Am I missing something or > is this a bug? > ___ > 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
Re: [tor-talk] dizum
On 2012-02-26, Anne Magarey wrote: > Please, what does this mean, and can I do something about it? > > It is in the tor Iran obfsproxy bridge log file. I had to turn off my > computer and on reboot have this repeatedly in the file. It's been > waiting for ~45 minutes so far. >> [warn] Got a certificate for dizum, but we already have it. Maybe they >> haven't updated it. Waiting for a while. This means that one of the directory authorities started using a new ‘certificate’ to sign a ‘consensus’. This message isn't something that normal users and relay/bridge operators should care about; we'll downgrade its severity in future releases of Tor so normal users won't see it. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Does obfsproxy make any sense for relays
On 2012-02-29, MacLemon wrote: > I was wondering if building tor with obfsproxy would make any sense for a > relay. The documentation suggests that obfsproxy is rather exclusive for > bridges yet isn’t absolutely clear about that. > > The only scenario I can fabricate is someone blocking tor by DPI, being > confident that they can block any tor traffic and subsequently doesn’t > bother to explicitly block relay IPs anymore. Doesn’t seem too realistic to > me. > > Would it hurt to implement obfsproxy into a relay? We don't know. We were worried that https://bugs.torproject.org/1776 would crash clients who use an obfsproxy with a relay behind it, but I've had a Tor 0.2.3.12-alpha-dev client running for over a day configured to use a relay as a bridge, and so far I haven't seen a crash. I'll be willing to declare that clients which use microdescriptors aren't susceptible to #1776 after a week or two (to ensure that moria1 has changed its onion key, and this issued a new microdescriptor). That won't help clients that are configured to also use a bridge running 0.2.2.x, but hopefully no one who uses obfsproxy will try to also use a regular bridge. I should start another Tor client with microdescriptors disabled, too. Maybe that will help us find (and fix) #1776, if it's still around in 0.2.3.x. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Does obfsproxy make any sense for relays
On 2012-02-29, MacLemon wrote: > On 29.02.2012, at 18:34, Roger Dingledine wrote: >>> Would it hurt to implement obfsproxy into a relay? >> Somebody needs to sit down and solve >> https://trac.torproject.org/projects/tor/ticket/1776 >> first > > May I draw the following conclusion from that or have I fallen for a > misunderstanding? > > Implementing obfsproxy as instructed here > https://www.torproject.org/projects/obfsproxy-instructions.html.en > but not setting "BridgeRelay 1" does actually make sense to potentially help > people reach tor? (Given the way Iran currently handles tor traffic.) > > This is what I meant with “implementation”. I guess it was bad wording on my > part (since I’m not native english speaking). I did net actually mean to > incorporate obfsproxy functionality into the tor binary (at the moment). It was bad wording, but we both knew what you had to have meant. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Operating system updates / software installation behind Tor Transparent Proxy
On 2012-03-02, Andrew Lewman wrote: > The trick is, I like to think I know what I'm doing and that I'll > notice if apt-get or my VM image fails to transfer untouched. Whether > I'll actually notice a sophisticated exploit in deb packages or my vm > image modified in perfect way that gpg or sha256 hashes don't detect, > remains to be seen. If I pulled a random person out of a barcamp and > asked them to do a OS X or Windows update over transparently proxied > tor, would they notice if the package was modified in transit? What do > these OSes do in this case? What about freebsd ports? Every FreeBSD port's list of distfiles includes hashes and sizes of each distfile to be downloaded. If I remember correctly, the only required hash is SHA-256. portsnap and freebsd-update reportedly use good, competently designed crypto to verify the files they download before parsing them in a shell script with (necessarily) root privileges. portaudit downloads, ungzips and untars an unsigned file as root, then parses a text file extracted from what was hopefully a tarball in a shell script run (unnecessarily) as root. Sucks to be a FreeBSD user. But apt uses GPG (run with (necessarily) root privileges) to verify the files it downloads. Sucks to be a Debian user when someone finds another code-exec bug in GPG's parsing code. > Or other package > systems? What about all of the other software that updates itself > automagically without a system package manager? This is a bigger risk to anonymity -- automatic update-related operations run in the background on a transparent-proxied system can link the traffic you intended to anonymize with properties of your operating-system installation (e.g. on Debian, /etc/cron.daily/apt leaks your system's time zone and the set of package repositories that you install software from to your circuits' exit node(s)). Windows users are at much greater risk from this, because most people install lots of crap software, thereby marking their systems (and thus their Tor circuits) with a unique set of automatic updaters. Of course, if you live in Iran, you're probably better off taking your chances with exit-node roulette than downloading unsigned, unverified updates directly through a known-malicious ISP. Just don't expect your transparently proxied traffic to stay anonymous. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Operating system updates / software installation behind Tor Transparent Proxy
through what Debian mirror you installed from and what time zone your VM is set for. Anonymity is hard! Let's do crypto. > So what do you suppose to do with the Transparent Proxy feature? How do you > want to solve the operating system update dilemma? Can the Tor network > handle the load? > > Resolutions possible: > a) Propose a solution. (That sounds like politician-speak.) Use Tor 0.2.3.x-alpha, give the user 10 or more SocksPorts and 10 or more DNSPorts to point things which really need to be anonymous at, and no TransPort. In the VM you're trying to ‘anonymize’, run 10 or more transparent-proxy-through-SOCKS stubs (one for each user ID in which you run a non-SOCKS-friendly application that you want to ‘anonymize’), and set up iptables rules. > b) Leave it complicated, a nice addon for power users only. Using a SocksPort safely is complicated. If you couldn't bother to SOCKSify an application's source code properly, did you audit it for all the possible information leaks that could nuke what little anonymity you had left after the cron jobs? > c) Encourage people to extensively use it. Let's not. It's bad enough that the GlobaLeaks clowns are telling people to point a Windows application SOCKSifier at their feet and pull the trigger. > d) Leave the situation as it is. Tell me, not to release a easy > per-configured package for an anonymous torified operating system. s/anonymous // You can prevent a system from making non-Torified connections without having to mash all of its traffic into the same Tor ‘identity’ with a single transparent proxy. > e) Remove the TransPort feature, make it even more complicated to use. So we > have to use transsocks again if we really want. Sounds like a good piece to split into a separate program, but splitting Tor's link protocols into separate processes is more immediately important. > f) Propose more, better solutions. (That sounds like politician-speak, too.) I'm all for auditing more applications, and then SOCKSifying them properly, so no one will need a transparent proxy. > rransomsaid [3]: >> Operating system updates over Tor are the main reason that >> transparent proxying is not recommended -- automatic update >> installers are likely to leak information about the software they >> are trying to update, whether due to malicious design or due to >> lack of consideration for users' location privacy. > > proper: This is the reason why we want to make them over Tor. Those > information would stay anonymous. The reason not to do them over Tor is the > network load as described above. No. See above, and see my reply to Andrew's message. > rransom said [3]: >> Also, this is not a ‘defect’, ‘critical’, or an issue to be addressed by >> changing ‘Tor Client’. Try tor-talk or IRC. > > proper: I think it is. Solution e) would be handled by Tor > Client. That ticket was a user support question, and did not belong in Trac. It was not a ticket about removing Tor's built-in transparent proxy support (or splitting it into a separate process). (I think it's too early to file such a ticket.) > If someone were to promote an easy-to-use per-configured > anonymous torified operating system, this could (I don't know, > that's why I ask here.) overload the network. This someone could be > me. I won't do it if you tell me not to do it, because I don't want > to kill the network I use. And someone else is probable not up to > it. The demand for such as thing is there, but no one started > working on it for years. Most of the people who were ‘up to it’ considered other tasks more important than developing an easy-to-misuse transparent proxy kit, and/or did not consider themselves qualified to make a transparent-proxied system (other than possibly Tails) ‘anonymous’. (I no longer think I'm capable of setting up an anonymous Debian system using a transparent proxy. Fortunately, I never got around to that back when I did think I was capable of it.) Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Awareness for identity correlation through circuit sharing is almost zero.
On 2012-03-05, pro...@secure-mail.biz wrote: > The users awareness for identity correlation through circuit sharing [0] is > almost zero. There should be more clear warnings about it on torproject.org. > > People are frequently told to extensively use Google. They do so and will be > affected. If you google the term [1] you will see that it has been > recommended all the time. The version spread at this time was version 423 or > below [2]. It didn't contain any warning that it's for advanced users only > and no sentence about identity correlation through circuit sharing. There > are so many instructions, howtos and blog posts. Everyone suggest to point > all applications they want to torify to 127.0.0.1:9050. Originally a Tor > developer brought this to my attention. [3] Everyone who suggests using BitTorrent over Tor is pointed to https://blog.torproject.org/blog/bittorrent-over-tor-isnt-good-idea , which mentions that issue. It should be more visible. Perhaps you could send a patch to add it to the list of warnings on the download page (see https://svn.torproject.org/svn/website/trunk/download/en/ for the source files). > Also tails, which is listed on torproject.org, uses only one SocksPort [4] > and mixed all activity into the same SocksPort. Using multiple SocksPorts from the same Tor client only helps if you are using Tor 0.2.3.x-alpha, which introduced 'stream isolation'. (I don't think 0.2.2.x supports multiple SocksPorts at all.) Read the man page. The Tails developers plan to start using Tor 0.2.3.x and 'stream isolation' as soon as a 0.2.3.x stable release is available. This might or might not happen in time for Tails 0.11. (But applications running within Tails have much less information to leak about their user.) > How to mitigate identity correlation through circuit sharing? > Ideas... > - do not use DnsPort > - do not use your local DNS resolver (like always recommend), deactivate it > while testing > - use an unique SocksPort for all applications you do not want to be liked > to one pseudonym > - tell your application to use remote DNS resolution, > - if that is not possible, use a wrapper such as torsocks/usewithtor > - a local DNS resolver who catches all DNS requests and redirects them > through Tor will probable also not help, as many applications will share the > same exit for those DNS requests More importantly, many applications which you did not intend to torify will use that DNS resolver. > Unfortunately torsocks/usewithtor [5] also seams to have only a single > global configuration file /etc/torsocks.conf [6], which means you can use it > only for one pseudonym. If you start more then one application through > torsocks/usewithtor it may happen that they all share the same circuit/exit. > There seams to be no option to redirect each application to a different > SocksPort. It would > be nice if there were a feature to tell torsocks/usewithtor which IP:PORT to > use trough command line arguments. The torsocks command supports a user-specified configuration file (read the man page). The usewithtor command does not. I agree that someone should make configuring torsocks easier. (Note that usernames and/or passwords can be used to separate streams, too.) > [0] If you redirect your (for anonymous use) browser, your mail client, your > irc client, etc. to a single SocksPort (standard 127.0.0.1:9050) everything > may be routed through the same circuit and exit node. Your real IP remains > hidden but (most of) your activity can be correlated to the same pseudonym. This is the main reason that I'm not a fan of TorBOX. It provides pseudonymity, not anonymity, but most people will think that it provides anonymity. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Can't access Tor network
On 2012-03-10, andr...@fastmail.fm wrote: > In trying to access Tor while using a certain network the following > error/problem message appears in the log; > Mar 1 02:45:53.090 [Warning] Problem bootstrapping. Stuck at 5%: > Connecting to directory server. (No route to host; NOROUTE; count 2; > recommendation warn) Is your network cable plugged in? (Yes, this problem actually happens.) Have you tried using bridges? (Something is dropping all packets between your computer and the directory authorities. This doesn't look like a DPI box; it's dropping packets before it saw a single TLS handshake.) Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] high memory usage
On 2012-03-18, eliaz wrote: > The only problem I have with the bridge I'm running is that for some > reason the memory used keeps climbing up, so that after three or four > days I have to reboot the machine. AFAICT rebooting doesn't affect the > bridge's usefulness much, but I can't do much else when the mem use > reaches 2.9 G. I recall seeing some discussion of this way back in > tor-talk, but can't find it. Can someone point me to it? [Running on > Vistax64 2.5 GHz dual core cpu, 4 G RAM] Thanks - eliaz Which version of Tor are you using, and what package did you obtain it from? On a Unixoid operating system, recompiling Tor with the --enable-openbsd-malloc configure option would probably help. But that code isn't currently Windows-compatible. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Azureus cannot work with Tor
On 2012-03-22, Michael Holzman wrote: > Greetings, > > I'm a newbie trying to setup a working Azureus (aka Vuze)-Tor pair. > Unfortunately,I cannot achieve that. Reading the documentation and searching > the Internet did not help. Good. Read https://blog.torproject.org/blog/bittorrent-over-tor-isnt-good-idea . Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] TOR bridge mailing list
On 2012-03-25, bordergu...@riseup.net wrote: > Since I was not able to find a place to share tor bridges, I created a > place... or rather a mailing list: > https://lists.riseup.net/www/info/torbridges By default, each Tor bridge publishes a descriptor to the ‘bridge authority’. Every hour, the bridge authority sends the descriptors of currently running bridges to bridges.torproject.org, which distributes them to users who request bridges over HTTPS and by e-mail. > If you or people you know are interested in obtaining bridges or > disseminating them, this would be a good list to be on. The idea is that > people would set up bridges, and send the ip, port and print to this list, > and every week I would send out a limited list of what has been collected. Distributing bridge addresses once a week is not useful. Most bridges move to a different IP address every 24 hours. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How can the video play in TBB without plagins?
On 2012-03-25, James Brown wrote: > How cat that nice video > https://media.torproject.org/video/2009-install-and-use-tor-browser-bundle.ogv > play in TBB when my plagin Shockware Flash is disable? Firefox 4 and later support the HTML 5 video tag. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Choosing a name for a .onon
On 2012-03-30, Maxim Kammerer wrote: > On Fri, Mar 30, 2012 at 01:54, Seth David Schoen wrote: >> Choosing the first 40 bits of a hash generally requires trying an average >> of 2⁴⁰ >> possibilities; my laptop does about 3-4 million SHA1 operations per second >> (per CPU core) so it would take me 3-4 days (per CPU core) of computation >> to try that many possibilities on my laptop. > > Due to proliferation of Bitcoin, there are now very efficient SHA-256 > generators for off-the-shelf GPUs. The numbers at [1] suggest > performance that's at least two orders of magnitude faster than your > laptop — and for double-SHA-256 instead of a single SHA-1 (which I > assume can be done by the same software after some simple adaptation). > > [1] https://en.bitcoin.it/wiki/Mining_hardware_comparison > >> Of course this requires being able to change something trivial about the >> public key when generating the .onion address. > > Not necessarily — you can generate the hash first, and then check > whether the public key is legal. I.e., generate a 512-bit prime p, and > then go on with producing a completely random 512-bit e, and checking > whether SHA-1(ASN.1-RSAPublicKey(modulus=p*e, exponent=65537)) (which > is how Tor computes the .onion address) produces the desired result. > If it does, check whether e is prime. Density of primes in the range > of e is ~1/512, so that's just 9 bits more of search space, and > primality checking efficiency doesn't matter much. Shallot computes a single public modulus p*q and searches for a public exponent e which produces a SHA-1 hash with the desired properties. That's much faster than doing a 512-bit-by-512-bit bignum multiply for each hash, *and* the search for a suitable exponent could (in theory) be performed in parallel across many (untrusted) computers. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Choosing a name for a .onon
On 2012-03-29, Seth David Schoen wrote: > There's a nice description of the possibility of creating a public key > with a chosen set of bits at the beginning or end at > > http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html > > although note that the Tor hidden service identifiers are 80 bits, while > PGP short key IDs are only 32 bits, so it's 2⁴⁸ times as hard to fake a > hidden service as it is to make a colliding PGP short key ID. (Full PGP > fingerprints are 160 bits.) In the old-style (PGP 2.x) key ID format, a portion of the public RSA modulus was directly used as the key ID. The most difficult-to-implement algorithm that you could possibly want to use to attack that involves a lattice computation, and succeeds far faster than brute-force. New-style (OpenPGP) key IDs are hashes of the public key; the only attack that can produce a desired key ID is brute-force search. (That's not hard though -- for RSA, generate a keypair in the usual manner, then change the public exponent (as Shallot does); for DSA or ElGamal, generate a keypair and then search for powers of the group generator and of the public key which lead to the desired hash. Both attacks allow the brute-force search to be performed on computers which cannot be trusted to know the private key.) So yes, short PGP key IDs are very bad news. Avoid them if you can (but I doubt that you can). Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Choosing a name for a .onon
On 2012-03-30, Maxim Kammerer wrote:
> On Fri, Mar 30, 2012 at 06:06, Robert Ransom wrote:
>> Shallot computes a single public modulus p*q and searches for a public
>> exponent e which produces a SHA-1 hash with the desired properties.
>
> For some reason I thought that that would produce non-standard RSA
> keys, perhaps because the old ssl-genrsa only supported e={3,65537}
> (whereas the new ssl-genpkey doesn't have this limitation). Isn't the
> point of e like 3 or 65537 (with few bits set) to make encryption
> fast?
Yes. (Note that hidden service identity public keys are only used for
signature verification, which is not the same as encryption with any
modern padding scheme.)
But Tor didn't enforce that requirement for hidden service identity
keys soon enough, and I don't think OpenSSL's RSA implementation
benefits much from those particular choices of e (other than from the
fact that they're short).
> Do you know whether Shallot-produced RSA keys have any
> noticeable detrimental effect on relays load because of the
> unrestricted exponent?
Maybe a little. No one will let Shallot run long enough to produce a
really big public exponent, though. (Relays raise 1024-bit numbers to
320-bit powers all the time for forward secrecy. Shallot won't
generate 320-bit public exponents.)
Maliciously generated hidden service identity keys could have much
larger public exponents, but hopefully no one will bother implementing
that DoS attack.
>> That's much faster than doing a 512-bit-by-512-bit bignum multiply for
>> each hash, *and* the search for a suitable exponent could (in theory)
>> be performed in parallel across many (untrusted) computers.
>
> Sure, but you don't have to do it in the most straightforward way. You
> can multiply once, and then add 2p for each hash. The overhead for a
> GPU / FPGA implementation should be negligible, and the search can be
> parallelized as well.
Maybe. But note that the public exponent is stored at the end of the
public key blob, so updating the exponent (or a piece of it) also
makes generating each hash easier.
> If adding large multiples of p, the nodes can be
> untrusted, too, I guess.
No -- the Euclidean algorithm would break that *very* quickly.
Robert Ransom
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Choosing a name for a .onon
On 2012-03-30, Asheesh Laroia wrote: > As the author of that asheesh.org note, I suggest you read it carefully. > (-: After reading that note four times, I still see no details about your attack tool. > In particular, pay attention to how key timestamps are used in OpenPGP! > It's interesting and was surprising to me at first, too. Your note does not contain the word “timestamp”. According to RFC 4880, the key generation timestamp is near the beginning of the key blob. Thus, every time you change the timestamp, you need to re-hash a relatively long fixed string (the public modulus in an RSA key, or the group parameters in a DLP-based key). Changing the timestamp may be useful for DSA or ElGamal keys (I'm not convinced of that), but it's not helpful in generating an RSA key with chosen key ID. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Absence of digital signature of TBB sources
On 2012-04-04, James Brown wrote: > Hello, > > Very sorry for creating a new topic, but that issue still don't resolve. > As I wrote earlier ( > https://lists.torproject.org/pipermail/tor-talk/2012-March/023755.html ) > there is no digital signature of the latest sources code of the TBB. The Git tag is signed. The official TBBs are built from the sources in Git, not from the tarballs. There probably shouldn't be any release tarballs for TBB source code. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor build failed - can't find libevent..
On 2012-04-04, Airosoβicz fb. wrote: > Hello everyone, > > I go by the name of Air0s & this is my first post to the list so pls bear > with me.. > I've got a problem building Tor from source which has to do with libevent.. > # pkg_version -v | grep libevent >>>> libevent2-2.0.16 Oh, you're using FreeBSD. Their goofy libevent2 port screws everything up. Build Tor using the security/tor-devel port. If you insist on not using the port, you need to run: export CFLAGS=-I/usr/local/include/event2 export LDFLAGS=-L/usr/local/lib/event2 before compiling Tor. But if you couldn't figure that out on your own, you really *really* should be using the FreeBSD port for Tor. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] TBB installation script doesn't work
Please open a Trac ticket for this. (Also, this is a problem with the TBB build scripts; TBB doesn't have an installation script.) Robert Ransom On 2012-04-05, James Brown wrote: >>> make -f linux.mk build-all-binaries >> /scratchbox/tools/bin/wget --no-check-certificate >> --directory-prefix=/srv/build-trees/build-alpha >> ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng-1.5.9.tar.bz2 >> --2012-04-05 22:37:00-- >> ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng-1.5.9.tar.bz2 >>=> `/srv/build-trees/build-alpha/libpng-1.5.9.tar.bz2' >> Resolving ftp.simplesystems.org (ftp.simplesystems.org)... 65.66.246.92 >> Connecting to ftp.simplesystems.org >> (ftp.simplesystems.org)|65.66.246.92|:21... connected. >> Logging in as anonymous ... Logged in! >> ==> SYST ... done.==> PWD ... done. >> ==> TYPE I ... done. ==> CWD (1) /pub/libpng/png/src ... done. >> ==> SIZE libpng-1.5.9.tar.bz2 ... done. >> ==> PASV ... done.==> RETR libpng-1.5.9.tar.bz2 ... >> No such file `libpng-1.5.9.tar.bz2'. >> >> make: *** [/srv/build-trees/build-alpha/libpng-1.5.9.tar.bz2] Error 8 > > > `wget --no-check-certificate > --directory-prefix=/srv/build-trees/build-alpha > ftp://ftp.simplesystems.org/pub/libpng/png/src/libpng-1.5.9.tar.bz2` has > as result the same error. > ___ > 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
Re: [tor-talk] wget - secure?
On 2012-04-18, Maxim Kammerer wrote: > TL;DR: wget is 100% safe to use with Tor and it does not leak DNS > (also true for curl, by the way). Which version of wget did you audit? What information leaks did you check for during your audit? Which SSL library did you configure wget to use? Which version of that SSL library did you audit? Based on your knowledge of the protocols that wget supports, where did you most expect to find information leaks in wget's source? (Since you claim that ‘wget is 100% safe to use with Tor’, clearly you didn't find any information leaks.) Which configuration of wget makes it use Tor ‘100% safe’ly? Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] wget - secure?
On 2012-04-18, Joseph Lorenzo Hall wrote: > The underlying point is that it would be neat if > you've done a comprehensive analysis of a specific version of Tor, > etc., etc. No, the underlying point is that I have personally seen wget send my computer's IP address over Tor in an FTP PORT command. wget is not ‘100% safe’. The code to send a PORT command is still present in wget 1.13.4. wget 1.13.4 is not ‘100% safe’; anyone who wants to recommend it needs to specify a particular configuration of wget which is safe. (Don't count on a ‘default configuration’; Linux distributors might have messed with it, or failed to update it to the version shipped in recent wget source distributions.) And that's not even the potential information leak that folks who are familiar with ‘anonymous FTP’ would check for first. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Problem with ttdnsd-665a534 on Ubuntu 12.04 server
On 2012-04-29, Gitano wrote: > ttdnsd-665a534 does not compile on my server Ubuntu 12.04 > (kernel 3.2.0-24-generic #37-Ubuntu): > > ### > root@server:~/ttdnsd-665a534# make install > /usr/bin/gcc -g -O2 -D_FORTIFY_SOURCE=2 -fstack-protector-all -fwrapv > -fPIE --param ssp-buffer-size=1 -Wall -fno-strict-aliasing -W > -Wfloat-equal -Wundef -Wpointer-arith -Wstrict-prototypes > -Wmissing-prototypes -Wwrite-strings -Wredundant-decls -Wchar-subscripts > -Wcomment -Wformat=2 -Wwrite-strings -Wmissing-declarations > -Wredundant-decls -Wnested-externs -Wbad-function-cast -Wswitch-enum > -Winit-self -Wmissing-field-initializers -Wdeclaration-after-statement > -Wold-style-definition -Waddress -Wmissing-noreturn -Wnormalized=id > -Woverride-init -Wstrict-overflow=1 -Wextra -Warray-bounds > -Wstack-protector -Wformat -Wformat-security -Wpointer-sign -Werror > ttdnsd.c -o ttdnsd -ltsocks -L/usr/lib > ttdnsd.c:12:19: schwerwiegender Fehler: stdio.h: Datei oder Verzeichnis > nicht gefunden > Kompilierung beendet. > make: *** [all] Error 1 > ### > > What am I missing? On Ubuntu 10.04 desktop it works very well. Looks like it's saying “stdio.h: File not found". (It would be easier for English-speakers to help you if you ran “export LC_ALL=C” in your terminal before compiling a program, to tell compilers to use the POSIX standard ‘locale’.) ‘sudo apt-get install build-essential’ might help. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Firefox security bug (proxy-bypass) in current TBBs
See https://blog.torproject.org/blog/firefox-security-bug-proxy-bypass-current-tbbs for the security advisory. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] can't enable SSL with IRSSI over TOR
On 5/6/12, Shane wrote: > I hope this is the right list for this. I am trying to get setup to > freenode and have irssi sasl'd over tor, but I can't seem to get this > enabled with SSL. I've tried using torsocks and socat. Does Freenode's hidden service support SSL? Does it support SSL on port 6697? Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] TBB lags behind as Firefox ESR 10.0.6 is released
On 7/21/12, Roger Dingledine wrote: > On Sat, Jul 21, 2012 at 08:09:42AM +0200, machine wrote: >> https://www.mozilla.org/en-US/firefox/organizations/all.html >> >> but there hasn't been any update yet for The Tor Browser Bundle, which >> has a Tor Browser version of 10.0.5. > > Yep. I believe TBB 2.2.37-2 is still in the QA process on our side. * Firefox 10.0.6 is a security-fix-only release. Why is Erinn putting it through a QA process? * What classes of problems can the QA process detect? Are these problems more severe or less severe than arbitrary remote code execution? * How long will you wait for the QA process before making this security-fix release available to users? * How long will you wait before removing the current stable release from the list of ‘recommended versions’ of TBB? Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Problem with new multiple-instance exit nodes never showing up in directory (cached consensus)
On 7/26/12, Name Withheld wrote: > > Hi guys, > > I've got a 1gbps (shared) debian server set up as an exit that can't > seem to handle all the b/w through a single instance of tor. After > getting some help from the tor lists previously, I've started setting up > additional instances of tor that run simultaneously to help handle more > traffic. > > Unfortunately, only the first of the extra instances works (even though > I copied the config from the "known good" config and only changed the > ports during other attempts). Other instances seem to work at first, > setting up the initial tunnels and passing very small amounts of traffic > for about a half hour, but never seem to get listed in the directory, so > they never get any other traffic once the initial tunnels all close, > even after many hours pass. > > Does anyone know why this is happening, and what I need to do to fix it? >From <https://www.torproject.org/docs/tor-manual-dev>: > AuthDirMaxServersPerAddr NUM > > Authoritative directories only. The maximum number of servers that we will > list as acceptable on a single IP address. Set this to "0" for "no limit". > (Default: 2) The dirauth operators all have this option unspecified (or set to 2). To fix this, either (a) persuade the dirauth operators to increase this value or (b) get more IP addresses and run at most two relays on each of them. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Problem with new multiple-instance exit nodes never showing up in directory (cached consensus)
On 7/26/12, Name Withheld wrote: > Thank you for the response. I'm assuming you're implying option A) (get > the dirauth operators to increase the value) is not actually serious. > Please correct me if I'm wrong (because I see know way of going about > this). It's not the easiest option, but it is possible. If you can make a convincing argument that whichever value you want them to set is still low enough to not make serious attacks significantly easier, or that raising the limit will let a significant amount of ‘good’ relay capacity enter the network, the limit will probably be raised. It might be even easier to persuade ‘enough’ dirauth operators to try raising the limit and see whether the result is ‘good’ or ‘bad’ in various ways; if nothing especially bad happens after a week or two, they'll probably change the default limit. > For B), this is probably a total newbie question, since I've never had to > run a program like this before. If I can get a second IP from the ISP for > the same physical server, is there a configuration option in Debian (or > something in the torrc file) I'll need to set to get it to the additional > tor daemons binding to the secondary address? I have no idea how to configure your OS to allow you to use a second IP address. That sounds like a common task, though, so there must be instructions for it somewhere. To configure Tor to listen on a specific IP address: Use Tor 0.2.3.x on the relay, specify an IP address on your ORPort torrc line, and if Tor refuses to start, read and act on its log messages. (Bonus points for reading the log messages yourself instead of pasting them into e-mail or IRC and waiting for someone else to echo them back to you.) You might need to specify an IP address explicitly for all of the relays (even the ones you want to listen on your server's default IP address); being explicit about that certainly won't hurt anything on a server with static IP addresses. I recommend continuing to use a different ORPort for each Tor instance, since some/many/most censoring firewalls censor connections with different server ports in different ways. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] ControlPortWriteToFile line added to torrc by Vidalia after TBB reload = bug?
On 8/5/12, Tomás Touceda wrote: > Hi, > > On 8/4/12 4:54 PM, m...@tormail.org wrote: >> Since the last version and continuing with the current version of Linux >> TBB 32bit, there is an >> extra line added to torrc on TBB reload, by Vidalia, with steps to >> reproduce: >> >> * Directory: >> ~/tor-browser_en-US/Data/Tor >> >> * Extra Line of Data Added: >> ControlPortWriteToFile >> /home/madeinchina/tor-browser_en-US/Data/Tor/port.conf >> Is this a bug? > > Only if it breaks something or if it conflicts with something. It is a bug (filed as https://bugs.torproject.org/6568), because it writes information about a filesystem location from which that copy of TBB was run. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
