Re: [tor-talk] tor/netfilter: packets without uid
On 05/10/2012 09:11 PM, johnmurphy...@safe-mail.net wrote: Hi List, I am trying to tweak my transparent netfilter setup (Tor Stable, Debian Wheezy, GNU/Linux, iptables v1.4.12.2, Kernel 3.2.0-amd64). So far, redirection and torification works fine. I have have several users, some of them have their TCP traffic forwarded to Tor, some are allowed to send packets directly. It works splendid. There is just one issue. About every once or twice a second there is a tcp packet running along my filter (that is the iptables -t filter) table that has no associated UID. This is what they look like: IN= OUT=eth0 SRC=192.168.178.50 DST=some-target LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=50447 DPT=443 WINDOW=1002 RES=0x00 ACK URGP=0 This packet is https, most likely generated by my firefox user when I was browsing a website. But it gets more interesting. There are lost packets, even when I only use Tor. A reverse dns lookup of the target ip shows that these are packets send by tor to the first relay. How is it possible for a packet not to have an associated uid? Dropping these packets of course works, but the logging clutters my syslog, and after all, why is there this type of leaking in the first place? I'm not a netfilter expert, but it looks this is a pure TCP ACK packet. With LEN=40 there's no application data in it. It may have been auto-generated by the kernel as a reply to the external packet and never tagged with a user for that reason. Dropping them may result in retransmission. As you noticed, once or twice a second until there's some user tagged data going out that can transmit the ack. Just a theory. - Marsh ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] segfault at 8 ip ... error 4 in tor
On 12/01/2011 09:16 AM, Hanspeter Spalinger wrote: Hi, I built a new gdb (from the homepage), and got the output below. I too tried rebuild tor from the source (apt-get source, dpkg-buildpackage,...) and both times the stack trace looks like this. I do not understand why gdb does not find the tor-dbg symbols, i installed them and squeeze gdb finds them, but not the new gdb (i tried the map-debug configure option and used the -s Option to directly give the path, but nothing worked) spahan:~/tor2# ../gdb/gdb-7.3.1/gdb/gdb -s /usr/lib/debug/usr/sbin/tor tor /var/lib/tor/core You might try building tor yourself and launching the tor executable right from the path where it was built, i.e., the location from which 'make install' would copied it. That's always given me the best luck for having gdb locate symbols and source. - Marsh ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor no longer works with win2K ??
On 11/12/2011 01:11 PM, Julian Yon wrote: Nobody's going to keep an old, unsupported system up and running, at personal expense, just to appease a person who is rude to them. It's also a bad idea from a security perspective. You could easily be doing them more harm than good. Win2k had a long and useful life, but it has been laid to rest by its creator. If it feels "stable" and "well understood" today, it is because the world has decided to no longer research and report its bugs. It's old and busted. Don't run it, even from behind a firewall. It is not secure. - Marsh ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor and AES-NI acceleration , and Tor profiling
On 11/08/2011 12:28 AM, Jacob Appelbaum wrote: On 11/07/2011 09:29 PM, coderman wrote: On Sun, Nov 6, 2011 at 5:57 PM, Moritz Bartl wrote: ... [notice] Using OpenSSL engine Intel AES-NI engine [aesni] for AES however, you are getting not only 3x-10x+ performance improvement in AES ops, but also avoiding nearly all side channel attacks against AES! Aren't you really just replacing them with hardware specific side channel attacks against their implementation of AES? :) I wouldn't think so. My understanding is that the problem with AES is that a straightforward implementation performs lots of table lookups and the access pattern is dependent on the secret key. This leaks information via cache timing. AES-NI converts this to a single instruction which is said to operate in constant time. So that would be a back door, not a side channel attack. :-) - Marsh ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Freedom Hosting admin revealed by Anonymous - Tor finally cracked?
On 11/02/2011 05:54 PM, Gozu-san wrote: Is it really possible that over 100 fools would have downloaded a purported Tor security update from Hard Candy in one day? In the middle of an attack by OpDarknet? Seriously? Mozilla stats https://addons.mozilla.org/en-US/statistics/addon/2275 seem to suggest that there were 3000 Torbutton downloads and 171000 active Torbutton users on a typical day (earlier in the year before it was removed). 190 users falling for some professional social engineering and downloading a signed code update hosted on a compromised web server seems realistic to me. I'd guess at an estimate of the overall site popularity, probably fewer than 2000 regular visitors. - Marsh ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Google and Gmail
On 09/10/2011 10:22 PM, Andre Risling wrote: I've noticed a lot of people that are concerned about privacy and security are using Gmail accounts. Do you really trust Google not to read your email and tell THE MAN what you've been saying? No. But technologies like Tor are general purpose and useful for many things. Sometimes other people in the world have different instances of "THE MAN", maybe theirs might be expected to not have the same access to Gmail. Accessing Gmail from within a network which is trying to block or intercept it is a easy to explain and realistic scenario. That type of example is useful for discussing the general security properties of a system. It also happens to be a service under active attack right now, providing a case study for attackers and defenders alike. This is historic: in the almost two decades of web security history, this is the first time a certificate issued by a widely trusted root CA has been detected in use in large scale man-in-the-middle attacks. - Marsh ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor spying
On 09/07/2011 09:21 PM, Indie Intel wrote: Apparently people are spying on Tor users by setting up their own exit nodes and sniffing traffic?! Oh yeah. It happens. This Moxie Marlinspike is even a well-respected researcher, apparently. He gives talks at Blackhat to government hacker wannabes. You may have the threat a bit backwards. Just try to imagine the spying that goes on over the internet as a whole. Governments, ISPs, telcos, businesses, spouses, employees, malware on your LAN, bad guys are all sniffing traffic all the time. Some digital satellite ISPs have an unencrypted downlink and the entire hemisphere can see the traffic. The difference here is that these security researchers have blessed the public with the fruits of their research and we have benefited from it. But stealing email passwords and credit card information? How is this legal in the US? It's a gray area. I wouldn't do it myself, but I'm grateful to the others who have on occasion done something useful with it. The more I research this, the more it seems this sort of ``research'' is more common than not. Wikileaks, Jacob Appelbaum, Adrian Lamo, Moxie Marlinspike... who else? Iran?! Yeah, who don't? The Tor Project needs to shed some light on this or it will have a serious problem with people wanting to use Tor at all... It's even a FAQ https://trac.torproject.org/projects/tor/wiki/doc/TorFAQ#CanexitnodeseavesdroponcommunicationsIsntthatbad Personally, if I were going to transmit a credit card or email password in-the-clear over Tor I'd choose Moxie or Jacob over some random node any day. But I'd do everything possible to avoid that in the first place. - Marsh ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Dutch CA issues fake *.torproject.org cert (among many others)
On 09/07/2011 04:48 PM, Julian Yon wrote: There's no need to be patronising. I have plenty of security experience. Sorry, wasn't trying to be patronizing. Just trying to give my opinion plainly. This is where, IMHO, computer security people can maybe take a step back. Sure we should all remind each other that it's easy to get engrossed in the computer screen that we forget what's going on around us and who may be watching. But everyone in the world has experience managing their own personal space and physical security. Computing devices are ordinary physical objects now. Computer security people may not be any better qualified to advise on personal physical security (and maybe we come across as a little patronizing too). Shared environments are not a thing of the past, certainly not in the UK, and a physically present adversary is a real threat for many people. Right. I'm just not particularly qualified to advise about that kind of threat. Not everyone can be told to look away (unless you like time in hospital), and if you can use a drop-down with your screen covered then I applaud you. And online-banking isn't aimed at experts, it's used by "normal" people. It's so easy to mitigate this specific threat in software that it is negligent not to do so. Realistically today the bank may have thousands of customers with malicious keyloggers for every one who is protected by an obscured display. This was not the case just a few years ago, the threat has changed. The keylogger threat might be somewhat mitigated with the UI changes, but the UI is largely incapable of restoring a user's physical security. - Marsh ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Dutch CA issues fake *.torproject.org cert (among many others)
On 09/07/2011 03:19 PM, Julian Yon wrote: My bank forces me to enter part of my password using unobscured dropdowns "for security". Sure, it avoids keyloggers, but what about *someone standing behind me*? Do they have a gun? Otherwise, cover the screen with your hand or ask them to look away. Realistically, this is nowhere near the biggest threat these days. It's mostly a holdover from security guidance from shared computing labs and pre-internet days. Yes, be aware of your physical surroundings. No, don't think that it keeps you one bit safe online, unless you're that special case where your adversary is physically present. - Marsh ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] EFF Tor Challenge
On 06/01/2011 07:35 PM, cac...@quantum-sci.com wrote: On Wednesday 1 June, 2011 16:39:22 Javier Bassi wrote: I have to say I felt a bit disappointed when I saw that the EFF was also running a middle node. I thought they would be running the openest exit node. Everybody's gotta choose their battles and the EFF has chosen enough of them to earn my great admiration. Although, until a Best Practices emerges for running a relay securely, I won't be running a relay at all. We went over this in detail here recently. The three methods I can think of have problems: - chroot jail can be broken by a skilled cracker. Yeah it's usually a matter of only a few weeks between local privilege escalation exploits for Linux are published on lists like Full-Disclosure, and those are just the ones that are not sold. Security boundaries on shared commodity hardware have almost always turned out to be ineffective. They're a myth, like Santa Claus, one that basically honest and good-natured people agree to believe in because of the huge cost savings it enables (over having to purchase separate hardware for every category of data). But this latest round of virtualization technology is holding up better than I'd expected. - VirtualBox VM bridged to LAN still must share the LAN class C, and could potentially monitor internal traffic. (And please don't quibble with me calling it a class C... they have to make up a name and stick with it. I still call Nissan's a Datsun) No, you're factually wrong on the deeper point. The muddy terminology is just a symptom. - VPN to router, most routers do not have VPN functionality, only the business-class like ProSafe. Don't forget the host-only virtual networking that was suggested too. Until Best Practices are defined, many of us will be wary as we know what is possible. Yes, everyone should think and plan carefully before running anything that accepts incoming connections from the internet. However, the millions of actual servers on the internet show that many can accomplish it in practice (both well and poorly). A Tor internal node is not really special in this regard and, actually, its attack surface is relatively limited in comparison. Just imagine trying to secure a full-featured multiuser mail server! Personally I'm more concerned about running Wordpress or any other random PHP app than TOR. - Marsh ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Securing a Relay - chroot
On 05/27/2011 11:22 AM, cac...@quantum-sci.com wrote: On Friday 27 May, 2011 08:10:47 tagnaq wrote: You do not mention the threats you worry about and assets you care about (thread model + security requirements). Yes that's because I don't know what threats there may be. http://en.wikipedia.org/wiki/There_are_known_knowns I am a user, I don't have an MS in Computer Science. Heh, I've known those who do who couldn't get as far as you have already. For example I don't understand, "maps subnets and/or ports to inside. Separating traffic into VLANs. In general having a lot more control of the hardware layer." Wikipedia has a great article on VLANs. What good is this if users can't secure their own machine effectively? Why set up a relay if my own machine could be compromised? You are asking entirely valid questions that the entire data security industry also struggles with every day on a deep level. I don't have a real satisfying answer for you. You already understand the key point though: separation. Decide which systems you trust and for what purpose in what contexts you trust them. Place systems in different trust zones accordingly. Implement barriers between the zones and be very selective about what is allowed to pass. No wonder you have a hard time recruiting relays, much less exit points. I guess the coyness here is for some good reason, but it's not doing the cause any good. Looks like I have to give up on a relay. Computers and networks are inherently good at copying and leaking information, they do it without even trying. Providing an open service while perfectly blocking the flow of selective information is actually extremely difficult to do on shared hardware. There is always a cost to security, usually complexity, performance, administration, and money. I find this stuff fascinating and spend all my learning about it. But when I set up a relay the other day, I chose to address most of these problems with money: I paid a few dollars a month for a remote virtual host environment having no trust relationships with any of my other systems. - Marsh ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor TLS error
Which version (number, distribution) of OpenSSL are you using? The line number s23_clnt.c:607 might tell us something. Could you get a packet capture (Wireshark, tshark, tcpdump, etc.)? It's probably only a few KB of the packets which are relevant to the failed connection attempt. On 05/27/2011 11:06 AM, alex wrote: On 05-27 17:56, intrigeri wrote: Not really, but enabling starttls mode makes it work: $ /usr/bin/torify openssl s_client -starttls smtp -connect 83.223.73.105:465 True, but I actually want to *not* do that. My guess is that the problem relates to the SMTP server not accepting raw TLS on port 465. Is the perhaps an MS Exchange server? From http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol : Server administrators choose whether clients use TCP port 25 (SMTP) or port 587 (Submission), as formalized in RFC 4409, for relaying outbound mail to a mail server. The specifications and many servers support both. Although some servers support port 465 for legacy secure SMTP in violation of the specifications, it is preferable to use standard ports and standard ESMTP commands[14] according to RFC 3207 if a secure session needs to be used between the client and the server. Some servers are set up to reject all relaying on port 25, but valid users authenticating on port 587 are allowed to relay mail to any valid address. Can you use port 587? - Marsh ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor TLS error
On 05/27/2011 11:53 AM, alex wrote: On 05-27 11:39, Marsh Ray wrote: Which version (number, distribution) of OpenSSL are you using? 0.9.8o-5ubuntu1 Could you get a packet capture (Wireshark, tshark, tcpdump, etc.)? I'll try. But I'm running a Tor Relay, so isolating my traffic is kind of hard :) Perhaps you have access to take the capture on the server side? True, but I actually want to *not* do that. My guess is that the problem relates to the SMTP server not accepting raw TLS on port 465. Is the perhaps an MS Exchange server? The thing is: it works without Tor. It would be interesting to compare the two pcaps. The Server is a qmail, although the port there is a Stunnel. - Marsh ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Securing a Relay - chroot
On 05/26/2011 11:12 AM, cac...@quantum-sci.com wrote: On Thursday 26 May, 2011 07:31:42 Eugen Leitl wrote: So you're worrying about a compromised vserver guest compromising the host, which is then used to attack your LAN segment? Doesn't even have to compromise the host. With the guest in the same class C it can monitor traffic. It's more that it's in the same 'broadcast domain' at the switching layer, whereas 'class C' is an (archaic) routing layer concept. Depending on the details of the switch though, monitoring (and active man-in-the-middle attacks) could range from easy to impossible. But it may be that your virtualization software can force the guest NIC inside an IEEE 802.1Q VLAN so it can't see the rest of the network. Which raises the question of what it can see, so you'll have to provide it with some connectivity, like a 192.168.x.x address and NAT to publicly-routable IP space. You could even do this NATting and firewalling on the host kernel, perhaps with a virtual "host only" segment from the guest to the host. But don't ask me for every detail on how to set this up :-), I've listed the key terms for which there are HOWTOs available. You should only undertake this project if you _like_ digging into this sort of thing. - Marsh ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] "drop all vulnerable relays from the consensus"
On 05/15/2011 03:38 PM, tagnaq wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, "If someone publishes or demonstrates a code-exec exploit [...] we should drop all vulnerable relays from the consensus" [1] - - Does Tor provide Authority Directories with an easy way to reject/drop relays from the consensus based on the platform string or is this only possible based on FP or IP? - - How will Directory Authorities determine if a relay is "vulnerable"? (inspecting the platform string only)? Once the attacker has code execution he can patch it to emit whatever version string is necessary. We see this with Windows botnets which will sometimes, immediately after infection, patch the vulnerability they used to come in on. They may also un-patch some other vulnerability (reinstalling the original vulnerable signed code) in such a way that the OS still thinks it's applied the update. Of course, none of this is an argument against kicking off known-vulnerable clients. - Marsh ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
