I2P client inside Whonix-Workstation Issues

Is this intended? No underscored or minus symbols?

I actually simply created a an i2ptunnel.config and a clients.config file with the required changes, forced a migration to a directory configuration, then used the migrated files as a result. Inserting an alternate character, _ or - for instance, won’t cause any problems.

Attempting to visit http://i2pforum.i2p/ I’ve got an error Website Not Found in Addressbook. The same goes for all other i2p domains such as zzz.i2p or stats.i2p.

OK this means I need to make another PR, one which contains a hosts.txt file in the /var/lib/i2p/i2p-config directory with a list of default hosts. Normally there are only 61 or so default hosts in this file, the essentials like our project site and our gitlab. Looks like since I did not include this file you are limited to only using .b32.i2p addresses instead. I’ll make another PR tonight to fix it.

Welcome to I2P! Please have patience as I2P boots up and finds peers.

It will, usually in somewhere between 90 seconds and 10 minutes, but depending on what Whonix does with the /var/lib/i2p/i2p-config/netDb directory at runtime, it may periodically re-appear in cases where the state of that directory is reset or it is otherwise emptied.

That actually reminds me of another interesting point, though, to avoid the reseed process entirely, it’s possible to include a netDb directory in the config directory itself. The router will scan the netDb directory and attempt a to connect to those peers before attempting a reseed. This might result in the “Welcome” message going away faster.

1 Like

Updated ip2-config file names to use underscores instead of white spaces.

Looking forward to. That’s a good solution to quickly get to a working state.

However, maybe a more complex solution for later… Why I2P can usually bootstrap that by itself but now with the config changes it fails to do that? Hardcoding the address book is non-ideal since this seems a feature degradation versus I2P outside of Whonix. Another thing which needs to be maintained. Would it be possible for I2P inside Whonix to use the same address book bootstrap mechanism that I2P is using outside of Whonix?

1 Like

Sent last night, also it has the eepsite docroot included which will allow users to enable the default webserver without building their site.

However, maybe a more complex solution for later… Why I2P can usually bootstrap that by itself but now with the config changes it fails to do that? Hardcoding the address book is non-ideal since this seems a feature degradation versus I2P outside of Whonix. Another thing which needs to be maintained. Would it be possible for I2P inside Whonix to use the same address book bootstrap mechanism that I2P is using outside of Whonix?

It’s because it sees the existing config and doesn’t want to change it since if it sees an existing config, the assumption is that the options it has are the options that the user wants. However, this probably applies less to the hosts.txt file than it does to i2ptunnel, for instance. hosts.txt is normally the static and unchanging “bootstrap” hosts file just for project sites(and people who applied to be included because they provide something fundamental like optional petname subscriptions), it needs to get copied once and from there, jump services and subscription services like stats.i2p and notbob.i2p take over the addition of new hosts. New hosts post-install go into the “BlockFileNamingDatabase” which manages user-added and subscription-added hostnames. So the long and short of it is that once you have the initial hosts.txt you should be able to add and remove petnames normally. So an old hosts.txt file isn’t too serious of an issue as long as you’ve got a one from the past few years since LS2(because all the keys changed with LS2). Also we only change it like, once a year, so I can just keep making PR’s when we add new hosts.

BUT, I guess there is a better way… to get a flow improvement for Whonix, I think what needs to happen is that when the I2P router checks if it needs to copy a base config to a working config, and if the hosts.txt file is not present, copy it to the working directory. That’ll be at least a 2.1.0 goal but there’s very little to stop me from making it work that way. This could theoretically be applied to the eepSite docroot as well.

1 Like

Quote @eyedeekay

It seems that if the config directory already exists, the the default files associated with the usable, “I2P distribution” aren’t copied over to the directory if they are missing. This includes 2 important sets of config files which weren’t covered in the previous PR. These are the hosts.txt file and the “eepSite docroot.” The hosts.txt file contains the default map of human-readable keys to cryptographic identifier values which comes with I2P and which forms the most basic part of it’s naming service. This is a single file. The “eepSite docroot” contains the example hidden HTTP service which end-users may enable to host a static site as an I2P client application. This is 73 files, including 7 XML files for configuring jetty with non-leaking defaults, 21 translated HTML files containing identical text, 21 flags in .png format, 18 various other .png files 3 .css files, 1 HTML template, a robots.txt and 1 .ico file. It is quite a lot, but it is simply the stable default configuration for the recommended webserver.

Thank you for your efforts! However, I am afraid, 74 files, ~ 5000 lines of code, seems far too much. I cannot review that.

Not convinced that it is really, really required to add a lot of html files, png image files, etc. Seems like excessive code duplication. That content if needed should be built into I2P and not duplicated in anon-apps-config which is supposed to only hold minimal, ideally plaintext only config snippets for Whonix compatibility and anonymity improvements.

Also for example /var/lib/i2p/i2p-config/eepsite/etc/realm.properties seems to include passwords.

Could you please minimize, send a new, separate pull request? (I don’t want to add this to the git history.)

Or should I just hand pick the hosts.txt?

Sure absolutely, I’ll make a revised one this evening and rip out the eepsite docroot. Splitting the difference would be to not include anything in the actual docroot(HTML, PNG, CSS) directory and pare it down to just the XML files where the jetty config happenss. Would that be acceptable? It would be more like 7 files instead of 74.

1 Like

Hopefully these 2 address your concerns:

1 Like

Merged. Thanks!

This one was easy to compare against https://geti2p.net/hosts.txt.

