Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Block http authentician data attacks using Privoxy?

Graphical Environments, Managers, Multimedia & Desktop questions.
Message
Author
Ahtiga Saraz
Posts: 1014
Joined: 2009-06-15 01:19

Block http authentician data attacks using Privoxy?

#1 Post by Ahtiga Saraz »

Those who use Tor should know about a new attack on websurfers which could be dangerous for bloggers living near repressive countries.

For some time, the Tor project has favored using Tor chained to Polipo, a caching proxy. This reduces load on the tor network. But Polipo has had some information leakage problems in the past. Furthermore, the most recent update to Tor seems to have actually degraded anonymity.

It is possible to use Tor chained to Privoxy, and older proxy which can also block many nasty things. Does anyone know how to block the kind of style sheets used in http authentication data attacks? See http://ip-check.info/?lang=en
Ahtiga Saraz

Le peuple debout contre les tyrans! De l'audace, encore de l'audace, toujours l'audace!

Ahtiga Saraz
Posts: 1014
Joined: 2009-06-15 01:19

Warning!

#2 Post by Ahtiga Saraz »

I gave a link in the previous post to a site which offers to check the anonymity of your torified browser.

Unfortunately, I recently experienced an alarming anomaly there--- a message stated that some site was requesting me to log in and popup window with a username and password panel. (I was too startled to write down the site named before the messages vanished).

Has anyone else experience anything like that? I've never seen this before.
Ahtiga Saraz

Le peuple debout contre les tyrans! De l'audace, encore de l'audace, toujours l'audace!

User avatar
craigevil
Posts: 5391
Joined: 2006-09-17 03:17
Location: heaven
Has thanked: 28 times
Been thanked: 39 times

Re: Block http authentician data attacks using Privoxy?

#3 Post by craigevil »

https://check.torproject.org/

I always use Privoxy with Tor, it is a bit slower than Polipo but why would I want to cache websites on my computer when I run Tor so people won't know . :)

BTW it is best to use Tor with the torbutton extension with Firefox, also a good idea to use the HTTPS Everywhere extension from EFF.

[*]HTTPS Finder 0.69
[*]HTTPS-Everywhere 1.0.1
[*]Torbutton 1.4.1

For various Privoxy settings take a loook at:
Privoxy 3.0.17 User Manual - http://www.privoxy.org/user-manual/index.html
Actions Files - http://www.privoxy.org/user-manual/acti ... T-EXAMPLES
Raspberry PI 400 Distro: Raspberry Pi OS Base: Debian Sid Kernel: 5.15.69-v8+ aarch64 DE: MATE Ram 4GB
Debian - "If you can't apt install something, it isn't useful or doesn't exist"
My Giant Sources.list

Ahtiga Saraz
Posts: 1014
Joined: 2009-06-15 01:19

Re: Block http authentician data attacks using Privoxy?

#4 Post by Ahtiga Saraz »

I also use Privoxy, for similar reasons. (I have also found that Privoxy sometimes throws up some useful warnings, which Polipo might miss--- one of the most interesting was a warning showing that a page I was visiting was trying to plant nasty spyware--- the culprit was a spyco which nominally was trying to check its own targeted advertising for accuracy by in effect "temporarily" trojaning my browser, which should be illegal.)

But I think the Tor developers favor Polipo because it puts less stress on the Tor network. I suppose users must make indidivual judgements about what risks they may face and how they want to weigh various considerations.

When I get to it, I plan to try to figure out how to tunnel Tor through Privoxy under Squeeze, so thanks for those links.

I use Torbutton (with Iceweasel), and only rarely turn it "off".

I love the EFF and the work that they do, but I have some concerns about HTTPS everywhere. When I tried installing it and visited the site mentioned in my previous post, it seemed that this one change had degraded anonymity, for reasons I don't yet understand. It was when I was trying to experiment further that I encountered the troubling anomaly mentioned above. I definitely should not have seen a login popup. Any ideas on what that might have been? (I realize that because I was too shocked to write down the site mentioned before it vanished, I don't even know precisely what I saw, much less what happened.)

I'd be very interested to hear what others experience at anonymity testing sites, but I'd recommend using a live CD designed for torified browsing until we better understand what that particular site may be doing.

I am concerned that applications such as the ABE WAN enforcer (turned on by default in NoScript) which try to guard against MITM attacks, could be used to track Tor users. Here is what the NoScript site said when this feature was introduced;

Code: Select all

NoScript 2.0rc5 and above extends its protection against DNS rebinding to those attacks which specifically target your router's external (WAN) IP address. In order to protect it, NoScript needs to detect the WAN IP currently exposed  to internet web sites by your HTTP requests: for this purpose, NoScript sends a completely anonymous query to the https:secure.informaction.com/ipecho web service, which provides back this information on a secure channel, typically once a day. Again, no data except the aforementioned WAN IP address travels on the secure channel, and no user data at all is collected, nor stored, nor shared nor reused by InformAction or any other party.  This feature, enabled by default, can be disabled by unchecking "NoScript Options|Advanced|ABE|WAN IP ∈ LOCAL".
So if you use this feature (which is clearly valuable!) you are placing a huge amount of trust in G. Maone. (I keep it off, but sometimes consider temporarily turning it back on to try to detect possible problems.) Does anyone know what Maone means by "secure channel"? For Tor users, SSL might be preferable to TLS.

