[X] My Assistant

I'm not having any problems with bookmarks whatsoever with the https it redirects just fine in mine.

If you are at all concerned with security, e.g. if using a proxy that might spy on you, you are still going to have to do one of 1. Change your bookmarks, 2. Set up your own rule to redirect http://g dot e-hentai.org -> https://e-hentai.org before the browser attempts to connect, 3. Set the secure flag on your .e-hentai.org cookies. Or else you are still going to be sending those cookies unencrypted every time you hit one of your old bookmarks, potentially for years yet to come.

(Edited because of new wordfilter that updates old gallery links but gets in the way of posts like this)

This post has been edited by Necromusume: Jan 25 2017, 20:50

The developer version of Firefox is broken. Don't use it, or do the change above.

It made it into the stable version, unfortunately.

As by now, the only way to work around HSTS Priming, is to either enable the H@H clients to properly respond to the HSTS Priming request (which requires a slightly more robust implementation of the request parser in order not to get stuck on an attempted TSL handshake!), or to mask the IP addresses by subdomains which you can then explicitly exclude from HSTS.

Well, the latter one would also be prerequisite for eventually rolling out IPv6 / dual stack.

And what do I mean by "more robust"? You know exactly...

The culprit is the use of BufferedReader::readLine() in HTTPSession.java which does NOT return until either the socket is closed or a new line character appears. So the TLS handshake only fails when the timeout eventually kills the worker thread and the socket is closed.

You need to validate per regex from the ***first*** received byte onwards, whether it can still become a valid, plain HTTP request, and immediately close the socket when you receive the first wrong byte.

That means if the first received character isn't either "G" or "H", it's already not an HTTP request.

Esiest done by using the regex which is already in there, and then use [docs.oracle.com] Matcher::hitEnd() to verify whether the string *could* match if more characters are added, even when it doesn't yet. And the run the regex every time the socket runs empty. Do NOT use a BuffereReader.

This post has been edited by foobar20324: Jan 25 2017, 21:37

Can't say I quite see the point of this, but you can use an userscript to force the browser to display the news page when you first open the homepage: [gist.github.com] click

Note #1: use it on a modern-ish script or it ain't gonna work (uses promises and Fetch)
Note #2: only works on HTTPS because reasons
Note #3: doesn't use iframes because iframes are the root of all evil
Note #4: works just fine on FIrefox, on Chrome/ium you might see some flickering due to [bugs.chromium.org] some browser limitations

[text]

The problem is that the priming request should not be sent at all since images are not affected by mixed-content security policies (you'll get a warning in the console but that's it), but for some reason Firefox sends it anyway
This is fixed in the newest alpha (53.0), but the dev channel is still affected (and I guess the stable branch as well now)

[quote name='Necromusume' date='Jan 25 2017, 12:47' post='4744813']
Or else you are still going to be sending those cookies unencrypted every time you hit one of your old bookmarks, potentially for years yet to come.

thanks i didn't know that. i'm doing those suggestions now. security isn't a big problem for me but it's still nice to know.

Omg, so much nerd talk.
I don't suppose anyone will answer this, but what's the actual benefit of these changes anyway?

So the newest stable firefox release 51.0 has the hsts loading problem and changing priming in about:config did not work for me, any other workarounds besides swapping browsers?

I think it was bumped up the to-do list because of all of Russia no longer being able to directly access e-hentai.

Because of purchasing-power parity issues, many of those Russian users are going to be using free proxies, including the tor network.
Anybody who wants to can set up a tor exit node for the explicit purpose of eavesdropping on unencrypted traffic passing through it.

EH cookies aren't sent to the H@H nodes. Enabling encryption on the hub of the galleries (e-hentai.org) doesn't hide from the proxy what you are browsing (unless you disable use of the H@H network or only view thumbnails), but it can prevent malicious proxies from mass-harvesting peoples' accounts by stealing their id & password cookies, provided that the users dot all the i's on their end.

In the case of tor, unencrypted traffic between the exit node and the H@H nodes also shouldn't be able to identify who is viewing that content, provided that users are using the full tor browser, not just tor with a regular browser that is more fingerprintable, and nothing has been compromised.

