Re: [tor-talk] 100-Foot Overview on Tor
On 6 May 2015 at 07:55, David Goulet dgou...@ev0ke.net wrote: On 06 May (19:28:38), teor wrote: Page 20: Can you explain why you say that consensuses are valid for 24 hours, and not 3 hours? Indeed, according to dir-spec.txt, see section 1.4 Voting timeline, there is an explanation. The current tor code actually randomize some of those values to be in a specific range that is not more than 3 hours (iirc). I believe that most places actually use the below function however: https://gitweb.torproject.org/tor.git/tree/src/or/networkstatus.c#n1041 When I was talking with many of the DirAuths in Valencia, they said that a 24-hour outage was necessary for the consensus to be well and truly out of date. I pointed out that wasn't what the consensus said, but they insisted, and then I found this code. Page 113: I think there are 3 relays between the client and introduction point, not 2. In new_route_len(), each circuit with an endpoint chosen by another relay gets an extra hop, and the hidden service chooses the introduction point, not the client. I could be wrong about this - the path code has a few special cases that I haven't quite got my head around. Yes you are right. Not only that but if the first introduction point fails (client side), the circuit is re-extended to the second intro point and so on until it works or the the maximum limit of 7 hops is reached. That's maybe a bit too deep to explain in the slides so I guess 4 hops Client - Intro is good enough. :) Yea, the extension quirk I think is a bit much, but I fixed the number of hops - now that I think about it closer, 3 makes more sense. On 9 May 2015 at 12:35, grarpamp grarp...@gmail.com wrote: On Tue, May 5, 2015 at 7:49 PM, Tom Ritter t...@ritter.vg wrote: It's (now) http://creativecommons.org/licenses/by-sa/4.0/ I looked but don't yet see that noted in the first or last slides. It would need to be editable for people to incorporate and tune the text to their audience. Images and pdf format are not text. I'd just post the source and pdf on your site for people to find. Fixed, and redirects updated. -tom -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] 100-Foot Overview on Tor
On 5 May 2015 at 07:53, Fabian Keil freebsd-lis...@fabiankeil.de wrote: Great. A couple of comments (about v1.3): Thanks! I made the changes and put up a 1.4 Page 141 and 142 seem to suggest that parsing strings is more likely to be vulnerable than parsing binary data. Is that intended? No but mostly yes. It's more a surprise factor: when I tell people tor uses HTTP to upload and download things, they're not surprised - when I tell them it has its own HTTP server implementation that does all the parsing of the requests, they're much more surprised. I'm not saying tor's code is insecure (I put up a $bounty inside my company with my own money to anyone who finds a bug in it actually) - but implementing your own HTTP server is not a recommended action. :) Is the source of the PDF available under a free license? I'm currently preparing a (German) presentation about location hidden block storage and could reuse the HS-related parts: http://chaos.cologne/Fahrplan/events/6653.html It's (now) http://creativecommons.org/licenses/by-sa/4.0/ As far as the sources well, I made it in keynote. Yes, I know I'm a bad person. I can export it as powerpoint, html, images, or pdf and send you any one of those five. (Or all of them.) -tom -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] 100-Foot Overview on Tor
Hi all, I've put together a slide deck that aims to provide a 100-foot overview on little-t tor and Tor Browser. 100 foot, meaning I go into a lot of technical detail, but not 10 or 1 foot which means some things are definitely glossed over or handwaved a little. My consistency with the 'foot level' throughout the deck varies a bit, but I think it's decent. Before I post it on twitter or a blog, I wanted to sent it around semi-publicly to collect any feedback people think is useful. In particular: - Upcoming Improvements worth mentioning (I'm a little light on the Hidden Services 2.0, but that's proposal is big) - Interesting 'hidden depths' worth shedding a little light on - Particularly good resources for a specific topic (I'm trying to avoid linking too much, but some is good) - Anything factually wrong of course Slides are at: https://ritter.vg/p/tor-v1.2.pdf Yes - it is long. There's a lot to tor these days :) -tom -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Platform diversity in Tor network [was: OpenBSD doc/TUNING]
On 5 November 2014 03:04, grarpamp grarp...@gmail.com wrote: On Tue, Nov 4, 2014 at 12:25 PM, Libertas liber...@mykolab.com wrote: I think it would be a good idea to add OpenBSD to doc/TUNING because [...] promoting OpenBSD relays benefits the Tor network's security. Absolutely. Not just due to OpenBSD's security positioning, but moreso from network diversity. Windows is its own world. I tried installing OpenBSD once... it was tough, heh. Coming from a Windows background, I like the idea of running more nodes on (up-to-date, maintained) Windows servers. I'll also throw out the obvious that if we're talking about diversity for the purposes of security, the network-accessible parts of tor rely on OpenSSL, which would probably be difficult to swap out, but might be worth it as an experiment. Even if it's to LibreSSL. Maybe the zlib library also, but that one's had a lot fewer problems than OpenSSL. -tom -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Krypton Anonymous: A Chromium Tor Browser
On 3 November 2014 17:05, Mike Perry mikepe...@torproject.org wrote: I also have an OpenWRT configuration I can give you to monitor for proxy leaks on an upstream router, but you need to be able to configure Tor Bridges to make use of it. Same idea, but I use a full linux machine as a router rather than an OpenWRT router. https://github.com/iSECPartners/LibTech-Auditing-Cheatsheet#appendix-a-examining-an-application-for-proxy-leaks You can also set up a linux box as a VPN server (not a router), and connect your phone to that VPN, and do the logging there. Both require you to configure tor to use a bridge though. -tom -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor relay activity from Antarctica
On 28 August 2013 12:29, lee colleton l...@colleton.net wrote: There is an indication that computers are connecting to the Tor anonymizing proxy network from Antarctica. This information is anonymously self-reported by the connecting client computers and it's entirely possible that the locations are inaccurate. However, there is also a possibility that malicious software has been installed on computers in one of your research stations which is using the Tor network for command-and-control purposes, unbeknownst to the owners. I would encourage you to investigate this matter. Is there any reason you suspect that Tor is being used maliciously, and that it's not likely someone on the research station is interested in protecting their privacy or anonymity? (Although if it's the latter, they'd probably not be doing too good =P) Seeing as it's likely the research stations are supplied internet through government connections, I'd be interested in using Tor if I were on such a station... -tom -- tor-talk mailing list - tor-talk@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How to designate specific node as exit node
On 13 August 2013 05:48, Hyoseok Lee zeusy...@gmail.com wrote: In Tor network Is it possible to make specific node as exit node? The ExitNodes configuration parameter. https://www.torproject.org/docs/tor-manual.html.en The standard caveat applies: messing with Path Selection in this way is likely to decrease, not increase, your security and anonymity. -tom -- tor-talk mailing list - tor-talk@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] HS drop
Hey grarpamp, You may have explained this elsewhere, but if so I missed it (potentially while on an internet moratorium for the past week) - how are you observing these statistics? Thanks, -tom -- tor-talk mailing list - tor-talk@lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] NSA, Tempora, PRISM And Company always know who is behind Tor?
On 19 July 2013 06:35, Ed Fletcher e...@fletcher.ca wrote: On a related note, does having (what I assume is) a serious percentage of the Tor relays in the Amazon cloud make it easier for the NSA to compromise anonymity? I don't think a 'series percentage' of relays are in EC2. I would politely ask you to research that and prove me wrong if you feel strongly about it. There might be a serious percentage of bridges, but even that is questionable. (Related: Runa is giving a talk at Defcon on the Diversity of the Tor Network, so hopefully that will be a canonical answer to these sorts of questions once her slides go up in a couple weeks.) Regarding their ability to monitor EC2 - well it depends on what datacenter. The bulk of EC2 is in the Virginia one - and yea the NSA probably has a line on that one or it's upstream ;) But what about the one in Singapore? /shrug -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Will Tor affect Internet Explorer? (newbie question)
On Jul 11, 2013 11:41 PM, cl34r an0n102...@riseup.net wrote: On 07/11/2013 11:24 PM, Gabrielle DiFonzo wrote: Hi there, Hi I am currently running Windows 7 and my usual browser is Internet Explorer. If I download Tor, will I still be able to use Internet Explorer when I want to? You can configure Tor to with any browser. However, by doing this you are compromising anonymity. Will continuing to use IE compromise my Tor privacy? Yes. The best solution is to download Torbrowser from the Torproject website, or Tails at https://tails.boum.org. Not only do either of these solutions work out of the box (in most cases), they also preserve anonymity. Will Tor affect my other programs in any way? Not unless you configure them to use Tor. Actually, to use Tor with IE, you have to set the system-wide proxy, which will affect the operating system and other applications. I don't know anyone who's ever looked at what will be sent through that, but I do know it will be a lot. (Windows update traffic for example) For this reason, and others, I would really recommend against using IE with Tor. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Plans about Askbot?
On Jun 17, 2013 5:41 PM, Lunar lu...@torproject.org wrote: Runa A. Sandvik: On Mon, Jun 17, 2013 at 3:09 PM, Lunar lu...@torproject.org wrote: One of the concern that was raised by Moritz is export capabilities of Stack Exchange. How likely are we to switch to a self-hosted application if it means losing data that had taken a lot of energy to assemble in the first place? Who said we will lose data? AskBot supports importing data from Stack Exchange (I have not tested it myself, so I don't know how much work it requires): http://askbot.org/doc/import-data.html Moritz mentioned that we would not be able to migrate user/reputation. As such QA websites have an important social component (karma, badges, and so on), volunteers who would have invested time and energy to build a good reputation could be turned away by loosing all their stats overnight. Overall, I am not afrad of the import part: AskBot is free software. It's getting data out of Stack Exchange that I am wondering about. Looks like at least most data (except user logins, emails and passwords) could be retrieved through http://data.stackexchange.com/, but it looks a bit tedious to get a full export. Also, given there's a CAPTCHA, I am not sure backups could be automated. Did they stop doing the database dumps? -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Plans about Askbot?
Not that, this: http://www.clearbits.net/feeds/creator/146-stack-overflow-data-dump.rss It's torrent of all the data, made every 3 months, in a machine readable format. Frankly, the StackExchange folks are pretty good about this, if they didn't make the data available in that sort of dump, containing all the data up until the last day, after they shuttered a site, I would consider them as having COMPLETELY violated the principles the site was founded on, and would go over to their office (they're in NYC) and see if I could plead with them into giving it to me on a thumbdrive. -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] What are some good VPS providers for Tor?
On 27 May 2013 20:52, Nathan Suchy theusernameiwantista...@gmail.comwrote: Hi Everyone, I looking for a good VPS provider in the United States for hosting a Tor Exit Node. I am considerog linode. My price range is up to $20/month. I would like the exit node to have power servers and very faster bandwidth (unlimted is a plus). I would prefer to avoid Amazon/Rackspace. Most lower end VPS (which tend to go up to $20/mo) do not allow exit nodes. Linode does not. Sometimes you can get away with running one on them for a few months, but they usually shut you down from the abuse emails. I got shut down after 10 months on a VPS that explicitly did allow exit nodes when I asked them about it before I purchased. Generally speaking, the more Tor nodes are in a single location (single VPS provider or single datacenter), the worse it is for the network, as it decreases diversity and increases single points of failure. If you cannot find a VPS you can afford to run an exit node on, consider running a bridge or a relay node on a VPS that (you think) other people aren't also using. Sorry there's no easy answer, -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] What are some good VPS providers for Tor?
On 28 May 2013 14:41, Nathan Suchy theusernameiwantista...@gmail.comwrote: Would running a bridge on Amazon be a bad idea? I could afford that. I know of an offshore provider that loves privacy projects. They only cost £10 a month. It's a supported mechanism: https://cloud.torproject.org/ The Torcloud images run Obfs Bridges, so it's better to run one of those than roll your own. -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Anonymity of Leaking Servers (Was Re: [tor-dev] Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization)
On 27 May 2013 14:39, Micah Lee micahf...@riseup.net wrote: Would it be fair to say that using the techniques published in this paper an attacker can deanonymize a hidden service? ...but for the time being the anonymity of the document upload server isn't one of them. Switching to tor-talk. Is that important for Strongbox? I don't think Strongbox's threat model needs the document upload server to *be* anonymous. Strongbox is run by the New Yorker. If you want to find their upload server, just look at all the IP ranges the New Yorker leases. Or subpoena them, or serve them with a warrant. If you were talking about Wikileaks, I might agree - it might be important for them for their servers to be anonymous. But then again, it apparently *wasn't* because IIRC they never ran a document upload service soley on a HS. (They may have run one, but everything was also available on the general 'net, again, IIRC). I think for all (or most?) of the document leaking services we've seen so far, the anonymity of the server isn't terribly important, it's the security anonymity of the sender that must be preserved at all costs. In that regard, HS are still good, because as you said sources are forced to use Tor, [with] end-to-end crypto without relying on CAs. -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] You could use ModX to create .onion sites,
On 24 May 2013 02:36, Andreas Krey a.k...@gmx.de wrote: Can hidden services talk SPDY? Sure they can. Just as well as ssh, smtp or pop3 or anything else that goes over TCP. I guess I should have phrased this as Can TBB talk to a SPDY enabled HS? or Can users take advtange of a HS running SPDY? I think TBB would need to make special provisions. SPDY requires SSL, if you use the weird Use SPDY over plaintext option[0] it breaks HTTP. So if someone without a SPDY client visited x.onion, it'd break. A HS can redirect to a SSL version it itself, but the certificate won't validate, at least according to normal PKIX validation rules, because no one can issue a cert for a .onion. ... Actually that's not true. I could have bought a certificate for a .onion address, any .onion address, from any CA until the end of 2015. They're starting to phase them out now so any CA is probably not correct some some CAs would be true. That's a mildly creepy thought, although the HS architecture should protect against that. (Unless you've broken RSA1024) I suppose it would be possible for TBB to talk to a HS over SSL, and attempt to negotiate an anonymous, non-confidential ciphersuite (to reduce the CPU needed) or make other provisions to accommodate it, like ignore PKIX validation and showing no security indicators. -tom [0]https://code.google.com/p/mod-spdy/wiki/ConfigOptions#Debugging_SPDY_without_SSL ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] You could use ModX to create .onion sites,
On 24 May 2013 09:25, Andreas Krey a.k...@gmx.de wrote: On Fri, 24 May 2013 07:22:28 +, Tom Ritter wrote: ... ... Actually that's not true. I could have bought a certificate for a .onion address, any .onion address, from any CA until the end of 2015. How that? .onion is not a real TLD. CAs can (or could, they're phasing them out now in anticipation of the new gTLDs) issue publicly trusted certs for domains that are not publicly routable. Usually this is for stuff like mailserver.corp or redmine.internal or sharepoint.dell for use inside corporate networks. But there's no reason they couldn't do .onion They're starting to phase them out now so any CA is probably not correct some some CAs would be true. That's a mildly creepy thought, although the HS architecture should protect against that. Hmm. Actually, we already have a kind of certificate - the HS itself. What point does certificate verification serve in https to onion site at all? It wouldn't serve a security purpose, as far as I can devise. It would just be for not annoying the user with a Invalid Cert warning, when in fact HS are secure regardless of SSL cert presented. Would it be possible to put the server's HS cert keys into the the SSL negotiation as well and have the browser either verify that the public key matches the HS name, or not verify at all? (And take a null cyphersuite as well?) Sure, but at that point you're talking about altering the SSL stacks of the client and possibly server. Mike and I were brainstorming ideas that would require fewer engineering changes. -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tragedy of the commons.
On 24 May 2013 15:36, Chris Patti cpa...@gmail.com wrote: I understood the legal implications. See my above note about the abuse report from Linode. I'm not complaining, just noting that it's unfortunate that folks have to abuse things. In my opinion the tragedy here is not that people abuse Tor, because everything will be abused. It's that providers will allow themselves to be bullied, and then bully others, when behavior falls into the bucket of legal, but annoying. If they SWIPed the IP, this could be averted easily, and remove Linode from having to deal with the complaints at all, but they won't do that either. -tom (who also uses Linode for his server, but runs it as a middleman) ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] You could use ModX to create .onion sites,
On 23 May 2013 16:27, Nathan Suchy theusernameiwantista...@gmail.com wrote: The hidden service protocol needs major modifications as it is very slow. I actually don't use hidden services but see the use in them and think that the hidden services need a better protocol... Can hidden services talk SPDY? The resource push features of SPDY might be a hugely tremendous boone, without requiring re-architecture web apps. -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] memory cached pages should reload instantly-but DON'T
Hm, that's an tough question. TBB doesn't modify the FF code very much at all, and the patches are pretty lightweight - they're all listed here: https://gitweb.torproject.org/torbrowser.git/tree/HEAD:/src/current-patches/firefox although some of them do deal with caching. The about:config settings are all listed here (AFAIK): https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config/pound_tor.js so I wonder if there's anything in there you might recognize as causing a problem? I'm afraid I'm not quite sure that the issue could be, these types of bugs are pretty tricky to track down. I did want to point you in the right direction for maybe finding the culprit though. -tom. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Is using player like VLC safe alternative to Flash?
VLC has a lot of stuff going on inside of it. I would not be surprised if there were proxy leaks that might be able to be forced by someone doing something tricky. Say you enter a url to a flash video and the content is intercepted and replaced with an RTSP stream that VLC somehow interprets, and due to a quirk of RTSP makes a request to a third party domain that isn't proxied? I have no idea if that's possible, but I wanted to give some strange example of something VLC supports that might have a proxy leak in some obscure component. Likewise, when discussing security vulnerabilities... VLC doesn't have the best track record. (See https://www.videolan.org/security/ ). I'm a big fan of VLC, but I put it in the same category as Pidgin when it comes to how far do I trust this program to not have bugs? I would love to see someone do an objective test of VLC as opposed to my subjective hand-waving, but I'm not aware of one. -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] HTML5 video and Tor anonymity.
On 1 May 2013 15:29, David Vorick david.vor...@gmail.com wrote: I don't know what I'm talking about, but here goes: If you were to put flash in a sandbox that had a fake IP address, might that make the sandbox incompatible with the tor network? When you are communicating, even over the tor network, your IP address is critical so that servers on the other end know where to send messages. That means that at the very least you have to know your own IP address. If the flash sandbox had a false address, the network might reject communication altogether, or it might simply be unable to return the messages to the right spot. Am I incorrect? Well, when anyone from outside the Tor project talks about sandboxing flash, they're talking about restricting the system calls it can make, restricting it from touching files on disk, spawning processes - real sandbox stuff. That's what Mozilla is after with Shumway. That's what Chrome is/was after with their sandbox. Tor is afraid of Flash for three reasons as I see it: it's buggy (see my previous sentence), it can read your IP address, and (I believe) it can or can be made to make requests that circumvent a configured proxy that would leak your external IP to whatever you connect to (assumed to be an attacker). And when I say proxy, you can read Tor. If Flash is running on a machine with a RFC1918 IP (192.168.x.x, 10.x.x.x, etc) then knowing the IP doesn't help. But it can still make a proxy-circumventing request. Putting Flash in a VM and restricting the VM from making any request except through the proxy (or routing all requests through the proxy) alleviates that concern. -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] FlashProxy and HTTPS
I finally watched the recent FlashProxy talk, and the bit about Not working on HTTPS intrigued me. I looked into it, and had two initial ideas. == Mixed Content. This isn't great, but it's something that might work for now. Chrome and FF do not block an HTTP iframe on an HTTPS site. Chrome26 displays a different icon, and logs to console. Chrome Canary (28) did the same FF9.0.2 allows and has no indication IE9 blocks So putting the badge on a page in an iframe could allow a webmaster to deploy it on a HTTPS site. That frame would be on a different domain, to get protections via Same Origin Policy == Root Cert. This one is more than a bit crazy, but I don't believe in discounting crazy out of hand. Basically, if you accept that the TLS connection provides *no security whatsoever*, that is - it does not provide authenticity, and therefore should not be assumed to provide confidentiality - but you want to use it as an opportunistic layer (hey maybe this will help, it can't hurt), or to enable it working on HTTPS sites, or as an anti-fingerprinting tool (now they have to look at the handshake/certificate instead of te traffic) it becomes acceptable. Create a FlashProxy Root Cert, with a critical NameConstraint extension. The Name Constraint would be something like .entire-internet.flashproxy.com. Because it's Name Constrained, and critical, no client will accept a cert for a domain like paypal.com chaining to your root. IIRC the only desktop client that does not support NameConstraints is Safari - BUT because it's critical, Safari will outright reject the certificate. Mobile Clients should behave the same way. A group of CA's and Browser vendors are working to document the veracity of those claims, but I'm pretty confident in them because they recently, to great consternation of the IETF, said we're going to allow non-critical NameConstraint extensions, because if we don't, we'd break Safari. So you've got the root cert. Folks who want to run FlashProxies install it in their browser or OS. (The NameConstraints give them confidence you're not going to, nor can you, mess with them.) Now when a client wants to have a FlashProxy connect to them, they talk to the facilitator or another facilitator like system, and they receive a Root-CA signed cert for 127.0.0.1.entire-internet.flashproxy.com (substitute 127.0.0.1 for the client's actual IP) that's valid for a short window, say 30 minutes. Now, when the FlashProxy connects to the client, they do so using wss:// and receive the FlashProxy Root-signed certificate, and the browser lets the SSL handshake succeed. There's a lot of downsides here: - NameConstraints are not rock-solid in the sense that we've taken them for long test drives, but no one's subjected them to 20 years of continual use. When the value of the system attacked is greater than the cost, the attack happens. What's the cost for an attack on Name Constraints? We don't know. - It requires the FlashProxy user to install a root cert (e.g. do more than just open a webpage) - The requirements for the client - facilitator communication channel go up: it must now be bi-directional and support up to 1K of data or so. - The signing of certificates would introduce a DOS channel. This can be mitigated in some sense by rejecting requests for an IP if you've signed a cert for that IP in the last validity_window / 2, and preventing the IPfrom being spoofed (free if done over TCP, difficult otherwise) -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Mail services: Hotmail / Live, Outlook
On 15 March 2013 18:34, Joe Btfsplk joebtfs...@gmx.com wrote: Don't know if this will always work, for all providers, but I have set torrc to use only exit nodes in my country I don't think this should be a recommended practice, because (while you are in that country) it explicitly enables your government to perform a traffic confirmation attack against you. Unless you meant you did this while you were traveling, in which case that's different. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Mail services: Hotmail / Live, Outlook
On 16 March 2013 13:54, Joe Btfsplk joebtfs...@gmx.com wrote: I think Gmail may do same thing, if try to login w/ exit node from a different country than used to sign up for the acct (not sure). According to the guy at Google who has posted here before, they require you to verify yourself (e.g. via your alternate email or phone) on the first login from an anonymous proxy service, after that they flag your account so they don't bother you again. I haven't test the limits or implementation of this. -tom. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] On the Theory of Remailers
On 9 January 2013 10:05, Alexandre Guillioud guillioud.alexan...@gmail.com wrote: Hi all, I'm reading your conversation, and i'm not understanding very well what you mean by high/low latency network. Isn't it just a ping duration delta ? You speak about low and high latency like it's a feature. Is tor mixing only low latency with low latency in its circuits ? Opening for a dispatching of services (ie. mail on high latency, web on low ) ? What's the point ? Someone can probably explain it better by putting more time into it, but the gist of it is how long a mix node will 'hold onto' a message, before sending it on. (Effectively 'mixing' it.) From the blog articles: A 'Low Latency' mix network means as soon as a node receives a packet, it sends it out. A 'High Latency' mix network means a node will hold onto a message for some amount of time before sending it out. Traffic Analysis is a huge part of mix network design. If an attacker is watching the network (and we generally assume they are) - how much information do they gain by watching packet paths, sizes, and times, and how easy is it? If you see a network flow from Alice to Bob, and Bob to Charlie - those flows will probably be matchable. With regard to defending against Traffic Analysis, High Latency is preferable - being able to hold onto a packet for any length of time before sending it on gives you lot more options. Tor is a 'Low Latency' mix network - it has no choice because it's infeasible to browse the Internet with minute-long (or longer) delays during page loads. However, email can have delays - if an email doesn't arrive for 30 minutes or an hour, it's generally not a problem. So Remailers can afford to be a High Latency mix network. They will accumulate a number of messages in a pool, and then when the pool is a certain size, will send the messages out. There are multiple algorithms for pooling, and we'll go into more detail about them and pool attacks later. As a mix node, if I accumulate 8 same-size messages, and then send them all out at once to 8 recipients, you can't use traffic analysis to see who I sent which message out to - because they're indistinguishable. That's high latency. But if I had sent out each message as soon as I got it, you could see which message went to each recipient - that's low latency. -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] On the Theory of Remailers
On 9 January 2013 10:33, Alexandre Guillioud guillioud.alexan...@gmail.com wrote: Wooo thank's Tom ! First time using mailing lists, i'm going to like it :D (and it's not a problem to answer from work :DD). Ok, so i understand what you're meaning by high/low latency network. Just, why don't apply this to web browsing ? Can't each node keep packet up to 5 seconde based on random ? 5 second isn't a problem, as tor network is already long to serve pages/packets. From my point of view, you can't allow some sort of different latency paths for clients. It will confuse basics users, And power users will tweak this to allow only low latency circuits. Allowing a client to choose their 'delay' and combining low and high latency networks is (as I understand it) the basis behind Alpha Mixing [0]. As far as a 5 second window in Tor nodes - off the top of my head, I'm not sure 5 seconds would really gain anything. If the nodes you're using (.e.g bridges) aren't used much, 5 seconds doesn't help you. On the other hand, adding 30 seconds (3 hops, 2 directions) to *each* request, keeping in mind a page maybe have 20 requests quickly makes web browsing near-unusuable. The other elephant in the room is that *even with* high latency, given *enough* traffic, you can always link it statistically. Think of it this way: If I'm sending a packet a day to a recipient, you can see a packet a second leave my machine, and a packet a day received at the other end. Even if my message is mixed well, held for an hour and mixed with other messages - it's not hard after a few days to realize the correlation. High latency makes this harder, harder still if you don't have a regular pattern. If statistically it's still easy, even with a 5 second delay, what's the point in making the software harder to use if you're not getting the defense you seek? I'm not the authority on Tor's design decisions, but those are my thoughts. -tom [0] http://www.freehaven.net/doc/alpha-mixing/alpha-mixing.pdf ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] On the Theory of Remailers
On 8 January 2013 01:18, Moritz Bartl mor...@torservers.net wrote: On 08.01.2013 05:29, grarpamp wrote: It is an interesting questions, if with a modern user interface, can they get to new life? I see no reason the state of the art from the legacy remailer types can't be combined and updated into a new service running on some of the same relay machines we have for Tor today. In the end, both low and high latency anonymity should be handled by the same network. I believe this is the concept behind Alpha Mixing [0]. When I talked to Roger once, many moons ago, I recall he expressed the desire that one day, in an ideal world, Alpha Mixing would indeed be the main mixing of the network, to allow for transit of other types of things, like email. -tom [0] http://www.freehaven.net/doc/alpha-mixing/alpha-mixing.pdf ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] On the Theory of Remailers
I'm hoping this will be of interest to this list. To encourage interest in the waning art of remailers, I'm starting what I aim to be a long series on how they work, design choices, technical limitations, and attacks. The first five are now live at https://crypto.is/blog/ -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] On the Theory of Remailers
On 7 January 2013 15:53, David H. Lipman dlip...@verizon.net wrote: I hope you fully elaborate on how remailers are used for abuse. -- Dave I intend to, but I've never been the receiving end of remailer abuse, so I've only got academic knowledge. I had a few ideas I was brainstorming about this: 1) a shared, hashed list of emails to provide a 'global' opt-out of emails for all participating nodes 2) For plaintext mails, adding a spam filter on outgoing mails 3) some form of 'status' remailers could publish where a client could see that their email was either delivered, flagged as spam by a remailer's exit policy, or just never recieved. And advantage of 3 is that it helps with the reliability quesiton: did my message get delivered? A disadvantage is it requires a client to remember a GUID of a message that would tie the user to the message (very bad). That's all assuming you mean abuse from the perspective of the recipient, and not abuse form the perspective of the remailer operator. -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Status reports archive, blog and git?
On 19 December 2012 07:16, and...@torproject.is wrote: There's a larger plan forming to scrap the current blog and convert it to something like jekyll/hakyll with the content served from git. We'd like to do this for the entire website, too. The step holding up the blog migration is the ability to accept comments. Some of our bloggers really enjoy the comments. We don't really want to sign up with some Internet-wide commenting system like disqus or intensedebase due to privacy concerns over data collection. Until we have a some sort of a forum, we're holding off on the blog migration. It'd require some custom development, but it'd be possible to load comments via javascript - basically to build your own Disqus. I do something like this on my blog. It grabs the page name/path from the URL, and uses that as a key to fetch comments out of a database and display them on the page. Now the comments are stored elsewhere and the page in git has some boilerplate javascript to load the comments. You can even let uses markdown-style their comments. -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Browser protections
On 18 December 2012 17:52, nile...@hushmail.com wrote: Hello everyone. I have a small question. Does Tor Browser protect against IP/DNS leaks more than regular Firefox? If I change the network settings in regular Firefox to local proxy and then disable the Tor service, I cannot connect to the Internet, so it doesn't look like anything can leak unless there's a bug. I do realise that Tor Browser has many other ways that it protects my anonymity. But I would like to know about whether you think Firefox has not implemented SOCKS 5 support properly. Thanks. Niles. Yes. At least based on what I see here: https://gitweb.torproject.org/torbrowser.git/tree/HEAD:/src/current-patches/firefox and in particular here: https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/src/current-patches/firefox/0016-Prevent-WebSocket-DNS-leak.patch -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Synchro of database server over Tor
I'd design as much or all of the db-parts of the site to load over AJAX as possible, so you can put up a nice Loading... message. Keep a persistent connection to the database; don't connect for every client (pconnect in PHP). Maybe do a redundant design that aims for eventual consistency if you have to fallback to database B because you can't reach database A. Have your site have very robust failure handling for timeouts, data not read etc both client and server side. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Hidden services home hosting
On 12 November 2012 08:27, HardKor hardkor.i...@gmail.com wrote: Looks easy no ? Any way for Alice to mitigate such attacks ? Two nodes hosting the same .onion in diffrent locations ? Something else ? I think different operational practices would solve the problem. For example, Host the blog on a HS on a VPS outside the country. Or for something that costs nothing, Host the blog on blogger.com or wordpress, and connect to it over Tor, signing up using non personally identifiable information -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Can we come up with a lighter, easier torified client apps ?
On 4 October 2012 00:27, and...@torproject.is wrote: I think you would be the first to want this I don't know if I'd say that... I think TorBrowser could be improved by integrating Tor+Vidalia+Firefox into a single app. This may also go towards fixing the user confusion with having several windows running. Or imagine a VirtualBox where all network traffic from the VM was automatically sent over Tor.. because Tor was embedded in it's network emulation. Of course those are the huge, monolithic cases. Take simpler apps like gpg, ssh, putty, pidgin (god help us), git, svn. While tracking upstream would certainly be a problem, having a statically linked tor and a modified binary that sent everything over Tor I think would go a long way towards getting average users using Tor safely... without ever having to say the words Proxy or Socks to them. I guess the problems to overcome would be to figure out a way to track upstream easily and identifying use cases where people would really benefit from specific tools, to focus on those first. TorPidginOTR seems like it'd be a likely candidate... unless there's a non-libpurple OTR-enabled chat client. -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] new tld question
Other good news: no one registered for .onion, and it's going to be several years until the next round of applications open. Hopefully by then, the process will be much smoother than this time around. It's possible that next time around, Tor could apply for .onion, and use it as a tor2web portal - but even if a lot of engineering effort was put in[0] - a user visiting aabbccddee.onion in a normal web browser would leak its DNS request, and an observer would know exactly who they were trying to browse to. That's not an issue with tor2web mode, because it's only the HS, not the user, trying to be anonymous. But trying to keep the user anonymous when visiting a .onion would be extremely difficult, if not impossible. But then again, on the flip side, if a user visits aabbccddee.onion without using either a Tor DNs Proxy or TBB, that .onion DNS request is still leaked. So maybe the threat model becomes We know we can't protect users trying to visit a .onion without/with-misconfigured Tor, so perhaps we want to at least enable the functionality, and hide what the user is doing on the HS'. Obviously there's a mess of holes with this, but I'm just thinking aloud, and if the idea of exposing HS to the normal web through .onion is desirable, we could start brainstorming in advance of the several hundred pages of paperwork applying for a gTLD requires. -tom [0] If every DNS Request returned the IP of Entry Guard or similar node, along with a DANE record, and a DPF policy of 'Always use SSL', the client would connect to the IP hardcoded to use SSL with a pre-arranged certificate. They would then request the resource of the hidden service (let's say '/'). That Entry Guard would hold all the information: the client connecting, and the resource requested. This is obviously nowhere-near-ideal, but for a 'Let everyone use any browser' situation, I'm not sure how to avoid it. That Entry Guard would then route the request through the Tor network, potentially padding it. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Torbirdy and gpg --throw-keyids
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I agree with Jake. Less information disclosed is better. Under some circumstances I will encrypt a message to recipients not in the email. For example, if I am emailing on behalf of a group, I will encrypt to the group, even if I do not CC/BCC them, because I consider it a 'trust' thing. I never intended them to not be able to read that message, so I portray it. (It's also super-handy if I need to forward the email from a phone w/o my key.) Another situation could be encrypting emails to a backup key of my own. Or even (whip me for suggesting it) encrypting to a message escrow service of some kind. So throwing the keyids of everyone but the recipient and sender is very good, and should be done. I argue strongly for that. Under some strange circumstances, the receiver and/or sender may have a non-public key that the message would be encrypted to, that they would not like to disclose the existence of. It could be used to segment working vs personal relationships, keep a high-security key under wraps for use with your spouse, be a project specific key, or perhaps be used to bypass a previously theorized key escrow service. If I was performing reconnaissance on someone, and say 85% of their traffic went to a public key on a keyserver, and 15% went to an undisclosed key - that's strange. But on the flip side, it's obvious the message is encrypted to the recipient(s) specified on the email and the sender saw it unencrypted... and in some cases those recipients may be greatly inconvenienced by throwing the keyids - as in your case. So throwing the keyids of the recipient(s) is still arguably important, but less so than third-parties. I could go either way on it. It almost seems like it could be worth codifying a preference in the OpenPGP standard. Potentially interpreting http://tools.ietf.org/html/rfc4880#section-5.2.3.17 to also imply throw-keyid or adding a new option. - -tom -BEGIN PGP SIGNATURE- iEYEARECAAYFAlAJ/DwACgkQJZJIJEzU09tWhwCfbW9CKWhr5O4ulukjokJdRtqr wLIAniS+G5NaBQr5HX1BFWvGfygRze2I =XazV -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] Roger's status report, May 2012
On 23 June 2012 18:20, Roger Dingledine a...@mit.edu wrote: - Start summarizing Tor research papers on the blog more regularly. There have been a huge number of really important research papers lately, and most Tor people don't know about them. Should I summarize them on the blog (for a broader audience), or on tor-dev (for the rest of the Tor developers), or what? The only reason I could think not to put them on the blog would be because it may 'turn off' some users because it's too mathy/programmy. If you're not worried about that, put them on the blog. If you are, perhaps a separate 'Tor Engineering' blog? If you do separate it into a second blog, you could disable comments, simul-post to the tor-dev list, and say all comments should go on-list -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Webserver on 127.0.0.1 only?
On 5/9/12 2:52 PM, Jerzy Łogiewa wrote: when building webserver I want only 127.0.0.1 able to connect - not the internet and not 192.168.x.x even! this is for hidden service _ONLY_ and no one even on local network should be able to probe for it. i know how to setup hidden service basically. how can i do this above with apache or lighttpd? if i want the same for ssh how can I do it using system? restrict all connections to 127.0.0.1 - and no tails please! :-D In addition to Ralf's advice (which is correct), you can/should configure a firewall to prevent connections to port 80 and 443 (and really everything except how you connect to the box which is probably ssh) just to be double-safe. You can use iptables for this, but if iptables is really confusing to you, I personally use shorewall which abstracts iptables to configuration files that make (more) sense. -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Another openssl advisory: Tor seems not to be affected (Chroot?)
On 19 April 2012 11:50, Fabio Pietrosanti (naif) li...@infosecurity.ch wrote: Apache does it with Mod_Security: http://www.modsecurity.org/documentation/apache-internal-chroot.html ProFTPD does it with DefaultRoot: http://www.proftpd.org/docs/directives/linked/config_ref_DefaultRoot.html To add another data point, Colin Percival has blogged about how he terminates SSL connections in a jail to mitigate this risk. http://www.daemonology.net/blog/2009-09-28-securing-https.html -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