Applications which try to look up certs could probably be used to track Tor users, unless they have been able to torify ocsp lookup. I am not sure I even know how to verify that this is happening on my PC, if it is.

I have the impression that at present, Tor users face a troubling choice between improved security and improved anonymity.
Ahtiga Saraz

Le peuple debout contre les tyrans! De l'audace, encore de l'audace, toujours l'audace!

debianized
Posts: 278
Joined: 2009-01-07 07:56

Re: Block http authentician data attacks using Privoxy?

#5 Post by debianized »

Ahtiga Saraz wrote:Does anyone know how to block the kind of style sheets used in http authentication data attacks? See http://ip-check.info/?lang=en
I surf through a privoxy--->tor chain and do not receive the authentication window on that website, but I surf with javascript and all plugins turned off. You have hit on one of my favorite of all sites to check such things. For an interesting experiment, proxy chromium via privoxy & tor, visit that link, then click on the test offered on that page. You will learn that chromium is NOT AT ALL anonymous, even when behind privoxy and tor.

Just don't make the mistake I made of inadvertently checking a bank account online through tor. The next day, that account was blocked from online access. I received a call from the fraud department of the bank. They were a bit concerned of three logins the previous day from two states on opposite sides of the country and one login from Russia.

OOPS!

User avatar
craigevil
Posts: 5391
Joined: 2006-09-17 03:17
Location: heaven
Has thanked: 28 times
Been thanked: 39 times

Re: Block http authentician data attacks using Privoxy?

#6 Post by craigevil »

Use Torbutton with Iceweasel/Firefox
Tor Project: Torbutton Options - https://www.torproject.org/torbutton/to ... ns.html.en

Code: Select all

Torbutton Options