What’s jetty? How important is it?
This is still a lot code.
A lot stuff which sounds security relevant but where I could only guess what it’s used for.

    <Set name="ExcludeCipherSuites">
      <Array type="java.lang.String">
        <Item>SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA</Item>

And impossible for me to keep that up to date.

Is there some better way? Can I2P be instructed to auto generate this content so it doesn’t have to be added to anon-apps-conf package source code?

Jetty is a web server written in Java, as part of the default install it is an optional “Client” of I2P which, when enabled, automatically runs a hidden service. Normally, a preview of the content which would be available on a hidden service is available on http://127.0.0.1:7658, but for Whonix it should be at http://127.0.0.2:7658 instead. This functionality is activated by forwarding that local service into the I2P network by starting the “I2P Webserver” which would be found at: http://127.0.0.1:7657/i2ptunnel/edit?tunnel=3 where it is configured.

The motivation for doing things in this way comes from things like OnionScan and other projects which discover misconfigured hidden services en-masse, we attempt to provide a “safe” default jetty configuration for this site which does not have these weaknesses. Apparently this kind of thing is still quite prevalent: Ionut Cernica - Deanonymization of TOR HTTP hidden services - DEF CON Forums

That said, this is an entirely optional feature. We can yank it out and it won’t hurt anything. We would do this by simply deleting the corresponding clients.config.d and i2ptunnel.config.d files, which are 03-I2P_webserver-i2ptunnel.config and 03-net.i2p.jetty.JettyStart-clients.config. In that case the site will be completely disabled by default and no configuration files need to be included. however we should also warn against attempting to activate it, because it will probably not work at all without them and if they do work it won’t be in a configuration we keep track of.

1 Like

Sounds good! Could you please send a pull request / edit the wiki?


Maybe a lot / most / all of this complication could be avoided if I2P was Whonix-Workstation aware? If it had an IF in the source code saying “IF Whonix-Workstation is detected, use 127.0.0.2 instead of 127.0.0.1”.

Maybe a lot / most / all of this complication could be avoided if I2P was Whonix-Workstation aware? If it had an IF in the source code saying “IF Whonix-Workstation is detected, use 127.0.0.2 instead of 127.0.0.1”.

How would you recommend I go about detecting the Whonix workstation? As long as there’s a standard way then I’ll see what I can do.

1 Like

Yeah I’ll make another PR today

1 Like

File /usr/share/anon-ws-base-files/workstation would be very suitable.

(From Whonix ™ friendly applications best practices chapter Programmatically Detecting Whonix in Whonix wiki)

1 Like

Quote @eyedeekay

Disables the built-in hidden site by default, neither jetty nor the corresponding tunnel will start in this configuration, thereby eliminating the need for all the shipped jetty configuration files. Example config can still be found in /usr/share/i2p/eepsite, if the user wishes to use the built-in hidden site they need only copy those files to /var/lib/i2p/i2p-config and re-enable the site.

Thanks, merged!

Quote @eyedeekay

Disables the built-in hidden site by default, neither jetty nor the corresponding tunnel will start in this configuration, thereby eliminating the need for all the shipped jetty configuration files.

Nice!

Example config can still be found in /usr/share/i2p/eepsite, if the user wishes to use the built-in hidden site they need only copy those files to /var/lib/i2p/i2p-config and re-enable the site.

Could you add this to Whonix wiki please? Something else needs updating in Whonix wiki?

they need only copy those files to /var/lib/i2p/i2p-config and re-enable the site.

Would this also be an option for other I2P default settings? Can we copy/paste them from some template which is already in the disk and then only use str_replace to apply the IP change?

Could you add this to Whonix wiki please? Something else needs updating in Whonix wiki?

Sure

Would this also be an option for other I2P default settings? Can we copy/paste them from some template which is already in the disk and then only use str_replace to apply the IP change?

Yeah I don’t see why not, the only issue is that they need to be there prior to launching the actual I2P router, because if the I2P router detects there is an existing config it won’t create new config files on it’s own. So if there was a script or something which did something along the lines of:

su - i2psvc cp -r /usr/share/i2p/ /var/lib/i2p/i2p-config
find /var/lib/i2p/i2p-config -exec sed -i 's|127.0.0.1|127.0.0.2|g' {} \;

prior to the first run of the router, then you would end up with a configuration which I think would have the necessary modifications.

1 Like

Is there any chance you could either,

A) add a “–create-config” feature to I2P which only creates the config and then exits? Or

B) Even better, ship the default config by default as usual config files as most other packages do (+ support drop-ins “d.” support)?

Probably yeah but how it was implemented would need to be informed by the fact that we do actually ship a default configuration, it’s the one in /usr/share/i2p which gets copied into /var/lib/i2p/i2p-config on the first run. If /usr/share/i2p had a Whonix-modded default config in it already, then the whole config could just be copied over like we normally do. Unfortunately, that would require applying the changes to /usr/share/i2p using anon-apps-config or something like it, which would involve the more extensive changes used the previous PR’s.

So there’s the “Base Config” in /usr/share/i2p/ and the “Working Config” which is in /var/lib/i2p/i2p-config. We do this so that different packages can carry different config options, for instance, Debian and Ubuntu package-installs disable automatic updates in favor of repository-managed updates, and Easy-Install bundles use different update sources than the core distribution. Copying over the wrong defaults could be harmful, so “Base Config” needs to be honored(AFAIK).

I think what would need to happen is that --create-config would copy over any “missing” config files from the Base Config?

1 Like

I see. So it goes back to the need for a .d drop-in folder where simple config overrides can be done.