Block http authentician data attacks using Privoxy?

[Ahtiga Saraz]

I'm back!

@ eric:

browser.cache.disk_cache_ssl

Great idea! Unfortunately, it turned out I already had that set to false, as my default, even. I cautiously tried changing a few more things, but nothing works.

All these problems started with the most recent update of Tor for Lenny (oldstable) on 30 August, which is unfortunately in the frame for the genuine cert for add-ons.mozilla.org which was improperly issued to an imposter by DigiNotar. Among other things it wiped out my old /etc/tor/torrc which I had to try to carefully reconstruct. IMO, it is really disastrous when a security upgrade to a privacy tool actually degrades anonymity, but probably the Security Team would says its my own fault for not having figured out how to use Squeeze yet (because I can't get KDE to work, because I can't seem to get the nonfree firmware I need, and maybe also because that PC is running hot).

A few years ago, there was some reason why one should use socks4a rather than socks5, and even the most recent version of tor (for Lenny) suggests adding to /etc/privoxy/config the lines

Code: Select all

listen-address  127.0.0.1:8118
forward-socks4a / localhost:9050 .

But Torbutton shows socks5, and trying to change that to socks4 seems to break proxying entirely! So I tried using

Code: Select all

listen-address  127.0.0.1:8118
forward-socks5 / localhost:9050 .

Then I do at least seem to chain Tor to Privoxy, which is what I want.

@ anyone else is struggling with this:

You can check to see if privoxy is running and if not call

Code: Select all

/etc/init.d/privoxy start

and try again. If you enter

Code: Select all

http://www.privoxy.org/config/

into the Iceweasel/Firefox location pane, you should see the internal privoxy configuration page; if privoxy is not enabled you'll surf to the external website. If all is good so far, toggled torbutton "on" and look at your Iceweasel configuration in Advanced -> Settings. If you you see port 8118, that is the privoxy port. I think the most definitive test is to do

Code: Select all

sudo netstat -anp | grep tcp | sed 1d | column -t

when you surf. You should see privoxy passing requests to a temporary port and then on to port 9050, the tor port.

@eric:

Do you also see a /var/run/tor/control on your system?

Would you feel comfortable being a bit more explicit about this?:

I have also disabled MUCH of caching in about:config

You are using Iceweasel/Firefox, right? (Not Google Chromium?) Version? What Debian? You have installed NoScript? Anything you can share about its configuration? When you do about:config and filter by "proxy", by "cache", or by "auth", what do you see?

I get very inconsistent results. On two tests I did get the popup window saying

Code: Select all

A username and password are being requested by http://ip-check.info.  The site says "IP-Check Realm"

On two tests I got a popup window, which appears to be an http authentication window, saying

Code: Select all

Name:
Password:

Usually I don't get any popup windows (NoScript tries to block them).

I may have a better guess about the nature of this "http authentication attack" now. I now think it is unrelated to both certificates and the yaha "http authentication attack" tool, which tries to guess default passwords in web servers.

The php script at ip-check.info definitely seems to be able to trigger some actions in vulnerable browsers, even if you are running NoScript and have configured Iceweasel/Firefox very conservatively (more than enough to "break" most functions, but sufficient to surf). My current guess is that the attack does indeed involve an "http password" function which seems to be impossible to disable, at least in older Iceweasel/Firefox. The /var/log/tor/log consistently shows two entries of form

Code: Select all

[warn] Rejecting SOCKS request for anonymous connection to private address [scrubbed]

It seems that when you surf to

Code: Select all

ip-check.info/?lang=en

and just wait for a minute, the php script is partially run. If you click on the "click to start test" it runs a second time, more completely (among other things, it makes your browser connect to a long list of specific webwites), and eventually shows what I hope is a false positive. The first entry is associated with first time the test runs and the second entry with the second time it runs. The second entry is noted at the end of the second test.

I cannot figure out why you are getting the green light but I am (mostly) not--- if you are willing, I would be grateful if you note similar notations in your Tor log, and so forth. Even if you simply try running the test several more times to see if you really do get a green light each time.

