[X] My Assistant

I'm currently using HV as a guinea pig to try out Cloudflare. If you notice any changes in how HV performs, for better or worse, let me know. It will take up to 24 hours for the name servers to be updated, you can tell that they have updated for you if the IPs no longer resolve to 94.100.y.z.

If you can be arsed, also let me know how it performs with HTTPS.

japan is very slowly.
I can not do anything like this.
Please do something

This post has been edited by blackjac00: Feb 20 2017, 19:32

I'll keep it like this for now, but you can still use [alt.hentaiverse.org] http://alt.hentaiverse.org/ if Cloudflare isn't performing well for you.

I'll keep it like this for now, but you can still use [alt.hentaiverse.org] http://alt.hentaiverse.org/ if Cloudflare isn't performing well for you.

It got a little faster.
However, the script has stopped working.

If you use some e-commerce site that's on Cloudflare, they can get your real name & address thanks to their MITM-SSL.

MITM is illegal.
Who cares? If they use MITM and get my real name & address they can come to my house and kill me
HV is the last of my problem if we take in account all the law-breaking actions they can take.

However, the script has stopped working.

You have to edit each userscript and add additional @include lines in the metadata block so the script engine knows to run it on alt.hentaivese.org.

E.g. if it had

CODE

// @include     http://hentaiverse.org/?s=Bazaar&ss=ss
// @include     http://hentaiverse.org/?s=Bazaar&ss=is

then you need to change it to,

CODE

// @include     http://hentaiverse.org/?s=Bazaar&ss=ss
// @include     http://hentaiverse.org/?s=Bazaar&ss=is
// @include     http://alt.hentaiverse.org/?s=Bazaar&ss=ss
// @include     http://alt.hentaiverse.org/?s=Bazaar&ss=is

if you want it to run on both.
[wiki.greasespot.net] https://wiki.greasespot.net/Include_and_exclude_rules

And alt.hentaiverse.org doesn't answer on https, at least for me.

MITM is illegal.

Not if you agreed to it. The HTTPS connection from one's browser is to the Cloudflare edge node, not the origin server. It gives users a false sense of security, and meanwhile Cloudflare is a de facto man-in-the-middle who can silently skim any data of interest.

Who cares? If they use MITM and get my real name & address they can come to my house and kill me

Why would they want to do that, if they didn't have any way of knowing that you are also this other user on this other site who was previously anonymous to them?



Before, the private keys were in one data center in one European country. Now, they've been distributed to data centers all over the world in many jurisdictions. Many more employees have access to them, many more shitty governments can obtain them via secret court orders, even if they couldn't get another government to co-operate. You live in Russia? Before, they'd have to hack a server in a foreign country. Now, they can just demand that the Moscow edge node secretly hand them over.

Any degree of assurance you had that you were connecting to hentaiverse.org rather than Roskomnadzor is gone. HV is the guinea pig; is the main site next?

Since Cloudflare only caches static data, it can only slow down any significant interaction with Hentaiverse. You just can no longer measure the true ping all the way back to the origin server.

Also, [blog.torproject.org] Cloudflare is making the web unusable for Tor and VPN users by constantly harassing them for captchas across more than 2 million sites and should be boycotted just for that.

This post has been edited by Necromusume: Feb 20 2017, 23:17

And it dropped me a __cfduid cookie, meaning they can diddle the contents of the transmission, but I was using HTTPS and the secure certificate did not change. So even if I never allow my browser to connect to HV through Cloudflare again, they've been given hentaiverse.org's private key, and they can give it to other people, who can then silently MITM you any time they want?

Have a look at a tamper data (the firefox plugin, or wireshark, or even an mitm proxy of your own) for HV login. You will see that they do not need to know the private key. (scrap your browser cache and perform the test).

Anyone monitoring your connection can get your connection info from the HV login. Unfortunately the HV login is inherently insecure.

