Re: DNS with Tor (compared to VPNs).
On Wed, Oct 20, 2010 at 4:47 PM, wrote: > ... > : However, my ISP does not see the DNS requests (or the website since > : all traffic flows through the encrypted VPN). > > It depends on the VPN. Many vpns don't touch your dns settings, > therefore your local resolver sees the requests. the reverse is not true, however. there are numerous side channels around host default nameserver entries set by VPN software or yourself manually (explicit resolver IP passed to host libs, or custom UDP DNS queries, or caching proxy query reflection, or. etc. "am I leaking DNS?" turns out to be a complicated question... > : If I am using Tor then all DNS resolution is done by the Tor exit > : node. No DNS requests leave my computer unencrypted - unlike in the > : previous two examples. > > If the apps are set to use tor correctly, yes. this is one reason why Tor Button or other privacy minded extensions and configurations explicitly disable bad plug-ins and mime types; this is useful for VPN users in general who want leakage resistant DNS privacy through their VPN provider DNS nameservers rather than ISP defaults. again, more complicated than it seems; devil in the technical details according to your uses and threats... best regards, *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: TCP stack attack?
On Sun, Oct 24, 2010 at 8:28 PM, coderman wrote: > ... > 1. remote ring0 do happen, c.f. CORE-2007-0219: OpenBSD's IPv6 mbufs > remote kernel buffer overflow. Forgot to link to the announce in question; it is worthy of a read if only to emphasize why any claim of immunity from a broad class of threats with blanket assurance is a strong claim best made after thorough and extensive effort to prove it to yourself via technical applied testing and measurement. http://www.coresecurity.com/content/open-bsd-advisorie "OpenBSD's IPv6 mbufs remote kernel buffer overflow" 2007-02-20: First notification sent by Core. 2007-02-20: Acknowledgement of first notification received from the OpenBSD team. ... 2007-02-26: OpenBSD team communicates that the issue is specific to OpenBSD. OpenBSD no longer uses the term "vulnerability" when referring to bugs that lead to a remote denial of service attack, as opposed to bugs that lead to remote control of vulnerable systems... 2007-03-05: Core develops proof of concept code that demonstrates remote code execution in the kernel context by exploiting the mbuf overflow. 2007-03-05: OpenBSD team notified of PoC availability. 2007-03-07: OpenBSD team commits fix to OpenBSD 4.0 and 3.9 source tree branches and releases a "reliability fix" notice on the project's website. ... The OpenBSD kernel contains a memory corruption vulnerability in the code that handles IPv6 packets. Exploitation of this vulnerability can result in: 1) Remote execution of arbitrary code at the kernel level on the vulnerable systems (complete system compromise), or; 2) Remote denial of service attacks against vulnerable systems (system crash due to a kernel panic) The issue can be triggered by sending a specially crafted IPv6 fragmented packet. OpenBSD systems using default installations are vulnerable because the default pre-compiled kernel binary (GENERIC) has IPv6 enabled and OpenBSD's firewall does not filter inbound IPv6 packets in its default configuration. However, in order to exploit a vulnerable system an attacker needs to be able to inject fragmented IPv6 packets on the target system's local network. ... """ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: TCP stack attack?
On Sat, Oct 23, 2010 at 5:59 PM, Robert Ransom wrote: > On Sat, 23 Oct 2010 12:42:11 -0700 > Julie C wrote: > >> Has anyone come across any TCP stack implementation vulnerability research? >> ... At this point in my education it strikes me that the TCP stack >> on any Tor node could be altered to do malicious things, and no one would >> ever know, or be able to know. > > Roughly every attack that can be performed in a Tor node's TCP stack > can also be performed by anyone that can stick his own hardware between > the Tor node and the Internet. There are some attacks that can be > performed there, but an attacker who can modify a Tor node's kernel > would be able to do more damage by reconfiguring or modifying Tor > itself. long of it short: given the spectrum of OS level remote ring0 exploits in network device and protocol attack surface, there is a potential risk here. given all of the other risks [0][1], this is probably the least of your many concerns... best regards, 0. if I were to rank broad category, a. application level arbitrary execution or side channel attack. so many, so frequent to reify and persist, so easy to leverage for full privileged arbitrary execution, so many additional clauses to add but omitted for brevity. (remote w/ priv. escalation, direct remote root/ring0, local escalation, vm break-out, many others) b. Tor deployment weaknesses as commonly built, distributed, and used on various platforms, primarily Windows, Mac and various Linux and Unix like systems to a lesser extent for everyone but node operators. (ex. Unauthenticated control port access with cross protocol vector - implementation / deployment vulnerability) c. Tor usability or correctness deficiencies including the application layer (ex. Firefox with Tor Button Extension - application usability, Transparent Virtualized Privacy Router - configuration correctness: IP and DNS side channel elimination) d. everything else, including mundane issues like not using trojaned hardware out to exotic risk models with chained professional multi-0day targeted efforts or state agency actors. but not the risks that exist outside your threat model, or the un-identifiable and un-conjecturable unknown risks we can't predict or reason about. :/ i mentioned the "Threat Model", right? because this entire topic of conversation requires the presumptive act of you having pointed out the threat model you are assumed to be operating under and that we are both discussing. :) 1. remote ring0 do happen, c.f. CORE-2007-0219: OpenBSD's IPv6 mbufs remote kernel buffer overflow. fortunately these are rare, extremely valuable (likely to be exposed once propagating), and relatively infrequent compared to most other operating system vulnerability concerns. stuxnet is a good example of the exotic end of this spectrum; unless "you" yourself are a very well funded or state level actor you're pretty much fucked/ entirely and inevitably fucked. :P *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Excessive scrubs
> And some would consider phony names used in email to show > lack of courage of convictions when voicing opinions in public Throughout history, some of the world's most important movements and changes have originated with the Anonymous. Anonymity is a tool whose use case is rightly selected solely by the user, not others. As are defenses against it the purview of the latter. Neither free to trample the other across the divide. It's a beautiful thing. During such selection, certainly some would consider system nodes run by those who speak against such anonymity (in whichever the case) as fine candidates for their excludes... lest they become unreliable partners (in whichever the heat, or the whim). Then again, how does one select any particular partner from the space, be it node or human? Which assertions are true? Which shall stand? And what value to assign the many silent ones? Most curious questions indeed. Therefore, rest. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: OT: Etiquette (was Re: Excessive scrubs)
This is way off topic, please take it off the list. Thanks. -- Andrew pgp key: 31B0974B *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
OT: Etiquette (was Re: Excessive scrubs)
Hi! On Sun, Oct 24, 2010 at 03:04:16AM -0500, Scott Bennett wrote: > I think what he was referring to was the fact that I do not use a mail >interface that supports the use of optional headers for threaded reading of >mail by subject similar to the way threaded USENET newsreaders do it. While "References" for mail is rather new and very optional, "In-Reply-To" is standardized in RFC822, i.e. very old already, and if your mail reader program set it, it'd be enough for most thread displays. If you're not the administrator of the box, you can still ask the administrator of the box to fix at least the generation of "In-Reply-To". >[...] >>Respectfully Scott, some would consider your signature / long quote, w/ >>multiple rows of asterisks & dashes a bit excessive. Doesn't bother me >>particularly, but would some. >[...] > Many people also would consider my .signature not to be excessive, >and there are many whose .signature blocks are far larger than mine, some >so much so that I would also be inclined to object if the owner were a >frequent poster. FWIW, mine has gone through many changes over the years, >but I like the way it is at present. If I run across another quotation that >I happen to like better, I may replace it. For mailing list use, I normally >omit the postal address lines anyway as below. One most important thing could possibly be to separate it using the "-- " convention. Then at least a few mail reader programs would offer the option to hide it/grey it out and to hide it from the quotes in replies. Kind regards, Hannah. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Excessive scrubs
On Wed, 20 Oct 2010 08:11:25 -0500 Joe Btfsplk wrote: > So I won't make same 'mistakes' as Jon, please explain what you mean by: >> please learn to edit followups in-line, i.e., stop top-posting >[Isn't top posting the way most forums work? I'm guessing protocol is >diff because it's a mailing list?? I haven't used mailing lists that >much.] Nope. I've never seen any non-tor-related lists where so many people top-post. On most lists to which I have ever subscribed, other subscribers firmly object to top-posting when it appears on those lists. Also, feel free to visit http://www.caliburn.nl/topposting.html http://www.html-faq.com/etiquette/?toppost > >and, >> please learn to list-reply, i.e. stop breaking threads >What is meant by "list-reply" vs "stop breaking threads"? Aren't they 2 >diff things? This is something I've answered many times on this list already, but I will answer it this one final time. After this, anyone who gives a dam can bloody well look up an instance of my explanation in the list archives. I think what he was referring to was the fact that I do not use a mail interface that supports the use of optional headers for threaded reading of mail by subject similar to the way threaded USENET newsreaders do it. My explanation in this case is in two parts: 1) regardless of the condition of other subscribers to mailing lists, my eyeballs and brain work just fine, so I have no trouble following the flow in the lists, including list digests, which are what I receive for most of my list subscriptions outside of the tor-related lists, especially for lists that are such low-volume lists as the tor-related lists tend to be, and 2) it's out of my control anyway because I not only am not the system administrator on this system, I have merely a guest account for the primary purpose of dealing with email, so I can't install mail software to suit the tastes of other people on the lists to which I subscribe. > >Respectfully Scott, some would consider your signature / long quote, w/ >multiple rows of asterisks & dashes a bit excessive. Doesn't bother me >particularly, but would some. > And some would consider phony names used in email to show lack of courage of convictions when voicing opinions in public, although I do recognize that there are some life-threatening situations where such practices may be necessary to reduce/eliminate the risk and the lack of courage is therefore forgivable. I don't know your situation, and perhaps you are exposed to such dangers, so I cannot comment upon the particular case of your use of a seemingly phony name, nor do I let such usage bother me as a rule either. Many people also would consider my .signature not to be excessive, and there are many whose .signature blocks are far larger than mine, some so much so that I would also be inclined to object if the owner were a frequent poster. FWIW, mine has gone through many changes over the years, but I like the way it is at present. If I run across another quotation that I happen to like better, I may replace it. For mailing list use, I normally omit the postal address lines anyway as below. Although I didn't respond directly to Jon's reply, I'd like to thank him for his update and its reassurance. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
