Welcome Guest ( Log In | Register )

9 Pages V  1 2 3 > »   
Closed TopicStart new topic
> [email protected] 1.5, Security Kageki Revue Starlight

 
post Oct 14 2019, 09:04
Post #1
Tenboro

Admin




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 [email protected] 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-18

This 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.

- [email protected] 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+, [email protected] 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 [email protected] 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 ports

If possible, changing the port for a 1.5+ [email protected] 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 [email protected] 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 "[email protected] 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 [email protected] 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: [email protected] 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 [email protected] 1.5.4, extract the archive, copy the jar files over the existing ones, then restart the client.

The full source code for [email protected] 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 [email protected], check out The [email protected] Project FAQ.

This post has been edited by Tenboro: Dec 19 2019, 09:12
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

 
post Oct 14 2019, 09:48
Post #2
darkknightx2



Casual Poster
***
Group: Members
Posts: 155
Joined: 11-April 11
Level 23 (Apprentice)


I love to see an update, finally (IMG:[invalid] style_emoticons/default/tongue.gif)

<3


thankyou Tenboro
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

 
post Oct 14 2019, 13:08
Post #3
mayriad



Retired Uploader
*****
Group: Gold Star Club
Posts: 663
Joined: 18-December 10
Level 58 (Expert)


Talking about mixed content, will the archiver be changed to serve archive downloads from HTTPS as well?
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

 
post Oct 14 2019, 13:11
Post #4
Vexxille



Casual Lurker
******
Group: Gold Star Club
Posts: 826
Joined: 20-August 12
Level 304 (Godslayer)


I don't use [email protected] at all but it's always nice to see TenB working on the site.
Especially after the panic few months ago.
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

 
post Oct 14 2019, 14:03
Post #5
Tenboro

Admin




QUOTE(mayriad @ Oct 14 2019, 13:08) *

Talking about mixed content, will the archiver be changed to serve archive downloads from HTTPS as well?


At some point in the rather slow "replace all the old servers" process, archives will almost certainly change to HTTPS, but it's not affected by this particular browser retardedness.
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

 
post Oct 14 2019, 14:53
Post #6
caxerx



Casual Poster
***
Group: Gold Star Club
Posts: 137
Joined: 5-March 15
Level 214 (Destined)


Oh, I need to modify the client to support my dual lan again.

edit with an additional question:
It mean I will have a lower quality if I'm not using 443 as hath port?

This post has been edited by caxerx: Oct 14 2019, 16:25
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

 
post Oct 14 2019, 17:20
Post #7
mewsf



Casual Poster
****
Group: Gold Star Club
Posts: 256
Joined: 24-June 14
Level 464 (Godslayer)


So it seems the RPC server and the source image server don't get https yet, it might no be so important, but would still wait to see it happens.

Edit: the linux build script in the source code is messed up and it can't build the proper jar file, please fix (don't know if the windows script works)

This post has been edited by mewsf: Oct 14 2019, 18:31
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

 
post Oct 14 2019, 17:47
Post #8
0xDEADC0DE



Newcomer
*
Group: Recruits
Posts: 12
Joined: 9-September 18
Level 226 (Destined)


Yeah boi! Great news, thanks!

Time to make some updates~
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

 
post Oct 14 2019, 19:01
Post #9
Tenboro

Admin




QUOTE(caxerx @ Oct 14 2019, 14:53) *

edit with an additional question:
It mean I will have a lower quality if I'm not using 443 as hath port?


Potentially, but while the sample size is still small (~125 clients), the actual data shows little to no real world difference at this point.

QUOTE(mewsf @ Oct 14 2019, 17:20) *

So it seems the RPC server and the source image server don't get https yet, it might no be so important, but would still wait to see it happens.


They won't in the foreseeable future, and even 1.5 won't actually work with HTTPS source image servers, because of the aforementioned java dumbness. It doesn't have to, so I didn't change it.

QUOTE(mewsf @ Oct 14 2019, 17:20) *

Edit: the linux build script in the source code is messed up and it can't build the proper jar file, please fix (don't know if the windows script works)


Oh, right, I forgot to update the makejar.sh file. Replace it with the following:

CODE
#!/bin/sh