(I'm not giving details 'cause anyone clever enough to actually do it, already guessed how it's done or can check it themselves. Feels like a CVE )

I'd really love if Tenb would make a different set of credentials for HV. Just that you can login to HV with EH credentials but can't login to EH with HV credentials. i.e. the forums bounce for HV gives you a different hash from the one used on the other sites.

This post has been edited by blue penguin: Feb 21 2017, 00:56

Any degree of assurance you had that you were connecting to hentaiverse.org rather than Roskomnadzor is gone. HV is the guinea pig; is the main site next?

Considering that 99% of the HV traffic is currently unencrypted, and the main site itself was as well until a month ago, having some theoretical opening for a MITM is hardly groundbreaking. But if you want, you can always sponsor the Enterprise solution that allows for keyless proxying, it'll just be $5k or so per month.

Also, [blog.torproject.org] Cloudflare is making the web unusable for Tor and VPN users by constantly harassing them for captchas across more than 2 million sites and should be boycotted just for that.

90%+ of traffic from Tor exit nodes is malicious. What do you expect, exactly?

Is there a prospect of improving communication speed?

Is there a prospect of improving communication speed?

Use the alt link?

Longer-term I'm planning on slowing down HV "turns" to the point where latency shouldn't be an issue, but obviously that requires a fairly substantial rebalancing to make sure everything doesn't just take four times longer to do.

Use the alt link?

Longer-term I'm planning on slowing down HV "turns" to the point where latency shouldn't be an issue, but obviously that requires a fairly substantial rebalancing to make sure everything doesn't just take four times longer to do.

Yes,Use the alt link.
However the operation is slower than the communication speed.

If there is a plan to fix it, I will endure for a while.

Tenboro, to appease the infosec bunch (me included) could you make a different session management for each site? Currently we suffer from both session-fixation (it is never invalidate) and session-leaking (you get some, actually all, information about the password hash from he session token).

If we can get rid of one of the problems (fixation or leaking) we would get a better security by a lot. Fixation is often needed by scripts (since there is no API to get a new session from a script) and creating a session invalidation is a lot of work, so I'd take on session-leaking.


Solution 1: Quick one

Creating 3+ random string of bytes, let's call them hv_key, eh_key, forum_key, etc; and keep them secret. Then instead of passing ipb_hash around pass:

CODE

For HV hash(XOR(hv_key, ipb_hash))
For the forums hash(XOR(forums_key, ipb_hash))
For the galleries hash(XOR(eh_key, ipb_hash))

This can still be kept inside the same cookie. It would just disallow someone with session data from one connection to connect to the other sites. Of course the one will still work as the bounce (forums), and getting that one would allow entry to the others.

This is likely vulnerable to good cryptographical attacks if enough account data from *all* websites is collected.


Solution 2: Probably too much work

Add to each user record a random string of bytes and pass this around instead of the ipb_hash. Would never reveal the actual ipb_hash, but generating good random data for all users is a daunting task.

Just reporting that I had the same problems as others have mentioned. My ping dropped from 224ms to 12ms, but the game slowed down a lot. I'll use the "alt" for now.

Tenboro, to appease the infosec bunch (me included) could you make a different session management for each site?

When HV is fully switched to HTTPS, that will sufficiently resolve those issues, but that depends on the latency overhaul.

That said, the general weakness of the session system is solely caused by it being grafted onto IPB's account system, and whenever that is ripped out, we'll be rolling something stronger.

generating good random data for all users is a daunting task.

There are open-source hardware random number generators.
[onerng.info] http://onerng.info/
[www.tindie.com] https://www.tindie.com/products/WaywardGeek...mber-generator/
The second one is out of stock, but you can build it yourself for ultimate security.

Or there's this:
[organic-entropy.org] https://organic-entropy.org/

This post has been edited by Necromusume: Feb 21 2017, 19:06

vastly better ping, slower turn per second. Am I doing something wrong with cloudflare?

The ping can only be measured between you and the edge node.
Cloudflare only caches static content. Things like the images.
Most of the battle output is dynamically generated by the origin server and can't be cached. Your ping to it is necessarily longer because your traffic has to go through several more steps of routing and processing, you just can't measure the true ping.

Only in the most optimistic case where the route from the edge node to the origin server is sufficiently more efficient than your traffic's normal direct route to make up for the extra steps (ie, your normal route is broken) could Cloudflare result in a faster turn rate.

being grafted onto IPB's account system, and whenever that is ripped out, we'll be rolling something stronger.

Yeah, IPB is quite outdated on that front. Am crossing fingers.

There are open-source hardware random number generators.

Even those are only 10^2 - 10^3 faster than a personal computer with a lot of user interaction.

Let's say that we want 256 bits for each user for each website (4), and we have 3500k users.

CODE

(256 * 4 * 3_500_000) / 8 = 448000000

(/ 8 'cause i'll make a test using bytes.)

Now:

CODE

$ /usr/bin/time head -c 448 /dev/random > file
0.00user 0.00system 2:34.05elapsed 0%CPU (0avgtext+0avgdata 1724maxresident)
0inputs+8outputs (0major+77minor)pagefaults 0swaps
$ /usr/bin/time head -c 4480 /dev/random > file
0.00user 0.00system 58:43.07elapsed 0%CPU (0avgtext+0avgdata 1724maxresident)k
0inputs+8outputs (0major+75minor)pagefaults 0swaps

(note the little number of page faults, i warmed the cache to make the impact of program start minimal)

That is on the machine i'm tagging galleries on, so there is a good deal of entropy. Moreover the function is definitely not linear. Even with a 10^3 speedup is isn't that great. I'd estimate it for some 2-3 days of continuous generation.

-----------------

Most of the battle output is dynamically generated by the origin server and can't be cached.

My thoughts exactly. Wouldn't be better to dump all static stuff from HV onto ehgt.org and cache that on cloudflare? Instead of the entire HV pageload.

The ping can only be measured between you and the edge node.
Cloudflare only caches static content. Things like the images.
Most of the battle output is dynamically generated by the origin server and can't be cached. Your ping to it is necessarily longer because your traffic has to go through several more steps of routing and processing, you just can't measure the true ping.

Only in the most optimistic case where the route from the edge node to the origin server is sufficiently more efficient than your traffic's normal direct route to make up for the extra steps (ie, your normal route is broken) could Cloudflare result in a faster turn rate.

Er, it was an empty dream
I was really excited when I saw my ping improvement after the switch.

Even those are only 10^2 - 10^3 faster than a personal computer with a lot of user interaction.

According to the RNG enthusiasts who designed them, they didn't make them faster because,

no one should need higher bit rates than a few hundred bits of unpredictability per second. TRNGs do not need to be fast, because we only use them to seed the CPRNG in /dev/random (or some other CPRNG). Once seeded, the only reason to ever read more bits from the TRNG is in case you are concerned that the CPRNG state may have been leaked, and you want to be able to recover. Recovery every second or so should be often enough for even the most paranoid, and 512 bits of unpredictability seems to be enough for modern crypto, even post-quantum crypto. Anything over about 512 bits per second of entropy is over-kill.

([lists.onerng.info] link)

Also, I don't expect all 3.5m users to log in at once, and many will never log in again. If the numbers have to be pregenerated, they can be queued and allocated as people show up.