Torbutton 1.2.0 adds several new security features to protect your anonymity from all the major threats we know about. The defaults should be fine (and safest!) for most people, but in case you are the tweaker type, or if you prefer to try to outsource some options to more flexible extensions, here is the complete list. (In an ideal world, these descriptions should all be tooltips in the extension itself, but Firefox bugs 45375 and 218223 currently prevent this.)

    Disable plugins on Tor Usage (crucial)

    This option is key to Tor security. Plugins perform their own networking independent of the browser, and many plugins only partially obey even their own proxy settings.
    Isolate Dynamic Content to Tor State (crucial)

    Another crucial option, this setting causes the plugin to disable Javascript on tabs that are loaded during a Tor state different than the current one, to prevent delayed fetches of injected URLs that contain unique identifiers, and to prevent meta-refresh tags from revealing your IP when you turn off Tor. It also prevents all fetches from tabs loaded with an opposite Tor state. This serves to block non-Javascript dynamic content such as CSS popups from revealing your IP address if you disable Tor.
    Hook Dangerous Javascript (crucial)

    This setting enables the Javascript hooking code. Javascript is injected into pages to hook the Date object to mask your timezone, and to hook the navigator object to mask OS and user agent properties not handled by the standard Firefox user agent override settings.
    Resize window dimensions to multiples of 50px on toggle (recommended)

    To cut down on the amount of state available to fingerprint users uniquely, this pref causes windows to be resized to a multiple of 50 pixels on each side when Tor is enabled and pages are loaded.
    Disable Updates During Tor (recommended)

    Under Firefox 2, many extension authors did not update their extensions from SSL-enabled websites. It is possible for malicious Tor nodes to hijack these extensions and replace them with malicious ones, or add malicious code to existing extensions. Since Firefox 3 now enforces encrypted and/or authenticated updates, this setting is no longer as important as it once was (though updates do leak information about which extensions you have, it is fairly infrequent).
    Disable Search Suggestions during Tor (optional)

    This optional setting governs if you get Google search suggestions during Tor usage. Since no cookie is transmitted during search suggestions, this is a relatively benign behavior.
    Block Livemarks updates during Tor usage (recommended)

    This setting causes Torbutton to disable your Live bookmark updates. Since most people use Live bookmarks for RSS feeds from their blog, their friends' blogs, the wikipedia page they edit, and other such things, these updates probably should not happen over Tor. This feature takes effect in Firefox 3.5 and above only.
    Block Tor/Non-Tor access to network from file:// urls (recommended)

    These settings prevent local html documents from transmitting local files to arbitrary websites under Firefox 2. Since exit nodes can insert headers that force the browser to save arbitrary pages locally (and also inject script into arbitrary html files you save to disk via Tor), it is probably a good idea to leave this setting on.
    Close all Non-Tor/Tor windows and tabs on toggle (optional)

    These two settings allow you to obtain a greater degree of assurance that after you toggle out of Tor, the pages are really gone and can't perform any extra network activity. Currently, there is no known way that pages can still perform activity after toggle, but these options exist as a backup measure just in case a flaw is discovered. They can also serve as a handy 'Boss Button' feature for clearing all Tor browsing off your screen in a hurry.
    Isolate access to history navigation to Tor state (crucial)

    This setting prevents both Javascript and accidental user clicks from causing the session history to load pages that were fetched in a different Tor state than the current one. Since this can be used to correlate Tor and Non-Tor activity and thus determine your IP address, it is marked as a crucial setting.
    Block History Reads during Tor (crucial)

    Based on code contributed by Collin Jackson, when enabled and Tor is enabled, this setting prevents the rendering engine from knowing if certain links were visited. This mechanism defeats all document-based history disclosure attacks, including CSS-only attacks.
    Block History Reads during Non-Tor (recommended)

    This setting accomplishes the same but for your Non-Tor activity.
    Block History Writes during Tor (recommended)

    This setting prevents the rendering engine from recording visited URLs, and also disables download manager history. Note that if you allow writing of Tor history, it is recommended that you disable non-Tor history reads, since malicious websites you visit without Tor can query your history for .onion sites and other history recorded during Tor usage (such as Google queries).
    Block History Writes during Non-Tor (optional)

    This setting also disables recording any history information during Non-Tor usage.
    Clear History During Tor Toggle (optional)

    This is an alternate setting to use instead of (or in addition to) blocking history reads or writes.
    Block Password+Form saving during Tor/Non-Tor

    These options govern if the browser writes your passwords and search submissions to disk for the given state.
    Block Tor disk cache and clear all cache on Tor Toggle

    Since the browser cache can be leveraged to store unique identifiers, cache must not persist across Tor sessions. This option keeps the memory cache active during Tor usage for performance, but blocks disk access for caching.
    Block disk and memory cache during Tor

    This setting entirely blocks the cache during Tor, but preserves it for Non-Tor usage.
    Clear Cookies on Tor Toggle

    Fully clears all cookies on Tor toggle.
    Store Non-Tor cookies in a protected jar

    This option stores your persistent Non-Tor cookies in a special cookie jar file, in case you wish to preserve some cookies. Based on code contributed by Collin Jackson. It is compatible with third party extensions that you use to manage your Non-Tor cookies. Your Tor cookies will be cleared on toggle, of course.
    Store both Non-Tor and Tor cookies in a protected jar (dangerous)

    This option stores your persistent Tor and Non-Tor cookies separate cookie jar files. Note that it is a bad idea to keep Tor cookies around for any length of time, as they can be retrieved by exit nodes that inject spoofed forms into plaintext pages you fetch.
    Manage My Own Cookies (dangerous)

    This setting allows you to manage your own cookies with an alternate extension, such as CookieCuller. Note that this is particularly dangerous, since malicious exit nodes can spoof document elements that appear to be from sites you have preserved cookies for (and can then do things like fetch your entire gmail inbox, even if you were not using gmail or visiting any google pages at the time!).
    Do not write Tor/Non-Tor cookies to disk

    These settings prevent Firefox from writing any cookies to disk during the corresponding Tor state. If cookie jars are enabled, those jars will exist in memory only, and will be cleared when Firefox exits.
    Disable DOM Storage during Tor usage (crucial)

    Firefox has recently added the ability to store additional state and identifiers in persistent tables, called DOM Storage. Obviously this can compromise your anonymity if stored content can be fetched across Tor-state.
    Clear HTTP auth sessions (recommended)

    HTTP authentication credentials can be probed by exit nodes and used to both confirm that you visit a certain site that uses HTTP auth, and also impersonate you on this site.
    Clear cookies on Tor/Non-Tor shutdown

    These settings install a shutdown handler to clear cookies on Tor and/or Non-Tor browser shutdown. It is independent of your Clear Private Data settings, and does in fact clear the corresponding cookie jars.
    Prevent session store from saving Tor-loaded tabs (recommended)

    This option augments the session store to prevent it from writing out Tor-loaded tabs to disk. Unfortunately, this also disables your ability to undo closed tabs. The reason why this setting is recommended is because after a session crash, your browser will be in an undefined Tor state, and can potentially load a bunch of Tor tabs without Tor. The following option is another alternative to protect against this.
    On normal startup, set state to: Tor, Non-Tor, Shutdown State

    This setting allows you to choose which Tor state you want the browser to start in normally: Tor, Non-Tor, or whatever state the browser shut down in.
    On crash recovery or session restored startup, restore via: Tor, Non-Tor

    When Firefox crashes, the Tor state upon restart usually is completely random, and depending on your choice for the above option, may load a bunch of tabs in the wrong state. This setting allows you to choose which state the crashed session should always be restored in to.
    Prevent session store from saving Non-Tor/Tor-loaded tabs

    These two settings allow you to control what the Firefox Session Store writes to disk. Since the session store state is used to automatically load websites after a crash or upgrade, it is advisable not to allow Tor tabs to be written to disk, or they may get loaded in Non-Tor after a crash (or the reverse, depending upon the crash recovery setting, of course).
    Set user agent during Tor usage (crucial)

    User agent masking is done with the idea of making all Tor users appear uniform. A recent Firefox 2.0.0.4 Windows build was chosen to mimic for this string and supporting navigator.* properties, and this version will remain the same for all TorButton versions until such time as specific incompatibility issues are demonstrated. Uniformity of this value is obviously very important to anonymity. Note that for this option to have full effectiveness, the user must also allow Hook Dangerous Javascript ensure that the navigator.* properties are reset correctly. The browser does not set some of them via the exposed user agent override preferences.
    Spoof US English Browser

    This option causes Firefox to send http headers as if it were an English browser. Useful for internationalized users.
    Don't send referrer during Tor Usage

    This option disables the referrer header, preventing sites from determining where you came from to visit them. This can break some sites, however. Digg in particular seemed to be broken by this. A more streamlined, less intrusive version of this option should be available eventually. In the meantime, RefControl can provide this functionality via a default option of Forge.

 