cd build
jar cvfm HentaiAtHome.jar ../src/hath/base/HentaiAtHome.manifest hath/base
jar cvfm HentaiAtHomeGUI.jar ../src/hath/gui/HentaiAtHomeGUI.manifest ../src/hath/gui/*.png hath/gui
cd ..


Note that it now dumps the jars in the "build" directory.
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

 
post Oct 14 2019, 20:14
Post #10
Maximum_Joe



You wa Shock
***********
Group: Global Mods
Posts: 23,698
Joined: 17-April 11
Level 500 (Godslayer)


https://ehentaihip.com/hentaiathome.php

Still listing 1.4.2 as the current version.
User is online!Profile CardPM
Go to the top of the page
+Quote Post

 
post Oct 14 2019, 22:51
Post #11
Tenboro

Admin




QUOTE(Maximum_Joe @ Oct 14 2019, 20:14) *

Still listing 1.4.2 as the current version.


Experimental branches don't go on that page or trigger an update warning. There will probably be a couple of minor releases on the 1.5 branch in short order before a 1.6.0 gets posted there. (I already have a couple of minor fixes in a for a 1.5.1.)
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

 
post Oct 14 2019, 23:24
Post #12
0xDEADC0DE



Newcomer
*
Group: Recruits
Posts: 12
Joined: 9-September 18
Level 226 (Destined)


Just curious if you maybe use some public version control for the source except the forum releases?
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

 
post Oct 15 2019, 01:24
Post #13
Shana



Shana is the source of my life.
****
Group: Gold Star Club
Posts: 290
Joined: 6-November 09
Level 486 (Godslayer)


When will 1.4.2 support end?
User is online!Profile CardPM
Go to the top of the page
+Quote Post

 
post Oct 15 2019, 04:17
Post #14
kamio11




******
Group: Catgirl Camarilla
Posts: 839
Joined: 6-June 13
Level 500 (Godslayer)


QUOTE(k258059 @ Oct 14 2019, 23:24) *

When will 1.4.2 support end?


Chrome 80, due out in January, will mark pages with mixed content images insecure by default, and block them by default in Chrome 81, due out in February. So support for 1.4.2 will probably end by February.
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

 
post Oct 15 2019, 07:03
Post #15
Anime Janai



Casual Poster
****
Group: Members
Posts: 435
Joined: 23-February 09
Level 350 (Dovahkiin)


Future Proofing? More like Future Shock is coming.

Encryption of communicated content is important to government monitoring services if a Social Credit Scoring system is to be implemented. Being encrypted means the users at both ends cannot use the "it was someone else doing a man in the middle hack so it wasn't me" excuse. Locking both ends down with encryption allows automated expert systems to make diagnosis without requiring a person to actually monitor and evaluate the connection.

Social Credit Scoring is done in China. Australia wants to do a partial version to start with its AI face recognition and tracking system cameras.
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

 
post Oct 15 2019, 09:54
Post #16
Supersonic



Internet Legend
*******
Group: Members
Posts: 1,185
Joined: 3-July 05
Level 24 (Apprentice)


QUOTE(Anime Janai @ Oct 14 2019, 22:03) *

Future Proofing? More like Future Shock is coming.

Encryption of communicated content is important to government monitoring services if a Social Credit Scoring system is to be implemented. Being encrypted means the users at both ends cannot use the "it was someone else doing a man in the middle hack so it wasn't me" excuse. Locking both ends down with encryption allows automated expert systems to make diagnosis without requiring a person to actually monitor and evaluate the connection.

Social Credit Scoring is done in China. Australia wants to do a partial version to start with its AI face recognition and tracking system cameras.


My almonds are FULLY activated by this post.
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

 
post Oct 15 2019, 11:23
Post #17
Lunar Tear



Missing someone
***
Group: Gold Star Club
Posts: 181
Joined: 14-July 15
Level 390 (Godslayer)


QUOTE(Tenboro @ Oct 14 2019, 16:04) *

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 [email protected] with --port=7777



So...for applying 1.5 version on Linux OS well, I have to register port 443 and 7777 on iptables then redirect port 443 to port 7777, right?

I tried it likes below, but as I'm all thumbs with handling Linux OS, I can't assure whether or not I did it properly.

Could you check this for me? I entered these code to my ubuntu 18.04 LTS machine in sequence.


CODE


pkill -9 -f 'java -jar HentaiAtHome.jar'      //override [email protected] client

su        //grant root privilege

iptables -A INPUT -p tcp --dport 443 -j ACCEPT

iptables -A INPUT -p tcp --dport 7777 -j ACCEPT

iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 7777

wget https://repo.e-hentai.org/hath/HentaiAtHome_1.5.0.zip && unzip -o HentaiAtHome_1.5.0.zip && nohup java -jar HentaiAtHome.jar &           //enter all the process from downloading 1.5 version to excuting [email protected] client, after changing its port to 7777 on [email protected] setting page of E-hentai website


This post has been edited by Jason78: Oct 15 2019, 11:25
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

 
post Oct 15 2019, 14:00
Post #18
Tenboro

Admin




QUOTE(Jason78 @ Oct 15 2019, 11:23) *

So...for applying 1.5 version on Linux OS well, I have to register port 443 and 7777 on iptables then redirect port 443 to port 7777, right?

I tried it likes below, but as I'm all thumbs with handling Linux OS, I can't assure whether or not I did it properly.

Could you check this for me? I entered these code to my ubuntu 18.04 LTS machine in sequence.


You don't *have* to, but it does seem to help a bit. Right now, 1.5 clients running on port 443 are averaging 9141 quality while those that don't average 8931.

Your rules look correct, but you also have to change the port to 443 on the [email protected] settings page.
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

 
post Oct 16 2019, 11:22
Post #19
mewsf



Casual Poster
****
Group: Gold Star Club
Posts: 256
Joined: 24-June 14
Level 464 (Godslayer)


Seems my [email protected] client to rpc server is just having too poor connection, whenever I start my client, it sometimes fails because speedtest procedure ends with "ssl connect error", when using the old client, it runs normal(although sometimes fails with slow speedtest result). I believe that's why my client quality decreases significantly, however it serves local region requests well, so I decide to keep running it.
User is offlineProfile CardPM
Go to the top of the page
+Quote Post

 
post Oct 17 2019, 07:42
Post #20
lestion



Active Poster
*******
Group: Gold Star Club
Posts: 1,276
Joined: 29-January 12
Level 500 (Godslayer)


My trust is taking repeated serious hits, and I'm not sure why. On the other hand, my quality is capped out. I am not aware of any connection issues on my end. This happened once yesterday and then spent the day recovering, and has apparently happened again overnight, despite serving files perfectly fine (from what I can observe).

Is this happening to anyone else using 1.5.0?
User is offlineProfile CardPM
Go to the top of the page
+Quote Post


9 Pages V  1 2 3 > » 
Closed TopicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 


Lo-Fi Version Time is now: 28th April 2020 - 20:24