I2P Integration

The easiest solution I can think of is to append a command to run TBB DLer, in the custom TBB menu icon.

for example:

custom torbrowser u% && run TBB DLer

A user would have to go out of their way to not run an update check.

For this to be seamless as possible:

  1. TBB Downloader needs to be able to check the version of the locally installed TBB - this can be done because there is a version.js capability implemented in Tor Browser that can be queried IIRC.
    EDIT:
    Use prefs.js to get installed torbrowser version by nickjwhite · Pull Request #308 · micahflee/torbrowser-launcher · GitHub
    Since TBB lacks a metadata file and parsing prefs.js for version info is bad practice, the best way is to read the changelog text file and go from there:
    Read the version number from ChangeLog.txt by kraai · Pull Request #307 · micahflee/torbrowser-launcher · GitHub

  2. TBB Downloader should run in a background mode and only show a prompt if installed version is less than a newer one.


While testing now: It seems other config settings are persistent, however disabling the socks proxy (to prevent normal internet access) is rolled back after a TBB update. Do you have a suggestion on how to keep it off permanently?

HulaHoop:

The easiest solution I can think of is to append a command to run TBB DLer, in the custom TBB menu icon.

for example:

custom torbrowser u% && run TBB DLer

&& would result in running update-torbrowser when torbrowser
exits 0 only.

Lunch into background.

torbrowser &
update-torbrowser --some-yet-to-be-implemented-switch[s]

A user would have to go out of their way to not run an update check.

For this to be seamless as possible:

  1. TBB Downloader needs to be able to check the version of the locally installed TBB - this can be done because there is a version.js capability implemented in Tor Browser that can be queried IIRC.

Patches welcome.

re-implement Tor Browser local version number detection
https://phabricator.whonix.org/T400

  1. TBB Downloader should run in a background mode and only show a prompt if installed version is less than a newer one.

Ticket and patches for new command line option welcome.

1 Like

OK before I open tickets with the proposals, there is another idea:

Have a script that monitors changes to changelog.txt and trigger an 1. overwrite of the custom TBB folder with the updated code if it detects changes in TBB original, 2. Run the I2P pref script to re-apply those settings after the code update.

Which one do you think is better?

1 Like

I think this one is easier to do and it would give us the option to check more things like:
is i2p running,
are tunnels build,
check for I2P Updates,
and so on…

what do you think ?

I’ve been reading through the tb-updater and tb-starter scripts, and I have a pretty good idea of how to make the changes we need to make to make them set up an i2p browser also. I’ll watch the proposals and try and implement them this weekend. It’ll also help me identify whether there are any needed modifications I can’t make in TBB with environment variables, but most of them already seem to be where I need them. I was thinking just an “–i2p” flag for each of them, which would tell tb-updater download the latest TBB to a different path and tell tb-starter to use that TBB and assure i2p-related settings. Unless I’m missing something that should be something I can do by Monday.

2 Likes

Actually these last couple of proposals are a workaround for the fact that we can’t get privoxy’s domain whitelist feature off the ground. This is by far the better solution as we can still update normally but not users visit internet sites by mistake. @Goldstein any luck doing this?


Now @Goldstein add the whitelist instructions to your github page:

In /etc/privoxy/config uncomment the line below and then restart privoxy:

trustfile trust

Edit the newly created file:

kdesudo kwrite /etc/privoxy/trust

Add this rule rules at the end of the file then restart privoxy:

~*.i2p

Now it should block access and display a big red “UNTRUSTED” warning whenever connecting to a non whitelisted domain (with the caveat that you can override it if you press the go there anyway link but I assume the user is not retarded). Tor Browser updater can connect no problem.

N.B. This is not effective for https links. To block those change the setting below in about:config:

network.proxy.ssl;127.0.0.1
network.proxy.ssl_port;8118

Also might as well set privoxy for ftp proxying too.

Now it will say proxy refusing connections. I think @eyedeekay’s choice to set all the protocols (ftp, ssl, http) to 127.0.0.1:8118 was a more sound choice because ‘share settings’ doesn’t seem effective. Can you also add this to github?


There is still hope. To filter ssl we can can use stunnel. Unfortunately squid is not an option because to enable sslbump support we would need to recompile the deb src package since the default binary does not have these options enabled.

This is more complicated than I thought with not much instructions on the web. The closest thing I have is this discussion though its not directly related:

What we want is to MITM SSL connections and pipe the output into privoxy which can then apply its whitelist. Why does it have to be a bitch to configure? I don’t know but we might get there.

Well it was really just a matter of what I started with and what I left in when I re-activated Torbutton. The reason I originally regarded what I did as “cheating” was that my original intent was to apply these settings to a current Tor Browser in order to produce an acceptable basic i2p Browser. Then I realized Torbutton configured most of those by default and removed all but the proxy-setting preferences, and leaving them all explicit seemed like the careful thing to do. I’ve added that back into the script. This is simple enough to maintain and useful to me, so I’m going to keep it maintained, but if I can I’d like to move to modifying the tb-updater to set up a Tor Browser especially for use with a modified proxy(i2p or privoxy, etc), and either modifying or imitating tb-starter to configure and launch it. That way the behavior is consistent and we can sidestep some of the update issues. I’ll just make it so they have a common configuration file with the desired settings.

1 Like

changelog.txt? Location? In tbb folder on local harddrive? Of regular
Tor Browser or custom i2p Tor Browser?

  • the user may not start the former for a long time so the former
    changelog.txt can’t be trusted
  • the latter changelog.txt in custom i2p Tor Browser folder won’t change
    since Tor Browser internal updater

Parsing changelog.txt sounds hacky and wrong.

Idk:

It’ll also help me identify whether there are any needed modifications I can’t make in TBB with environment variables, but most of them already seem to be where I need them.

Yea. Environment variables everywhere already. Fore-planed modification
long ago. And where we lack needed environment variables them, we would
add them.

I was thinking just an “–i2p” flag for each of them,

Yes, it could have a flag --i2p which runs a function which then sets
the variables.

Idk:

if I can I’d like to move to modifying the tb-updater to set up a Tor
Browser especially for use with a modified proxy(i2p or privoxy, etc),

Yes.

and either modifying or imitating tb-starter to configure and launch it.

Imitating tb-starter doesn’t sound so great. Modification should be doable.

2 Likes

I thought on it some more & I don’t feel comfortable fucking with Tor Browser’s updater SSL with stunnel. They are probably checking code sigs too but still. Yet another probably impractical solution is to “virtualize” the original TBB. Essentially every time you launch the custom Bundle, the original is copied to the custom folder, a script applies the custom prefs including the SSL blocking, bookmarks and so on. Then on exit the entire custom TBB folder is deleted. The advantage is you are guaranteed to be running the latest TBB version despite internet access blocked, also its way more easier than modifying the Tor downloader script to keep track of versions, perform the updates and then restore our custom settings that disable socks access. The disadvantage is it could be slower to start.

If this too sounds too much then I say we forget about blocking internet access and save everyone’s time. Let’s assume a non-disciplined user is not really our problem.

You forgot to add enforce-blocks 1

that’s what the “enforce-blocks” option is for. If it’s enabled, Privoxy hides the “go there anyway” link. If the user adds the force prefix by hand, it will not be accepted and the circumvention attempt is logged

.

Expected see

However, because the proxy cannot gracefully show the regular “blocked” page with HTTPS, it will just refuse the request. The browser will then display an error like “The proxy server is refusing connections”. This means you won’t be able to bypass the filter (if that option is even enabled).

Couldn’t we just whitelist the updater URL ?

1 Like

HulaHoop:

I thought on it some more & I don’t feel comfortable fucking with Tor Browser’s updater SSL with stunnel. They are probably checking code sigs too but still. Yet another probably impractical solution is to “virtualize” the original TBB. Essentially every time you launch the custom Bundle, the original is copied to the custom folder, a script applies the custom prefs including the SSL blocking, bookmarks and so on. Then on exit the entire custom TBB folder is deleted. The advantage is you are guaranteed to be running the latest TBB version despite internet access blocked, also its way more easier than modifying the Tor downloader script to keep track of versions, perform the updates and then restore our custom settings that disable socks access. The disadvantage is it could be slower to start.

See bold. Why would the version be up to date? The user would have to
interact with the “virtual” (or call it template?) TBB’s gui internal
updater. Then the user would have to close TBB so the starter could make
a copy of it, modify, and start it.

1 Like

You were right :slight_smile:

I added:

~.torproject.org

and it worked while blocking other ssl sites. My first post is now valid again. No need for the complicated workarounds with Tor downloader. Sorry for not doing a more thorough job the first time. Please add the steps in my link to your github. I also added one more thing for ftp proxying since last time.

1 Like

Great, thanks for testing

I guess trust-info-url would also be handy for telling the user what happened and that he should use the normal TBB

A URL to be displayed in the error page that users will see if access to an untrusted page is denied.

Please Edit the Link to point to the Repo directly ( i changed the name of the file and i’m going to add more by time just to avoid 404’s )
https://github.com/mutedstorm/Whonix-I2P

1 Like

+1

Done

1 Like

TBH, it doesn’t actually seem to be that hard to modify tb-updater to download to a custom folder without affecting any other functionality. I’m still testing it to make sure it doesn’t break anything else, and it’s not doing any of the i2p modifications(I’m going to do that by modifying tb-starter instead, as that is where those changes are appropriate) but this change adds that functionality in a basic way at least. I’m pretty sure that’s all I’ll actually “need” to do to the updater.

3 Likes

Hey can somebody make sure I’m not missing something here? There seems to be a problem using an IPC socket by setting the environment variable in the tor-launcher extension. If I set TOR_SOCKS_IPC_PATH, somehow it ends up with extensions.torlauncher.socks_port_use_ipc=false and network.proxy.socks containing the path to the socket. If I switch extensions.torlauncher.socks_ipc_path to the socket and set extensions.torlauncher.socks_port_use_ipc=true and restart the browser, then it works, but I can’t set this with an environment variable(and I’m pretty sure I shouldn’t be able to. It looks like it’s supposed to work with the socks_ipc_path if it’s set and the file exists, the relevant section of code is https://gitweb.torproject.org/tor-launcher.git/tree/src/components/tl-protocol.js#n135). An i2p SOCKS tunnel(without socat) doesn’t seem to work in this context either, which I tried as a workaround. Before I try and modify tor-launcher, does anyone have any advice?

Never mind. I figured it out like an hour after I posted. I need to submit a tiny change to Torbutton.

Merged. And refactored.

https://github.com/Whonix/tb-updater/pull/3#issuecomment-396076138

Could you please check again if it’s still working as expected?

3 Likes

Sorry I was in bed when you did the refactoring. I tried it and ran into an issue where the variables were not available to tb_preparation. Simply moving tb_preparation to after the argument parsing seems to work and doesn’t seem to interfere with anything else. tb_settings_folder is drawn from directories in tb-starter(/etc/torbrowser.d/) which are not hyphenated. In my fork of tb-starter I didn’t hyphenate the /etc/i2pbrowser.d folder, but if that is preferable I will. For now, I changed that so that it would find the right folder. New pull request should address all that.

2 Likes