Also take a look at Torbutton Design Documentation - https://www.torproject.org/torbutton/en/design/#attacks
doc/FireFoxTorPerf – Tor Bug Tracker & Wiki - https://trac.torproject.org/projects/to ... FoxTorPerf

from that other debian forum:
craigevil wrote:Research problem: measuring the safety of the Tor network | The Tor Blog : https://blog.torproject.org/blog/resear ... or-network

Is TOR Safe To Use? - Black Hat Forum Black Hat SEO : http://www.blackhatworld.com/blackhat-s ... e-use.html

tor network safety | The Tor Blog : https://blog.torproject.org/category/ta ... ork-safety

Encrypt the Web with HTTPS Everywhere | Electronic Frontier Foundation : https://www.eff.org/press/archives/2011/08/04

Tor even works on my android phone. Just install the orbot app.
Raspberry PI 400 Distro: Raspberry Pi OS Base: Debian Sid Kernel: 5.15.69-v8+ aarch64 DE: MATE Ram 4GB
Debian - "If you can't apt install something, it isn't useful or doesn't exist"
My Giant Sources.list

Ahtiga Saraz
Posts: 1014
Joined: 2009-06-15 01:19

http authentication data attack-- what IS it anyway?

#7 Post by Ahtiga Saraz »

@debianized:
I surf through a privoxy--->tor chain ... I surf with javascript ... turned off.
Me too!
and all plugins [turned off]
Referring to a setting in the Torbutton configuration? I checked that too, but AFAIK it doesn't turn off the NoScript add-on. I am not sure I understand the difference, if any, between a plug-in and an Iceweasel/Firefox add-on.

I've only been playing with that site for a few days and I have noticed that I get inconsistent results. The "unique identifier" seems to be always different (whew!) but also does not seem to be correlated with the Tor exit node. Yanking the cable, killing Iceweasel, waiting five seconds, restarting it, plugging back in the cable, and reconnecting to the Tor network seems to prevent the alleged "http authentication data" attack, but slows down webbrowsing, since it takes a few minutes to complete this process.

Do you know if ip-check.info is associated with jondos.de? (The jondos anonymity checker now redirects to the apparently almost identical anonymity checker at ip-check.info.) I assume that it is.

Years ago I played with Jondos but didn't really get it to work. And like Tor, Jondos is tarred by connections with "Western" intelligence agencies. (Tor was originally developed by the US Naval Research Laboratory, and still gets some funding from US military. And years ago Jondos had to admit they'd passed some logs to the German secret service.)

@craigevil:

I seem to have a later version of Torbutton than 1.2.0 but an older version of Iceweasel (I am using one up-to-date for Lenny), which is probably why my Torbutton options are significantly different. I have however made careful and I hope good choices in configuring Torbutton, Iceweasel, etc.

You linked to some https pages at torproject.org. Did you know that torproject.org has been named as one of the domains targeted by "Ich Sun", aka "Comodo Hacker"?

@all:

Interesting that we are all three using Privoxy rather than Polipo, for the same reason: enhanced security (we hope) at the price of some degradation of speed. I have tried to argue that the majority of Tor users probably feel this way, and that the developers should consider increasing the number of hops from 2 to 3 (for example), i.e. from 3 to 4 Tor nodes in each chain. But the developers don't seem to agree.

Does anyone have any idea how to torify ocsp lookup and (harder?) how to check that it's working?

On my Torbutton options allow to try to torify gopher and ftp, but I don't think that helps. At present, I am not at all sure that contacting any https site while using Tor is really safe.

Does anyone know what is this alleged "http authentication data" attack on anonymous-surfing?
Ahtiga Saraz

Le peuple debout contre les tyrans! De l'audace, encore de l'audace, toujours l'audace!

debianized
Posts: 278
Joined: 2009-01-07 07:56

Re: http authentication data attack-- what IS it anyway?

#8 Post by debianized »

