I have recently tried a new browser, torpark. It works fine BUT avast does not intercept incoming websites.
I have tried OptinProcess=tor.exe under [Webscanner] in avast4.ini but this does not work.
Any ideas to solve this?
Well, first tor.exe is not a web browser … I am somewhat lost to imagine how you arrived at this solution. The process tor.exe is a form of peer-to-peer client designed for anonymous web connections.
As you may have found from searches in this forum, the Web Shield works by scanning only those processes that have been designated by the avast team or those that user specifically include by the Optin process.
torpark a variant of the portable Firefox web browser and probably has not yet appeared over the horizon in many a geek’s view. It seems it is the offspring of portable Firefox mated with Tor.
A better process name to include in the Optin process (from scans rather than personal testing) would seem to be torpark.exe.
Please let us know if that shows up in the Web Shield scanned sites and counts … if not … we’ll look into it some more.
Which is your operational system?
Is tor.exe the name of the process (not the executable) of Torpark?
Which port Torpark uses to connect the Internet? The default 80?
For alanrf
Yes I have tried torpark.exe & this does not work either, hence my attempt with tor.exe.
for Tech
I am on windows XP home SP2 fully updated. alanrf’s post explains the type of system torpark uses. Basically it uses firefox system but net connections show as tor.exe process in a port monitor. Tor.exe initially sets up an anonymizer circuit before firefox is activated.
Thanx for the replies.
I installed torpark to get a better idea of how it works.
It consists of a strictly contained implementation of a customized version of (portable) Firefox along with the web traffic anonymizer function tor. It is intended for use with such devices as a USB keychain where it can be loaded, the USB device plugged in to a PC and the package used for anonymous web browsing. When the USB device is removed no data is left on the PC at all to indicate it was ever used.
The program is initiated by executing the process torpark.exe - this process is not a browser it is used to initiate the browsing environment. It first uses tor.exe to set up a “circuit” or route through the network of tor servers that transfer web connections that are encrypted through a maze of servers … the web request is finally decoded at an exit server and passed to the intended destination bearing no trace of the originating IP address.
Once the tor “circuit” has been established the customized version of Firefox is started. This is basically the current production version of portable Firefox. However it is set up to use a SOCKS host (v5) proxy to localhost:9050. I confess at this point that I am not familiar with SOCKS host proxy use. It appears that the http requests from Firefox are then routed via the proxy to tor.exe which encrypts it and launches it into the anonymizing “circuit” that has been set up already.
To see if avast could trace the http requests to localhost:9050 I added the port to the list of redirects in the Webshield and unchecked the “Ignore local traffic” box. However that just resulted in every browser request being timed out.
Perhaps there are others familiar with SOCKS host proxy use who might have more effective suggestions.
cshinn101,
the torpark developer has a forum dedicated to support of the function. It might well be worth asking there for advice on using torpark so that an antivirus like avast can scan the http responses. In my scan of the forum I did not see any reference to such a request.
Hello, first of all greetz to all forum supporters, specially szc and alanrf for his hard work researching for this topic 
I first get curious about Torkpark when I read this topìc because I was using -until that time- Vidalia-Tor-Privoxy bundle with Opera 9 USB, switching between normal conections and proxies ones via F12 hotkey.
But Torpark really took my attention and I decided to investigate it a little. So, I found that if you set avast! correctly it can scan Torpark traffic like any other common browser.
For me to work, I just added (check bold)
HttpRedirectPort=80,443,3128,8088,8080,7900,1080,83,82,81,8888,8118,9050
and
OptinProcess=OperaUSB.exe, Opera.efe, op.com, torpark.exe, tor.exe, torcircuits.exe
to the avast4.ini file located in the C:\PROGRAM FILES\ALWIL SOFTWARE\AVAST4\DATA folder (c:\archivos de programa\alwil software\data folder for you spanish speaking people ;))
I then put north to some questionable websites 8) to check if this was working and… voila! no single dialer, trojan, malware, etc. detected by avast! could get thru protection!!
Please check it by yourselves an put back your own experiences in this topic.
Love!!
Thanx for all the time you have spent on this.
I have followed the method given by martosurf, then watched the connect process using a port monitor. The ashWebSv.exe process activated during the initial tor circuit setup only. However it did NOT activate for the full circuit setup or the following firefox operations. Web connections are shown as directly to the tor.exe process.
Although webshield activates for normal firefox use I tried adding firefox.exe to the OptinProcess list - this didn’t work either.
There must be some additional process we are missing.
alanrf
I don’t like running enquiries at more than one place at a time. If we run a blank here I will follow your suggestion on torpark forum.
martosurf
After the previous post I found that in the avast4.ini file which I had manually modified, HttpRedirectPort list had reverted to its previous ports settings. I then tried adding your port string in the custom settings area. There is not sufficient space there for your full list, however I did ensure that port 9050 was included.
With the correct settings this time, I had exactly the same observations as before. The last site scanned is http://194.109.206.212/tor/status/fp according to the webshield on access scanner page, while I am presently writing this post!
I have carefully read Martosurf’s post and I very much regret to say that I believe, exactly as described, it will be completely ineffective in causing avast to scan any of the http activity issued by the customized version of Firefox.
It will cause avast to scan (as I discovered in my testing yesterday and as cshinn101 reports) the few http accesses made by the tor programs in obtaining status information on the tor network and the preliminary setting up of the tor “circuit”. Using the OptinProcess for the tor programs is not very useful, the whole point of the tor programs is to encrypt the http transactions to make them completely unreadable by anyone and any other program.
The Webshield is set up, by default, to not trace any internal communications of the system. The port 9050 is not used for any external communications by tor; it is purely the internal (that’s what localhost means) port associated with the SOCKS host proxy set up in the customized Firefox.
In the Webshield it is possible (as I did) to uncheck the “Ignore local communications” box. I did that with the port 9050 in the redirect list for Webshield. That should cause the Webshield to trace http requests using the 9050 port but, as I reported yesterday, doing that caused every browse request from (the torpark installed) Firefox to timeout.
It may be that martosurf omitted from his post the extra step of unchecking the “Ignore local communications” box in the Webshield. cshinn101, it would be interesting to see if there is any difference for you if you uncheck this box, perhaps you will experience a more succesful result than just the timeouts I saw.
cshinn101 avast already has firefox.exe in the list of programs whose http accesses to any redirected port will be intercepted and the http response scanned, so adding it to the OptinProcess list has no effect.
alanrf
Yes I already tried unchecking that box - it resulted in no connections made.
I have played around with turning tor network on & off & then checking the last scanned site under the On Access Webshield. In every case, when the tor circuit was re-enabled NO change appeared for new scanned sites. In every case when the tor circuit was initialized, the last scanned site was of the form:
xxx.xxx.xxx.xxx/tor/status/fp or
xxx.xxx.xxx.xxx/tor/server/d
irrespective of the number of sites visited later. I imagine these are the encryption servers as there were many cases of the faux IP address not being resolved in the browser status line.
It is my opinion that using the tor circuit effectively disables the webshield provider & that avast users should be aware of this. If encrypted circuits are to be the wave of the future perhaps the avast boffins can investigate alternative forms of webshield. In any case I am now going over to torpark to check whether their encryption system may be modified to allow use of web scanners - I assume avast is not the only product affected.
Anyone interested in this further can use the home page torpark.nfshost.com.
The Internet Mail provider should be disabled to the changes become permanent or, if you change using the GUI, you need to boot, as far I know.
Sorry, but I let to Alan, the expert on these communications troubles, the solution of this mess :-[
This is, in some ways, like the move we see to email being sent and received in an encrypted session from the mail client to the mail server. It stops avast from scanning the email for viruses. There are workarounds available in that case so that security is maintained and avast can still scan the messages.
I do not think that the issue is one of tor needing to change anything to do with encryption. Firefox has nothing to do with the encryption, tor is the start point and end point on the way back for that.
What needs to happen is that avast needs to be able to intercept the http traffic after it leaves Firefox and before it gets to tor. The Webshield would then pass the http request on to tor, when the response is returned it would go back to avast for scanning before being returned to Firefox to be displayed. This is really just another case of proxy chaining that other folks use with browsers and avast. It seems that something is getting in the way of avast being able to successfully use its intercept mechanism in this case for port 9050. It may have something to do with the use of SOCKS host proxy in Firefox - but I would have to defer to the knowledge of the avast team if they go through this thread.
I have followed the post by cshinn101 in the torpark forum.
The only response received (not from the developer) clearly lacked an understanding of how antivirus products intercept browsers and assumed that avast would be trying to scan the encrypted stream outbound from the tor client.
In response to a different post the developer of torpark advised another user that:
Yes, it bypasses your Norton (In)Security. No, you are less likely for viruses and malware since I have all kinds of blocking and safety mechanisms in place inside Torpark. As usual, don't download and open/run files from people you don't personally know.
I very much doubt that this product can qualify as a replacement for a real antivirus product. It may be that, since the Firefox browser is built into the package, one of the “blocking mechanisms” is to ignore any requests that do not appear to come directly from Firefox and may well ignore any re-directed by the avast Webshield.
I am not trying to bash this product, but as always let the buyer beware. Transmission through the tor network significantly delays browsing so I would suggest folks only use this if they really feel they need anonymity and then to be extremely careful in the sites they access - since they will be without any antivirus protection.
If someone wants such “privacy” on their own PCs, I think just installing the current version of Tor would be better since the installer contains Privoxy. Users are able to let Web Shield watch the connection between their browsers and Privoxy. Maybe, Torpark is for messing with other peoples’ computers. ;D
I think we are getting slightly off topic here. Anyone wanting to use a privacy product - see tor.eff.org - should judge the product solely on its privacy merits. I would not want to rely on anti-virus measures where I have no control of updates. Thus I want a product such as avast to use WITH the privacy product.
My admittedly small understanding of webshield is that it must contact the host site & incoming packets are screened before saving onto hard disk. Why wouldn’t it be possible to use the browser to deposit incoming files into an avast quarantine cache where they could be scanned before transferring to the browser cache? This would not be browser specific & would solve the problem. It is so simple … what am I missing?
What you are missing is how browsers work and how antivirus products intercept them to scan the results (just as the person who replied to you in the torpark forum did).
The antivirus products all have the same problem. Every browser works a different way internally, there are no standards for how browsers work internally and there is no such thing as a quarantine cache in any browser.
The only common feature in all browsers is that they send http requests to http servers at port 80, period - end of common features.
avast and others place a low level intercept in the operating system so that any requests (made by any process attempting to make a connection outbound to any server at port 80) is instead routed to the handler that avast has set up (in this case running at localhost port 12080). This passes the request to avast, avast then issues the request to the real server so that the results come back first to avast and can be scanned for infection. If the response in clean it is passed back to the browser - which was completely unaware of the intercept.
This all works perfectly well for all well known browsers.
It should work with torpark when we tell avast to intercept port 9050. I pretty much suspect that the developer has, as part of his concern for privacy, decided to ignore requests that are redirected to the tor process instead of coming directly from portable Firefox. After all - that redirect might be from code placed by a security agency. The same developer has effectively told users (in the quote I posted) that it does not matter that an antivirus product scan the results of the web accesses too. I can only suggest that this is an issue that you could take up directly with the product developer.
I doubt that one Web browser or one antivirus will be modified to work with torpark. The
major browsers are used by hundreds of millions, the antivirus products by at least tens of millions, torpark may attract a few thousand users. In the places where torpark will be really useful all access to the tor servers will be blocked, in other places it will probably be thought (however unreasonably) that anyone wanting to use torpark is doing so for unsavory or dangerous purposes. In any of these cases - major software developers will not want to be seen as catering to those causes.
Incidentally, your concept of a quarantine cache was one that the developers of Thunderbird came up with for email - apparently in total isolation and without consultation with antivirus producers. I have heard of it working with one antivirus product - all of my tests show it not working with any antivirus I have tried. The same developer of torpark has produced torbird - an email equivalent based on Thunderbird. Users of that may also find that their email cannot be scanned by an antivirus product too.
Just an afterthought.
I was pondering torpark over dinner.
I got involved in this thread, not because I want to use the product - it is far too slow for real use, but because it represented an interesting technical issue.
It occurs to me that I, and possibly cshinn101 too, have been looking at this from the wrong perspective.
I cannot know the incentive for the developer to create this product but I suspect that it may have been the challenge to develop a method of truly anonymous browsing that could be placed on a keychain USB device, relied on nothing but the Windows operating system of the host computer, could not be intercepted by software on the host computer and left no trace on the host computer when the USB device was removed.
If that was the technical challenge the developer was seeking to overcome then I think the result is actually quite successful and the developer is to be congratulated.
Again, I must not attempt to put words in the mouth of the developer but I think the response from the developer to a user, like cshinn101, would reflect the post of Smith above. If you want antivirus scanning of the web access results then you are free to install regular Firefox and regular tor. avast will be able to intercept the http accesses of Firefox before they go to tor for encryption and the results will be scanned on the way back. There you have the advantages of both Firefox and tor plus antivirus scanning while torpark is intended for those who want to guarantee almost total stealth and no traces at the expense of forgoing antivirus support.
Firstly I appreciate the responses of alanrf. It is always easier to formulate thoughts with informed combat ;).
As the enquirer it is my duty to be the guinea pig. I have installed & run tor with regular firefox. It gives exactly the same performance as torpark. All avast intercepts terminate at the tor directory servers.
Unless anyone else has a bright idea I guess I am SOL for achieving my goal :(.
I just downloaded regular Tor and I am running it now with the current production version of Firefox. I also installed the recommended Torbutton extension that gives you the ability to toggle Tor on and off. This sets up Privoxy as a proxy in the Firefox connection settings using localhost:8118
Then, in the avast Webshield I added port 8118 to the redirected ports and unchecked the “Ignore local communication” box.
Net result - Firefox web accesses are going through Tor and are also being scanned by avast.
Edit: interesting to see my post contains a completely different IP address from normal.
Thank you alanrf. This works for me too!