NOTE:
To continue running 1.5, please update to 1.5.4. This fixes the CA issues experienced by previous versions of the 1.5 branch.As far as timelines go, unless some issues are discovered I expect this to graduate to "stable" around new year's, after which I'll start lowering the quality for 1.4.2 clients. 1.4.2 should be phased out completely around the start of February.
****
Major browsers have announced concrete plans to enforce their One True Vision™ of the web and outright disallow mixed content (HTTP) images on HTTPS sites in the near future. As such, even though this is completely pointless with our setup, and does nothing except add complexity and overhead, we don't really have any choice except to switch H@H to use HTTPS. This will take place early 2020 (February at latest), and the 1.4 branch will stop working before that time.
Please direct all complaints about the inevitable drawbacks to the brainless security fetishists at Google and/or Mozilla who cannot seem to comprehend that there are actual valid use cases for loading HTTP resources on HTTPS sites.
1.5.4 - 2019-12-18This update fixes the CA issue that required reverting to 1.4.2, by changing the CA and replacing the issuing method with an actual secure one. Note that older 1.5 releases cannot be used, 1.5.4 is required.
- H@H now uses individually issued certificates signed by Let's Encrypt. Modern browsers/OSes should all support this CA. YMMV for EOL ones.
- While the backend is still HTTP and the certificate file itself is still downloaded in plaintext, the private key is now encrypted with a shared secret, specifically the client's key.
- When the client certificate is close to expiring, the client will now automatically request a new certificate and reinitialize the HTTP server.
1.5.3 Changelog- --disable-ip-origin-check should now actually work as intended. Using this will now also disable flood control implicitly.
1.5.2 Changelog- When running on Java 11+, H@H would default to using TLSv1.3, but this was found to significantly increase the failure rate. TLSv1.3 has therefore been disabled for now.
- Fixed a minor Makefile issue on Linux for the "clean" target (which no one is likely to use).
1.5.1 Changelog- Avoid allocating a new byte array buffer for each TCP write.
- Cleaned up some now pointless code involving improved packet fillrate.
- Fixed the broken makejar.sh in the source dump to make jar files on Linux.
1.5.0 Changelog- HTTPS support has been added and is now required. All incoming requests to the client will now be HTTPS.
- If any of the required program directories cannot be created, startup should now fail in a cleaner way.
- The cache handler should now gracefully handle any inaccessible directories/files in the cache directory (like, say, a lost+found)
- Added the argument --disable-ip-origin-check that disables the requirement that RPC server requests come from a whitelisted IP. Using this is discouraged as it reduces security, but may allow H@H to work in some common non-transparent proxy configurations. Note that if the non-transparent proxy is a local network IP, speed and rate limits will not be enforced.
- Added the argument --disable-flood-control that disables the rate limit on connections per IP address. This may be necessary to use with the above trigger unless the non-transparent proxy appears as a private network IP.
- To work around systems with non-existing or broken unicode support, the gallery downloader will now fall back to a minimal ASCII directory name if creating a directory with the full name fails.
Known wontfix issues- SSL overhead is not counted by the bandwidth limiter; as handshaking is transparent there is no real way to measure it.
About portsIf possible, changing the port for a 1.5+ H@H client to 443 (the standard HTTPS port) is recommended. This can potentially significantly improve quality for the client, as some proxies and security software prevents HTTPS access to non-standard ports. In the future, clients running on port 443 may be prioritized as far as traffic goes, but outside of any quality difference, this is not currently the case.
Note that for Linux specifically, it can be complicated to let the java binary bind to low ports unless you run it as root, which is not recommended. Even if you let it with setcap, ld will then typically block unprivileged users from even running it without some trickery, as it becomes a "privileged executable" and some library paths are not trusted by default. It is easier to use --port to bind to an unprivileged port and then use iptables rules to forward the port, for example:
CODE
*filter
...
-A INPUT -p tcp --dport 443 -j ACCEPT
-A INPUT -p tcp --dport 7777 -j ACCEPT
...
COMMIT
*nat
...
-A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 7777
...
COMMIT
then start H@H with --port=7777
Another alternative is using authbind; see
this post.
Note 1: The "odd" branches should be considered experimental, but as there is not that much time until mixed content is disallowed, we need to get clients migrated fairly rapidly. 1.4 clients will therefore get an increasing quality penalty applied over the next couple of months, to give the SSL-capable clients higher traffic priority.
Note 2: The "Hentai@Home Local Network Host" setting does nothing anymore with a 1.5 client. Because the hostname is validated against the certificate, we can no longer change it to a local network IP. This setting will soon be removed.
Note 3: 1.2 is now considered EOL and can no longer be started up. If you are one of the 3 people still running a client with this version, you should shut it down and update ASAP, as the RPC endpoint will soon be removed.
Note 4: Initially, before there is a bit of uptake with the new clients, you may see lower speeds than what you eventually will end up with, since 1.4 clients cannot run tests against 1.5 clients. This is normal and expected.Note 5: Because of buggy behavior in HttpsURLConnection, 1.4 clients are not actually able to fetch data from any HTTPS sources at all even though URLConnection is supposed to handle this transparently, which means the 1.4 H@H downloader will fail fetching files from 1.5 clients. There is no workaround outside of updating.
Note 6: Because image requests now involve both a DNS lookup and a SSL handshake, requests will invariably be slower and more phrone to failure. This would normally affect quality, but the calculations compensate for this. The exact factors used here will be tweaked over time to avoid having overall quality being lower than before.
Note 7: H@H 1.5 does not change the cache structure or any internally saved data, so it is trivial to downgrade to 1.4 if something breaks. Of course, this will only be an option until 1.4 is dropped.
To update an existing client: shut it down, download Hentai@Home 1.5.4, extract the archive, copy the jar files over the existing ones, then restart the client.The full source code for H@H is available and licensed under the GNU General Public License v3, and can be downloaded here. Building it from source only requires OpenJDK 8 or newer.For information on how to join Hentai@Home, check out The Hentai@Home Project FAQ.This post has been edited by Tenboro: Dec 19 2019, 10:12