Ahtiga Saraz wrote: Referring to a setting in the Torbutton configuration?
No. I surf with all of those things turned off as a rule, including search suggestions, type ahead, and always delete those boomarket thingies when I first set up the browser. Https Everywhere is the only Firefox extension I use all of the time.
Ahtiga Saraz wrote: Do you know if ip-check.info is associated with jondos.de? (The jondos anonymity checker now redirects to the apparently almost identical anonymity checker at ip-check.info.) I assume that it is.
I assume it is, but have never actually bothered to check for sure.
Ahtiga Saraz wrote: Years ago I played with Jondos but didn't really get it to work.
It could be executed by the user only, without having to install it system wide.
Ahtiga Saraz wrote: Interesting that we are all three using Privoxy rather than Polipo, for the same reason: enhanced security (we hope) at the price of some degradation of speed..
Actually, I got into privoxy originally because it was the successor to the junk buster proxy. The advertisers particularly ticked me off in the days of dialup and junkbuster was the original way to block the ads. I've always preferred squid to speed up internet connections, although I dare not use it with tor since I couldn't be sure it would leak dns requests. I do have tordns running on port 53 for dns resolution via tor. If I could figure out command line iptables (denying all both in and out, while allowing only specific connections out), I would love to test squid against tordns to see if it would work. If so, then the ideal configuration would be pdnsd--->tordns, with a squid3--->privoxy--->tor chain, which should speed things up considerably but also insure squid3 wasn't hitting dns servers outside of tor, particularly if port 53 is specifically blocked outbound by iptables, (while also convenently preventing squid3 from caching ads!).
Ahtiga Saraz wrote: On my Torbutton options allow to try to torify gopher and ftp, but I don't think that helps.
Was it the Galeon browser that used to allow us to set a separate app (prozilla) for downloading? I wonder if you could have Firefox call a separate app for all downloads, and have that separate app preconfigured for tor. That should work at least for ftp, I would think.
Ahtiga Saraz wrote: At present, I am not at all sure that contacting any https site while using Tor is really safe.
My concern is not so much for safety as anonymity, although I feel MUCH safer with encrypted connections via ssl, even if it's certainly not anonymous, since the connection itself could be seen, even if the data on the connection could not be read.
Ahtiga Saraz wrote: Does anyone know what is this alleged "http authentication data" attack on anonymous-surfing?
Isn't the authentication window produced by the code on that page, much like the ftp connection is? This page is another examlpe of the same.

Ahtiga Saraz
Posts: 1014
Joined: 2009-06-15 01:19

Re: Block http authentician data attacks using Privoxy?

#9 Post by Ahtiga Saraz »

OK, I think I am beginning to get the general idea. I should have noticed that the url changed when I executed the test script, which is a php script at the test site. The "http authentication attack" uses the fact that this php script can make my browser send "auth" data; the "unique identifier" is the first part of this auth data. It seems to involve the request time and maybe some other stuff.

@debianized:
Isn't the authentication window produced by the code on that page, much like the ftp connection is? This page is another examlpe of the same.
Agree that the authentication attack appears to be produced by php script forcing "auth" data, although I still don't understand what that is about. I know the page you mean at browserspy, and what I saw was similar, but it only happened once, so I don't think the php script was to blame.

In my tests, I seem to be given a different unique identifier each time by the test site, but if I understand correctly, this might not be true for a malicious server running a similar php script.

I haven't yet figured out any way to block this, but if it were possible to block php scripts including "auth=" that would be worth trying. I don't yet have a clue how to get Privoxy to do that.

@all:
Any ideas, anyone?

@debianized:
No. I surf with all of those things turned off as a rule, including search suggestions, type ahead, and always delete those boomarket thingies when I first set up the browser.
I think we are misunderstanding each other. From what you say, it sounds like we are trying to obtain similar configurations which attempt to optimize anonymity at the expense of speed... where we differ might be trying to optimize anonmyity at the expense of some security features like ABE WAN ip enforcer in Noscript configuration (which I tend to keep turned off).
It could be executed by the user only, without having to install it system wide.
Been a couple of years, but I think I tried installing it as my ordinary user from the tarball.
I've always preferred squid to speed up internet connections, although I dare not use it with tor since I couldn't be sure it would leak dns requests.
In your /etc/tor/torrc try adding the lines

Code: Select all

SafeSocks 1
TestSocks 1
Then

Code: Select all

tail -n 25 /var/log/tor/log
and you should see "Your application (using socks4a to port 80) gave Tor a hostname, which means Tor will do the DNS resolve for you. This is good".

I am about to try something new with my test Squeeze and I'll get back to you.

Code: Select all

My concern is not so much for safety as anonymity
Sounds like we are making similar tough choices, which expose us to "Ich Sun". I guess we just have to monitor Tor in real time.

I guess you do not use a Tor controller? These seem to be very problematic in my experience. Not only do they seem to always have many security problems, even worse, they seem to degrade anonmity dangerously.

Have you tried any of the live CDs which claim to offer anonymous browsing via Tor in an emergency, if your system is in trouble and you need to quickly check something "independently"? One problem I've noted
  • they tend to use Firefox with appalling configuration wrt anonymity
  • those which use pre-loaded add-ons use appalling configurations of those add-ons
  • they tend to make it very hard to set the correct system time, which guarantees problems using Tor
No-one has really said anything about whether or not OCSP lookups while browsing with Tor to https sites could expose one to tracking, but I assume it would. If so, in many cases it might be better to use an http connection. I'd love to hear what the authors have to say about this, but I fear that using HTTPS Everywhere, Monkeysphere, etc., could be really bad for anonymity.

Stick around for a while, please, I want to try something and ask your opinion in an hour or so.
Ahtiga Saraz

Le peuple debout contre les tyrans! De l'audace, encore de l'audace, toujours l'audace!

debianized
Posts: 278
Joined: 2009-01-07 07:56

Re: Block http authentician data attacks using Privoxy?

#10 Post by debianized »

Ahtiga Saraz wrote: I haven't yet figured out any way to block this, but if it were possible to block php scripts including "auth=" that would be worth trying. I don't yet have a clue how to get Privoxy to do that..
Since privoxy blocks ads as follows:

# Block any URLs that match these patterns
{+block}
ad*.
.*ads.
banner?.
/.*count(er)?\.(pl|cgi|exe|dll|asp|php[34]?)
.hitbox.com

