Re: [tor-talk] Tor and TBB Issues Needing Good Advice

[Wanderingnet <wanderingnet@xxxxxxxxxxxxxx>]

I understood that most TB attacks were metasploits - exploitations of vulnerabilties that result from java, flash et al, or other increases in attack surface in browsers. I >despise< the heavy use of java on the net: it slows life down, and is an increased vulnerability, and would love to discourage it. It is also genrally extraneous to requirement, for example email services will work perfectly well without java; animated gifs are cool :)

​Sent from ProtonMail, Swiss-based encrypted email.

​

-------- Original Message --------
 On February 3, 2018 2:02 PM, Wanderingnet <wanderingnet@xxxxxxxxxxxxxx> wrote:

>Yes, I have already adapted the TBB browser to proxy the package installed tor service. This just entails stripping out the tor elements and treating the browser as a relatively clean Firefox pointing to the appropriate proxy.
> Obviously, the benefit of the tor service is UID, allowing it to be specified in IPTables. But Vanilla Tor is poor, will rarely get off the ground, and has little defence; and there is minimal pluggable transport support in packages without a lot of work.
> The idea, instead, is to have the tor service, configured in init.d/tor and the tor-defaults file, to point to the TBB binary and its pluggable transports (all in Tor and Data in the TBB folder structure).
>
> This should be feasible, since the TBB folders contain everything needed to run Tor, and the tor system daemon installed by the debian package is configured in /etc/init.d/tor and the tor-defaults file in /usr/share/tor, allowing it to be pointed at the TBB binary. I can't find anything that configures pluggable in the system beyond the torrc config file itself, so it is unclear how to ensure the tor binary uses the transports in the TBB folder, unless this is incorporated in the binary anyway.
>
> This would be radically unlike any version of tor I've seen run, and advantageous, since it benefits from the tor daemon, allowing a hard iptables policy to specify the daemon UID (simply changing the permissions of the TBB package, or creating and assigning a GID is something I have tried and not been able to have work), and from the newer TBB binary and its extensive support for transports, all contained in two folders and constantly updated and easy to update. In fact, in theory, this would be better than installing Tor at all: all that would be required ideally would be the TBB, an edited init.d and defaults file and a script to run.
>
> This also assumes that the debian package in installed and simply hijacked to run TBB.
> Editing init.d/tor is not straightforward, though: the path statements are odd, for a start. I have started to look at editing init.d daemons in Linux for this purpose. But all this will take a lot of trial and error. If there is much more to it, it would help to know.
>
> ​Sent from ProtonMail, Swiss-based encrypted email.
>
> ​
>
> -------- Original Message --------
> On January 25, 2018 5:21 AM, Andreas Krey a.krey@xxxxxx wrote:
>
>>On Mon, 22 Jan 2018 13:33:31 +0000, Mirimir wrote:
>> ...
>>>But it would be very cool if its vulnerabilities were clearly disclosed.
>>> On the download page. There's already disclosure (but maybe not explicit
>>> enough) that Tor isn't secure against global adversaries. So why not
>>> disclosure that Tor browser isn't secure against Tor-bypassing malware?
>>>Perhaps to not scare the potential users away, as in 'like not that much
>> more secure to be worth the download'?
>>Also, the GPA can attach tor/TBB as designed; the FBI's thing relies
>> on vulnerabilities that are not in the design. But I'm not writing
>> the download page.
>>...
>>>As I understand it, FBI's NIT gets dropped through Firefox, but it
>>> phones home through a standalone process.
>>>Yes, but the phoning home is necessary to locate the user. It could
>> just as well access ifconfig.me via clearnet, and then relay the result
>> home via tor, but that is an unnecessary step.
>>If it were to just take control of the machine it could really do
>> all its comm via tor.
>>>So restricting Firefox to Tor
>>> wouldn't be enough. But even if I'm wrong about existing malware, what I
>>> describe is doable. It's already a risk when opening downloaded files.
>>>Yes. Basically, firefox, and everything it starts needs to be contained
>> in a sandbox. (With the added difficulty that opening some documents
>> on some systems will not start a new process but tell an existing one
>> to open the doc.)
>>...
>>>
>>>>I have to 'admit' that I have a TBB instance running
>>>> partially so I can use putty to reach hidden services.
>>>> Why not standalone Tor?
>>>>
>>>Because windows. I had a proprietary windows service wrapper (that
>> needs to be compiled into the service's, i.e. tor's, code), and remember
>> the fickleness; I never looked into how to run tor as a windows service
>> officially. And partly because I have TBB running all the time anyway.
>>Also: Admin permissions, and update hassle. Self-updating tor as windows service?
>> I don't think we even have a suitable download source for that.
>>(My raspberries all do have tor as a service, in different ways, and
>> different ages. Because no TBB for them, and because they have the
>> hidden services to access.)
>> - Andreas
>>--
>> "Totally trivial. Famous last words."
>> From: Linus Torvalds <torvalds@*.org>
>>Date: Fri, 22 Jan 2010 07:29:21 -0800
>>tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
>> To unsubscribe or change other settings go to
>>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>>
>

-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk