[X] My Assistant

According to this, it all depends on how much ipv6 traffic there is. Google's statistics shows near 30% of its visitors have native ipv6. I have to say that's still not quite much, but it's growing faster now, can't wait to see ipv6 makes up more than half of the whole internet traffic.

In a server with more than 1 IPv4 address, is there any way to make H@H use an address (or network interface) of my choosing?

In addition to the iptables method, you can refer to https://forums.e-hentai.org/index.php?showt...2693&st=80# and let H@H listen on the IP address you want it to listen. Mapping the backend according to the destination IP will do the same.

I have a problem： how can I use H@H on NAS. I can run NAS all the time

I have a problem： how can I use H@H on NAS. I can run NAS all the time

A reasonable number of NAS systems allow for root access, and can therefore install what's needed. There are more than 100 different NAS vendors with thousands of different models, each with a different build cycle.

Another slight difference with 1.5: bwtest now goes only to 500Mbits, while the bandwidth checks did stay at 2.5Gbit/s originally (at which it is capped in H@H settings). Not that anything above 100Mbits would hardly ever matter with any realistic hitrate, but it's a practical example of what performance downgrade from java's TLS one can expect on fast networks.

(IMG:[invalid] style_emoticons/default/smile.gif) thanks man. I'm satisfied with the site management

great thanks!

Great news! It's always good to see an update. Just upgraded and it's working, though it took a little effort to figure out how to set up the HTTPS port forwarding right.

I have a problem： how can I use H@H on NAS. I can run NAS all the time

It depends. For example, I run mine as an HDD dock-station for my Linux server which does all the job. I'm not sure that running H@H directly on NAS is the best option, though I did little to no research regarding this, my guess is that if it's possible then it might be tricky (in case if this option was not essentially designed by the NAS manufacturer).

This post has been edited by Fagut: Dec 4 2019, 17:27

[crt.sh] https://crt.sh/?id=1976741370&opt=ocsp

The certificate for *.hath.network seems to be revoked. Seems it's because the private key is hard coded in the client so everyone can revoke it.

Does this mean some images on the site will be unavailable in the near future?

This post has been edited by pigeongugugu: Dec 4 2019, 18:38

Distributing private key in a public available way is not how it should work. In CA/B guideline any CA will revoke the cert in 24 hours upon private key leak. To distribute things over ssl, there are multiple industry-standard ways used by CDNs, for example:

* The CDN will use its own domain and certificate.
As many people who run H@H on dedicated server also maintains their own website, it quite easy for them to set up a subdomain with cert for H@H. We just need a way to set our own domain name and port in the H@H control panel. Then we can use our HAProxy / nginx as TLS terminator, or we can specify the cert and privkey when running H@H client. To help those who has no experience doing this, we can provide wiki on how to get free domain name from FreeNom and free cert from LetsEncrypt, or automate this using their API in the client software. (Using subdomains of hath.network will not work, as LetsEncrypt has quota on how many certs can be issued per domain.)

* Using a keyless server.
So everyone still use the same cert, but the private key is not distributed. CloudFlare has a blog explaining the details of how this works, but unfortunately their software is proprietary. For this approach, both the keyless server and the TLS key negotiation step on H@H client need to be re-implemented, so the asymmetric key decryption will happen on keyless server, and H@H only gets the session key for that specific TLS session. The keyless server itself must verify all incoming requests (probably using the client ID and key).

This post has been edited by tt_qr: Dec 4 2019, 19:28

I'm looking into options, but yeah, you should revert to 1.4.2 if you were running the experimental branch.

Interesting

I guess this explains the sudden drop in my client's quality.

Was questioning the cert thingy when I upgraded to 1.5 but could not think of any way of seriously abusing it other than posing as hath.network client and serving inappropriate content to pretty much no one. Did not think of the potential revocation.

I hope there is a reasonable solution. Having to manually set up certs and domains just to setup a client surely isn't going to work. I would think of integrating letsencrypt into the client - though don't have nearly enough experience to tell what problems you would run into at this scale.

I would think of integrating letsencrypt into the client - though don't have nearly enough experience to tell what problems you would run into at this scale.

The problems with this were already addressed earlier in the thread - using LetsEncrypt for something of this scale would cause problems if done on e-hentai's end (which it kinda has to be)

I can't imagine they would be happy with thousands of certificates being registered and renewed in batch, especially all for the same service

... if done on e-hentai's end (which it kinda has to be)

It can be done on the client side. As long as port 80 is public available, and the DNS record is correct, we can use http-01 to get the cert. It also eliminate the problem of hitting per IP rate limit.

I can't imagine they would be happy with thousands of certificates being registered and renewed in batch, especially all for the same service

See the rate limit of LetsEncrypt at [letsencrypt.org] https://letsencrypt.org/docs/rate-limits/ . The main limit is 50 new certificates per registered domain per week. Renewal does not count into this limit.

* Using a keyless server.
So everyone still use the same cert, but the private key is not distributed. CloudFlare has a blog explaining the details of how this works, but unfortunately their software is proprietary. For this approach, both the keyless server and the TLS key negotiation step on H@H client need to be re-implemented, so the asymmetric key decryption will happen on keyless server, and H@H only gets the session key for that specific TLS session. The keyless server itself must verify all incoming requests (probably using the client ID and key).

I think they have at least some of the source code for Keyless SSL [github.com] here, but that might just be only used for Cloudflare's network. I'm not a network operator.

Regarding rate limiting and Let's Encrypt... Those rate limits (ie 50 new certs per week) apply to "registered domains". So any site under "*.hath.network" would count against that, and it would obviously start hitting the limit quickly. However, DDNS sites never seem to hit that problem, right? That's because they're on the Public Suffix List - [publicsuffix.org] https://publicsuffix.org/list/ - and as per Let's Encrypt's own guidelines, each subdomain of those counts against its own 50 per week limit.

So if "*.hath.network" was added to the Public Suffix List - somehow, don't look at me for how that thing gets updated or what requirements it might have - then rate limits become a complete non-issue. Or rather, it doesn't matter if there are a thousand H@H clients all trying to update at the same time, as they'll all be for different subdomains. (And if the limits do get hit, it would only be for a client going haywire and repeatedly requesting new certs. I think.)

...This is entirely sidestepping the larger issue, though, of that you need to prove ownership of a domain (or subdomain) before something like Let's Encrypt will even issue you a certificate. The most common version requires port 80 to be open on the server, and that port is not changeable - it MUST be 80. There are other challenge types, though, listed at [letsencrypt.org] https://letsencrypt.org/docs/challenge-types/ (I've used the DNS one myself before and it does work). I don't know whether the others would be possible or not in H@H's setup.

If this doesn't get solved, though, there is no way to actually do the "give everyone a cert" solution, as Let's Encrypt (or the like) won't let you get a cert without proving ownership to their satisfaction. And if that's the case, then yeah, a keyless server setup would probably be the only real solution. (I'm skeptical of a solution requiring every H@H client/user to register their own DDNS and supply their own cert. Some can, sure, but I feel a number of people won't use it if it needs that level of tinkering.)

Edit: Looking through the Public Suffix List's guidelines, it says "We do not accept entries whose sole purpose is to circumvent Let's Encrypt rate limits.". (They also note that Let's Encrypt has a form you can submit to increase rate limits?) So if this route is chosen, I guess just make sure it wouldn't run afoul of something like that by accident.

This post has been edited by jadoeman: Dec 6 2019, 03:55

The problems with this were already addressed earlier in the thread - using LetsEncrypt for something of this scale would cause problems if done on e-hentai's end (which it kinda has to be)

I can't imagine they would be happy with thousands of certificates being registered and renewed in batch, especially all for the same service

10b just hates LE for some reason. There are ways to get mass cert - public suffix, or just letting H@TH clients supply their own domain (most of us able to run server usually have some sort of domain too).

...This is entirely sidestepping the larger issue, though, of that you need to prove ownership of a domain (or subdomain) before something like Let's Encrypt will even issue you a certificate. The most common version requires port 80 to be open on the server, and that port is not changeable - it MUST be 80. There are other challenge types, though, listed at [letsencrypt.org] https://letsencrypt.org/docs/challenge-types/ (I've used the DNS one myself before and it does work). I don't know whether the others would be possible or not in H@H's setup.

Yes, it would demand a bit more of engineering. As for DNS-01, that's tenable only with common suffix scenario, where EH allows clients to "upload" the DNS-01 response record for their subdomain. As for "it must be 80", no just 443 is enough. Indeed without common suffix and using their own domain instead (even reverse dns if it forward-resolves will suffice), clients are forced to run on 443 and answer TLS-ALPN challenges on there, lest otherwise massive PITA with delegating to DNS that can answer is involve (free ones like he.net or cloudflare can do it, but bleh).

Edit: Looking through the Public Suffix List's guidelines, it says "We do not accept entries whose sole purpose is to circumvent Let's Encrypt rate limits.". (They also note that Let's Encrypt has a form you can submit to increase rate limits?) So if this route is chosen, I guess just make sure it wouldn't run afoul of something like that by accident.

Note that their rule against "circumventing limits" is for the case when the subdomains *dont* belong to other people (ie its a spammer generating shitton of certs). As long it is distinct people generating domains (ie LE client running in H@TH keeping their key private), LE public suffix works fine - that's exactly the use case it was intended for.

This post has been edited by ezdiy: Dec 6 2019, 06:59

Yes, it would demand a bit more of engineering. As for DNS-01, that's tenable only with common suffix scenario, where EH allows clients to "upload" the DNS-01 response record for their subdomain. As for "it must be 80", no just 443 is enough. Indeed without common suffix and using their own domain instead (even reverse dns if it forward-resolves will suffice), clients are forced to run on 443 and answer TLS-ALPN challenges on there, lest otherwise massive PITA with delegating to DNS that can answer is involve (free ones like he.net or cloudflare can do it, but bleh).

Note that their rule against "circumventing limits" is for the case when the subdomains *dont* belong to other people (ie its a spammer generating shitton of certs). As long it is distinct people generating domains (ie LE client running in H@TH keeping their key private), LE public suffix works fine - that's exactly the use case it was intended for.

Alright; thanks for the clarification. I was kind of confused by the wording on the challenge page - it says 80 only, then it says 80 or 443, then it says 80 only again, all in like one paragraph... And really, the "circumvention" part is just covering my ass, since I haven't looked into it any further than that one page - if that route would be taken I would assume someone would more thoroughly investigate things.

...Hmm. Really though, thinking about it, the HTTP-01 challenge might be doable, even if the H@H client can't use 80/443. I suppose it would depend on how it's all set up, but... Can't check now, since 1.5/HTTPS is down, but how does "blahblah.hath.network" resolve to a H@H client IP? Does it first hit EH's servers then bounce over to the correct IP? I wonder if it would be possible to have "*.hath.network/.well-known/acme-challenge/*" resolve to EH's servers - some server configuration rule somewhere - where 80/443 are both quite obviously available. That would mean that the H@H client and the EH servers could coordinate such that the EH servers respond to the LE challenges, and after it succeeds, bam you have your cert.

Eh. It's all spitballing anyway; the topic does interest me but I'm far from versed in it well enough to actually suggest valid stuff. Hopefully smarter people find a smart solution to it.

Alright; thanks for the clarification. I was kind of confused by the wording on the challenge page - it says 80 only, then it says 80 or 443, then it says 80 only again, all in like one paragraph... And really, the "circumvention" part is just covering my ass, since I haven't looked into it any further than that one page - if that route would be taken I would assume someone would more thoroughly investigate things.

A LOT of ddns providers are on public suffix list, so hath.network just need to become another one. What LE cares about that you do rate limiting on your own when it comes to those subdomains - ie not allow arbitrary amount of subdomains from complete strangers -- the users you delegate subdomain to must be something tangible, not automated spam.

Very quick and dirty interim solution is to simply implement client for one of ddns already on the list, for example dynu.net. That one allows you to publish TXT record you submit, and in turn client can complete DNS-01 cert creation/renewal with their own ratelimit, not global one. The downside is that end user needs to register on some horrible 3rd party site, and then pass credentials to the h@h client for it, instead of h@h doing all that on its own with help from EH dns - to reduce 3rd part dependency.

...Hmm. Really though, thinking about it, the HTTP-01 challenge might be doable, even if the H@H client can't use 80/443. I suppose it would depend on how it's all set up, but... Can't check now, since 1.5/HTTPS is down, but how does "blahblah.hath.network" resolve to a H@H client IP?

If EH controls the dns responses for client's domain (ie is authoritative for that domain), it can simply serve TXT records for DNS-01 on behalf of client (client just uploads it via some api). No need to do shady dns rebinding/split horizon for fake http server. The issue is that entire *.hath.network is rate limited to 50 subdomains a week, regardless of cert generation method.

[github.com] here, but that might just be only used for Cloudflare's network. I'm not a network operator.

This looks pretty interesting. The only downside is the "double-bad" round trips (surfer->H@H->EH and back). That can easily clock half a second with sucky geography (think h@h in japan ringing in to netherlands). Plus EH doing shitload of kex (can be hardware thrown at though). With CF it makes much more sense because it's done only once and then the session is cached ticket on the front of the proxy. But given how h@h works, session caching is near impossibility as same user hits the same proxy again only once in a blue moon.



This post has been edited by ezdiy: Dec 6 2019, 08:35

I think the first line (edit) should be bold, underlined, in bigger font, or even be a separate news, as it is really something important.