It should be possible to {+block} "auth=" or whatever variants of that might be necessary {*auth=}, {auth=*}, {*auth=*} and it looks from the above like you could somehow tag the block with php as well.
Ahtiga Saraz wrote: In your /etc/tor/torrc try adding the lines

Code: Select all

SafeSocks 1
TestSocks 1
Then

Code: Select all

tail -n 25 /var/log/tor/log
and you should see "Your application (using socks4a to port 80) gave Tor a hostname, which means Tor will do the DNS resolve for you. This is good".
Could I be sure squid is using tor and only tor for dns resolution or could squid still be bypassing tor in some instances, which tailing the log wouldn't show?
Ahtiga Saraz wrote: I guess you do not use a Tor controller?.
I don't. I try to turn off all features shown in the ui which could compromise anonymity, in combination with altering about:config in ways to hopefully increase privacy as well. I keep two profiles, one for privacy and one without. Since extensions can also compromise privacy, i only use the https everywhere extension in the privacy profile.
Ahtiga Saraz wrote: These seem to be very problematic in my experience. Not only do they seem to always have many security problems, even worse, they seem to degrade anonmity dangerously..
The tor controller seems to bog down the ui, but also seems redundant to me. If I surf with all javascript, extensions (except https everywhere) and plugins disabled, what would be the need for the tor controller? I guess what I am trying to do is acheive what the controller does, without the use of the controller itself. The only problem with that is, the online references for the controller, don't refer to the latest browser version I am using.
Ahtiga Saraz wrote: Have you tried any of the live CDs which claim to offer anonymous browsing via Tor in an emergency, if your system is in trouble and you need to quickly check something "independently"?
I've run Tails in Virtualbox, but that's it.
Ahtiga Saraz wrote: One problem I've noted
  • they tend to use Firefox with appalling configuration wrt anonymity
  • those which use pre-loaded add-ons use appalling configurations of those add-ons
  • they tend to make it very hard to set the correct system time, which guarantees problems using Tor
.
I don't trust so many of the add-ons either, because I can't be sure what they are doing or how they operate.
Ahtiga Saraz wrote: No-one has really said anything about whether or not OCSP lookups while browsing with Tor to https sites could expose one to tracking, but I assume it would. If so, in many cases it might be better to use an http connection. I'd love to hear what the authors have to say about this, but I fear that using HTTPS Everywhere, Monkeysphere, etc., could be really bad for anonymity.
The following are the OCSP settings in about:config for Firefox 6:

security.OCSP.enabled
security.OCSP.required
services.snyc.prefs.sync.security.OCSP.diable_button.managecrl
services.snyc.prefs.sync.security.OCSP.enabled
services.snyc.prefs.sync.security.OCSP.require

Would setting the first and last two above to false make any difference?
Ahtiga Saraz wrote: Stick around for a while, please, I want to try something and ask your opinion in an hour or so.
Ehh, I am not even sure I understand much of this, so probably won't be much help here.

Ahtiga Saraz
Posts: 1014
Joined: 2009-06-15 01:19

HTTPS Everywhere: not suitable for Tor users?

#11 Post by Ahtiga Saraz »

That's a great idea, and I'll try it.

Are you sure you are not running a controller and just don't know it yet? The most recent security update for Tor in old-stable (Lenny) (it may be relevant that I added torproject.org to my /etc/apt/sources.list so I should be as up to date as possible given Lenny constraints) had major effects:
  • significantly changed logging in several ways (not neccessarily welcome)
  • wiped my old /etc/tor/torrc
  • introduced a /var/run/tor/controller
I don't. I try to turn off all features shown in the ui
Sorry, I'm still confused by what you are referring to. Do you mean the GUI (graphical user interface) for... Torbutton configuration?
I keep two profiles, one for privacy and one without.
For Iceweasel/Firefox? I never really figured out how to do that.
Since extensions can also compromise privacy, i only use the https everywhere extension in the privacy profile.
What about the concern I have tried to raise repeatedly, that OCSP lookup may not be torified and thus may enable easy tracking of Tor users as they surf to https websites? Also, how confident can we be that cert lookup is still strong immunization against browser hijacking?
The tor controller seems to bog down the ui, but also seems redundant to me. If I surf with all javascript, extensions (except https everywhere) and plugins disabled, what would be the need for the tor controller?
Agreed. I'd like to see settings in Torbutton allowing one to chain Privoxy or Polipo to Tor, maybe even some security settings ranging from "beginner" to "paranoid", with the paranoid setting using the minimum of add-ons. It's possible that I shouldn't use NoScript, since I disable Javascript and image loading globally, but so far I have chosen to use it with the problematic ABE WAN IP Enforcer and some other default features disabled.
I don't trust so many of the add-ons either, because I can't be sure what they are doing or how they operate.
I love all the good work done by the EFF, but I mistrust Google and Comcast, both of which have been caught implementing clandestine and (IMO) horrific intrusions into the lives of tens of millions of people at a minimum (in particular, the Google WiFi packet snarfing scandal affected everyone who uses a WiFi router in the UK, and probably a good fraction of WiFi users in dozens of other countries worldwide), and it worries me that one of the two recent papers is a colloration between EFF, Google, and Comcast. So unfortunately I have unresolved concerns about Tor Users trying to use HTTPS Everywhere.
I am not even sure I understand much of this, so probably won't be much help here.
You're too modest, I've found your suggestions very helpful even when I have doubts.