There have been other attempts to mass-harvest accounts, whether to steal e-monies, or to use them to scrape all content on the entire site.

This post has been edited by Necromusume: Jan 25 2017, 22:36

I don't suppose anyone will answer this, but what's the actual benefit of these changes anyway?

Slowly moving towards full HTTPS. Which would make things considerably better with the amount of people (if you can actually call SJWs people that is) trying to enforce censorship. We are not there yet, but we are slowly moving there.

I'm 100% for marking all the cookies secure btw. You can't really contribute without visiting the things that are on HTTPS only. And, leaving http:/e-hentai.org without a possibility to get account credentials would also make easier to check how the website works without being logged in.

Something in these changes makes my router (or my ISP) reject the connection entirely. Across multiple devices and browsers, I can't access anything other than the news page (IMG:[invalid] style_emoticons/default/sad.gif)

It made it into the stable version, unfortunately.

As by now, the only way to work around HSTS Priming, is to either enable the H@H clients to properly respond to the HSTS Priming request (which requires a slightly more robust implementation of the request parser in order not to get stuck on an attempted TSL handshake!), or to mask the IP addresses by subdomains which you can then explicitly exclude from HSTS.

What, they just try to connect to a plain text socket with a HTTPS request? That would be by far the most retarded behavior I've ever seen in mainsteam "stable" browser. I assumed they were trying to hit port 443, but if what you say is true, that's just Grade A stupid.

No amount of Appletinis will ever get me through this. (IMG:[s29.postimg.org] https://s29.postimg.org/3zptvsp5j/sad_woe.gif)

Perhaps this explain why I've been having problems lately but just in case I want to ask; are the pages when browsing whatever you're viewing slow to load for anyone else? For me the rest of the page will load but the image won't appear, at least not 30 seconds or so later. Clicking on "Click here if the image fails loading" doesn't change anything, still a big delay. Is the migration the reason or could it be something else?

Slowly moving towards full HTTPS. Which would make things considerably better with the amount of people (if you can actually call SJWs people that is) trying to enforce censorship. We are not there yet, but we are slowly moving there.

I'm 100% for marking all the cookies secure btw. You can't really contribute without visiting the things that are on HTTPS only. And, leaving http:/e-hentai.org without a possibility to get account credentials would also make easier to check how the website works without being logged in.

Thanks.

imho, it feels dull without the front news page.

And what do I mean by "more robust"? You know exactly...

I put up a release candidate for 1.4.1, which implements the improved request header processing. Seems to work fine, and it makes Firefox back off quickly and get back on spec almost instantly.

jar and source

Will probably post it later today, unless I find something in testing or someone spots any mistakes.

Edit: Posted. No changes since RC1.

I put up a release candidate for 1.4.1, which implements the improved request header processing. Seems to work fine, and it makes Firefox back off quickly and get back on spec almost instantly.

jar and source

Will probably post it later today, unless I find something in testing or someone spots any mistakes.

I'll give this latest version a shot.

RIP old home page

Very much RIP old home page. (IMG:[invalid] style_emoticons/default/rolleyes.gif)

I've been waiting for SSL/TLS on E-Hentai for quite some time, and the fact that it's happened gives me a warm feeling all over. Ta, Tenboro.

Yes, I'm all over for secure cookies as well.

Now that we had some time to get used to the new look I noticed something that bothers me a bit.

The news section is now divided into two columns and sometimes the most recent change is on the left side, while another time it's on the right side.

Would it be possible to apply a visual cue to the most recent update like a slightly different background or a border around it, so that we wouldn't have to check the dates every time?

This post has been edited by Sanddan: Jan 28 2017, 18:02

Now that we had some time to get used to the new look I noticed something that bothers me a bit.

The news section is now divided into two columns and sometimes the most recent change is on the left side, while another time it's on the right side.

Would it be possible to apply a visual cue to the most recent update like a slightly different background or a border around it, so that we wouldn't have to check the dates every time?

The left is short descriptions of all changes while the right is long descriptions of major changes.

Unless the most recent change is to H@H (which doesn't get logged in the left) the left side will always be more recent or talking about the same thing as the right side.