I have never gotten the same "unique identifier", and I hope the rejection of the request for a private address (can't figure out what it is) show that no "pseudocookie" is actually getting into my system.

But I am still very concerned, because deanonymity could have devastating consequences for me. And it appears to be possible that the script is able to execute a hidden http authentication window which is only intermittently visible.

There should be some way to deactivate this http authentication entirely, at least when using Tor. But unless someone sees something I'm missing, it may be that only the Debian Security Team can provide a fix for Lenny users.

[datakraken]

Code: Select all

#################################################################################
#
# CSS-auth-tracking: protect against css-based authetification tracking demonstrated at ip-check.info 
#
#################################################################################
FILTER: css-auth-tracking Gets radically rid of CSS/HTML Authentification tracking attacks
s|http://.*\@|http://|gi
s|http://.*\@|http://|gi

add

+filter{css-auth-tracking} \

in your match-all.action file and the problem is gone

[datakraken]

I forgot one line:

Code: Select all

s|\<link(.*)href="(.*)\?(.*)"(.*)\>|\<link$1"http://$2"$4\>|gi

will transform

<link rel="stylesheet" type="text/css" href="http://ipcheck.info/auth.css.php?test=t ... &locale=en">

into

<link rel="stylesheet" type="text/css" href="http://ipcheck.info/auth.css.php">

This is prevents exacly what ip-check.info does (go there, type crtl+u and search for auth.css ...)

Rem: The first two lines (above) was their first version of the attack. Now they refined it a bit, but privoxy has full-Turing-power

[debianized]

I see someone already found a solution that I will probably use myself. I wanted to let you know this problem does not occur with Konqueror 4.6.5. I checked twice in the same session to verify the cache was not read and got green both times.

[Ahtiga Saraz]

Sorry for the very late reply, but after more checking, I think the red alerts I obtained may have been a false alarm caused by my browser not reacting as expected when intructed to load a script. By taking a different action I consistently get a green light with Iceweasel.

@ datakraken: I want to try that, but are you sure that you gave the correct name of the file I should alter? I am using oldstable with Privoxy 3.0.9 (I know, I know...)

I have found that Iceweasel with Torbutton/Noscript/Adblock Plus seems to give a good compromise between the desire for fairly anonymous browsing and the need for fairly secure browsing.

I sure wish someone would come up with a "Torbutton for Konqueror". This entails not simply browsing with Konqueror via Tor, but sending the browser identification sent by Firefox with Torbutton 1.4 (IE and Windows something or other). Did mozilla stop supporting torbutton as an add-on available at mozilla.org?

Anyone knowledgeable have an opinion on whether or not konqueror is potentially more anonymous/secure than Iceweasel?

Anyone have an opinion whether Tor with Privoxy is better than Tor with Vidalia?

[debianized]

I sure wish someone would come up with a "Torbutton for Konqueror". This entails not simply browsing with Konqueror via Tor, but sending the browser identification sent by Firefox with Torbutton 1.4 (IE and Windows something or other).

The solution for this is very easy. Edit the file /home/your-username/.kde4/share/config/kio_httprc to read as follows:

UseCache=true
UserAgent=Mozilla/5.0 (Windows NT 6.1; rv:10.0) Gecko/20100101 Firefox/10.0 <---this is the line you add
UserAgentKeys=:

After saving that file, go to Konqueror->Settings->Browser Identification and make sure "Send Identification," but nothing else, is checked.

Anyone knowledgeable have an opinion on whether or not konqueror is potentially more anonymous/secure than Iceweasel?

I woulid say less anonymous, if you go by Panopticlick results, because Konqueror identifies as one in 2.x million, whereas Iceweasel identifies as one in a couple of thousands, based on the data sent via the browser. Konqueror is far more unique and thus more easily identified.

However, you can get clean "Cache (E-Tags)" on the JonDoNym website with Konqueror with the following settings:

Konqueror->Settings->Cache->Use Cache->Use cache whenever possible, whereas, if you instead select "Keep cache in sync" the 'Cache (E-Tags)" setting will be red.

These results are on Gentoo with KDE 4.8.3, so your mileage may or may not vary, until Wheezy is released.