Haven't yet tried that thing because I've been trying to deal with other problems which came up.
Ahtiga Saraz

Le peuple debout contre les tyrans! De l'audace, encore de l'audace, toujours l'audace!

debianized
Posts: 278
Joined: 2009-01-07 07:56

Re: Block http authentician data attacks using Privoxy?

#12 Post by debianized »

Ahtiga Saraz wrote:That's a great idea, and I'll try it.
The userprefs.js OSCP toggles don't seem to change the authentication issue, at least not judging from the ip-check.info site.
Ahtiga Saraz wrote: Are you sure you are not running a controller and just don't know it yet? The most recent security update for Tor in old-stable (Lenny) (it may be relevant that I added torproject.org to my /etc/apt/sources.list so I should be as up to date as possible given Lenny constraints) had major effects:
  • significantly changed logging in several ways (not neccessarily welcome)
  • wiped my old /etc/tor/torrc
  • introduced a /var/run/tor/controller
I think I misunderstood what you were referencing when you discussed the controller. I thought that referred to the Vidalia Tor Button, rather than in built capabilities of tor itself, which the Tor button could alter.
Ahtiga Saraz wrote: Sorry, I'm still confused by what you are referring to. Do you mean the GUI (graphical user interface) for... Torbutton configuration?
HA! The confusion is all mine, I assure you. Yes, instead of using tor button, I try to set maximum privacy/anonymity settings in Firefox->Edit->Preferences ui, and then turn to the userprefs.js in about:config.
Ahtiga Saraz wrote: For Iceweasel/Firefox? I never really figured out how to do that.
It requires either a customized menu entry on your menus or a customized desktop entry in /usr/share/applications/. Change the exec line from firefox' (or iceweasel) to 'firefox -ProfileManager.' You can easily figure it out from there.
Ahtiga Saraz wrote: What about the concern I have tried to raise repeatedly, that OCSP lookup may not be torified and thus may enable easy tracking of Tor users as they surf to https websites?.
That's what I don't understand. I understand your concern, but I don't understand how this would compromise our anonymity, even after having read the info about this on the JonDo website. Since I don't even understand how the compromise would work, I am not sure how one would go about tracking down a cure or setting(s) to prevent it.

On the other hand, what if these lookups are like phishing attacks, and our only option is to take our chances until the browsers themselves have built in protection against it?
Ahtiga Saraz wrote: Also, how confident can we be that cert lookup is still strong immunization against browser hijacking?
I wonder how much of a risk this is. The JonDo site sells a service after all. And the test site that points out the risks says it 'may'' lead to such and such. Is it something we really should be concerned about, or are they pulling the fear chain to sell a product?
Ahtiga Saraz wrote: I love all the good work done by the EFF, but I mistrust Google and Comcast, both of which have been caught implementing clandestine and (IMO) horrific intrusions into the lives of tens of millions of people at a minimum (in particular, the Google WiFi packet snarfing scandal affected everyone who uses a WiFi router in the UK, and probably a good fraction of WiFi users in dozens of other countries worldwide), and it worries me that one of the two recent papers is a colloration between EFF, Google, and Comcast.
I trust the EFF. I dont' trust Google, Comcast or any other corporations because they care about the bottom line, not our privacy. Given the EFF backs both tor and HTTPS Everywhere, I would hope tor and the extension would play well together.
Ahtiga Saraz wrote: So unfortunately I have unresolved concerns about Tor Users trying to use HTTPS Everywhere.
Have you contacted the EFF about your concerns, or posed questions to them about this? I would be curious to see their response, particularly given that they recommend both tor and the extension. It might be worth it to pose the question to the tor project as well.

Ahtiga Saraz
Posts: 1014
Joined: 2009-06-15 01:19

Re: Block http authentician data attacks using Privoxy?

#13 Post by Ahtiga Saraz »

even after having read the info about this on the JonDo website
Could be important: earlier this year, when I went to the anonymity tool at jondos.de, I started to be redirected to ip-check.info. If that hasn't been happening to you, I have even more problems than I thought.
The JonDo site sells a service after all. And the test site that points out the risks says it 'may'' lead to such and such. Is it something we really should be concerned about, or are they pulling the fear chain to sell a product?
A natural question, which as you probably sensed had also occurred to me.

I have a guess: is it possible that this PHP script with an auth= command, hosted at an https site, forces our browser to create a personalized certificate which can then be grabbed during a later visit to the same site or the website of confederates? Is that perhaps the nature of the "authentication data attack"?

I have noticed a trend recently towards https but to my dismay only some of that seems to be related to the legitimate reasons cited by the EFF for running https (e.g. this forum should ideally be run as an https site, if only to provide modest security for username/passwords and uploaded/downloaded PMs which otherwise would be transmitted in the clear). The rest seems to be motivated by spying schemes leveraging certificates in some manner I don't yet understand. But that's just a hunch.
Have you contacted the EFF about your concerns, or posed questions to them about this? I would be curious to see their response, particularly given that they recommend both tor and the extension. It might be worth it to pose the question to the tor project as well.
It is almost impossible to contact a reporter or civil rights group safely. Amazing but true: very few "Western" reporters are willing to use encryption; they seem to have been terrified by their own security services into abjuring it. Yet encryption was created precisely for sensitive communications between reporters and sources, political representatives and constituents, labor organizers and laborers...

Your comments are very interesting, I hope to have more to say later. I need to get some sleep first, though...
Ahtiga Saraz

Le peuple debout contre les tyrans! De l'audace, encore de l'audace, toujours l'audace!

debianized
Posts: 278
Joined: 2009-01-07 07:56

Re: Block http authentician data attacks using Privoxy?

#14 Post by debianized »

Ahtiga Saraz wrote: I have a guess: is it possible that this PHP script with an auth= command, hosted at an https site, forces our browser to create a personalized certificate which can then be grabbed during a later visit to the same site or the website of confederates? Is that perhaps the nature of the "authentication data attack"?
I am not sure exactly how it works, but this is why I question the information on the JonDo site. In the section marked Details of the attack it begins:

1. "If JavaScript is allowed, attacks on web proxies are quite easy...."

By the third paragraph of the same section:

2. "However, this disqualifies web proxies for general web surfing, as sooner or later you will need JavaScript in order to use the sites you want. "

So, this attack begins by turning javascript on (1) and since you know you will HAVE to turn Javascript on sooner or later (2), you can only escape this attack by means of the JonDo proxy. For me, the problem with the logic is, if I need to turn javascript on, I switch browser profiles, which means I won't be subject to the attack while surfing through tor, because I won't be hiding my real ip to begin with.

Additionally, on another page discussing the same attack:

"You will find a demonstration of this technique on the web site ip-check.info."

What interests me here is, there is no demonstration of this attack. Or at least, as long as javascript is turned off, the authentication window does not appear and my real ip is not revealed. Yet, another attack does appear on the website when you check, if you surf tor via Chromium, because your real ip and your tor ip are displayed to demonstrate that attack. So I don't personally worry about the authentication attack, since it is only possible if javascript is turned on, and the website fails to reveal my real ip by means of the attack, when it clearly succeeds at doing so in the case of tor->Chromium->ftp.
Ahtiga Saraz wrote: this forum should ideally be run as an https site, if only to provide modest security for username/passwords and uploaded/downloaded PMs which otherwise would be transmitted in the clear).


This brings up other concerns of mine regarding these certs, although your point in this is clear and well founded regardless. The gentoo forums do require a cert and are encrypted. However, the cert used on the website appears as 'invalid.' Seriously, why would I care if the cert is invalid? The site has existed for years so this 'invalid cert' window is nothing but a wholly unnecessary annoyance which places a gate between myself and the data I seek. The only cure to remove the annoyance is to accept the invalid cert and click 'OK.' Admittedly, I don't store invalid certs permanently for websites with which I am not familiar, but I did store it permanently for the gentoo forums. Realistically, how many people would even notice the tiny little checkbox which references permanent storage or not? In other words, the 'security' these certs supposedly provide, mean little in the real world, if we will be gradually trained in real world usage to ignore the valid certs and click ok, in order to get the annoyance off the screen. So now we have an OSCP security hole, if javascript is enabled, solely due to security certs that don't really provide security at all, beyond encrypting our logins and passwords.
Ahtiga Saraz wrote: Your comments are very interesting, I hope to have more to say later. I need to get some sleep first, though...
You've got me thinking about quite a few things in this process. I have even permanently changed some Firefox settings as a result of this conversation. Thanks.

debianized
Posts: 278
Joined: 2009-01-07 07:56

Re: Block http authentician data attacks using Privoxy?

#15 Post by debianized »

Try this. Go to about:config then search for

browser.cache.disk_cache_ssl

then turn it off/set to false. Head to ip-check.info, do the test and see if your results are any different. I've got the 'Authentication' field green on every check now, but I have also disabled MUCH of caching in about:config. I just didn't get any different results in the Authentication field until I changed the above switch.

Also, since the site distributes their own version of Firefox, which they call JonDoFox, it might be worth it to download it, only to look into the prefs they distribute, to see others like the above they may be setting.

Ahtiga Saraz
Posts: 1014
Joined: 2009-06-15 01:19

Re: Block http authentician data attacks using Privoxy?

#16 Post by 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.
Ahtiga Saraz

Le peuple debout contre les tyrans! De l'audace, encore de l'audace, toujours l'audace!

datakraken
Posts: 2
Joined: 2011-10-01 09:41

Re: Block http authentician data attacks using Privoxy?

#17 Post by 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
Last edited by datakraken on 2011-10-01 11:08, edited 2 times in total.

datakraken
Posts: 2
Joined: 2011-10-01 09:41

Re: Block http authentician data attacks using Privoxy?

#18 Post by 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
Posts: 278
Joined: 2009-01-07 07:56

Re: Block http authentician data attacks using Privoxy?

#19 Post by 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
Posts: 1014
Joined: 2009-06-15 01:19

Konqueror potentially more anonymous than Iceweasel?

#20 Post by 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?
Ahtiga Saraz

Le peuple debout contre les tyrans! De l'audace, encore de l'audace, toujours l'audace!

Post Reply