[X] My Assistant

I hadn't tried to access the sadpanda version of the site for many months now, but for the past few days I've been trying to connect (using https) and the page just keeps loading indefinitely without displaying anything. In fact it doesn't display any "page", the browser is stuck at the very first stage of connecting to a site, with the little spinning circle displayed in the tab. Is the address still the same as it always was?

Same issue on my end today. "this site can't be reached refused to connect"

"this site can't be reached refused to connect"

Use HTTPS, not HTTP.

Worked, thank you!

[blog.chromium.org] Looks like Chrome is planning on phasing out all mixed content, including images.

While it looks like there's a lot of time before that happens, and for now there will be a setting to allow mixed images, it's clear that the end goal is to eliminate mixed content in its entirety.

I assume Mozilla will follow suit at some point.

Looks like we have until Feb. Goodie goodie.

Looks like we have until Feb. Goodie goodie.

I have a technical prototype for video to circumvent this via webrtc - browser can talk to arbitrary host out there. Would there be some interest in this if I ported the prototype to be H@H specific - ie modify H@H to serve via webrtc + example page where you get served a picture if you know my client key?

There are some issues with that, as it's not clear what availability of wrtc people have, so http(s) should be probably always a fallback. WebRTC on the H@H client side is quite non-trivial either, as it's a typical W3C hairball of code when outside of browser. Not to mention the blob of javascript one needs to run all this.

Another option would be add LetsEncrypt auto-cert for H@H client, and EH assigning subdomain to each H@H box. You can then fetch https images from that, even on different port. LE certs can be issued via DNS so no requirements for the H@H host to do anything fancy, and the private key secret they'd have would be tied only to a single subdomain.

This post has been edited by ezdiy: Oct 4 2019, 20:43

I already knew Mozilla had concrete plans about enforcing that Soon™, so there is a design ready for HTTPS H@H, but it will inevitably be slower. Guess it's time to leave the design phase and prepare to raise the curtains on this particular security theater.

Just FYI, Let's Encrypt is unusable due to rate limits.

I'm a little confused, is ex-h back up and running again or is it just e-h? I'm able to access e-h but for ex-h there's only a blank page.

back up and running again

Has been for months.

I'm a little confused, is ex-h back up and running again or is it just e-h? I'm able to access e-h but for ex-h there's only a blank page.

I'm getting the same on Firefox. Works fine for Chrome though. Tried private browsing window in FF too - same result, blank page with no error messages, nothing. Just blank.
I've tried deleting cookies, using HTTPS for the site. Flushing DNS in windows, as well as changing DNS servers for google and cloudflare. Still the same result.

This post has been edited by yoshi245: Oct 9 2019, 00:48

Bear in mind there is no depressed animal image on display anymore.

This post has been edited by Maximum_Joe: Jun 13 2020, 21:59

I already knew Mozilla had concrete plans about enforcing that Soon™, so there is a design ready for HTTPS H@H, but it will inevitably be slower. Guess it's time to leave the design phase and prepare to raise the curtains on this particular security theater.

Just FYI, Let's Encrypt is unusable due to rate limits.

Every client shouldn't need its own cert. Just send every client the same wildcard for *.hath.e-hentai.org or whatever. Pretty sure Let's Encrypt will sign wildcards. (Of course this cert would be useless for authentication and everything under that subdomain would have to be considered non-authoritative by the application. This may break the protections built into modern browsers unless CORS/whatever can handle it)

edit: by client i mean server

Also, it should prefer to direct requests to subsequent pages to the same hath server to avoid re-handshaking

This post has been edited by Supersonic: Oct 10 2019, 06:20

We just use a regular wildcard certificate. Dicking around with Let's Encrypt to save the cost for that isn't worth my time. We'd still be using individually signed certificates from them if we could spam the hell out of their signer as it would be more secure with no real drawbacks, but seeing as their regular limit is 20 per week, I have a feeling that "a few thousand per day plz" isn't going to get approved.

We just use a regular wildcard certificate. Dicking around with Let's Encrypt to save the cost for that isn't worth my time. We'd still be using individually signed certificates from them if we could spam the hell out of their signer as it would be more secure with no real drawbacks, but seeing as their regular limit is 20 per week, I have a feeling that "a few thousand per day plz" isn't going to get approved.

There's really nothing stopping an H@H server from serving arbitrary results anyways, so the potentiality of MITM should already be accounted for. Marginally more secure, I guess, but the real security is that the untrusted content is always stuck in an <img> tag. Maybe send out some hello.jpg or 100000x100000.gif if you're feeling saucy.

We just use a regular wildcard certificate. Dicking around with Let's Encrypt to save the cost for that isn't worth my time. We'd still be using individually signed certificates from them if we could spam the hell out of their signer as it would be more secure with no real drawbacks, but seeing as their regular limit is 20 per week, I have a feeling that "a few thousand per day plz" isn't going to get approved.

Wouldn't the main limit be the new certificates per domain one (50/week) and I'd have thought new certificates would only be relevant when a new H@H client is added. Am I missing something here because I wouldn't have thought that would happen thousands of times per day?

(That's not to say that that limit wouldn't be a problem, especially in the beginning, but I'm very curious as to why there would be an ongoing need for thousands of certificates per day.)

This post has been edited by Kidf: Oct 12 2019, 10:02

Wouldn't the main limit be the new certificates per domain one (50/week) and I'd have thought new certificates would only be relevant when a new H@H client is added. Am I missing something here because I wouldn't have thought that would happen thousands of times per day?

(That's not to say that that limit wouldn't be a problem, especially in the beginning, but I'm very curious as to why there would be an ongoing need for thousands of certificates per day.)

Well, two reasons.

First of all, unless we start adding "static IP" as a requirement to run H@H, the IP can change at any time. This means that either the DNS record TTL has to be very short so it can be updated, which will frequently add in the full latency of an authoritative DNS request for an image load. Alternatively, we can change the DNS name for the client, which allows for a very long TTL and minimized DNS delay in the common "IP has not changed" case. I went with the latter. However, for Let's Encrypt to work in that case, we'd need to issue a new certificate to the client as well. There are other complexity issues with having to restart the serversocket bits of H@H to load a new certificate too.

Secondly, there are advantages to occasionally cycling the DNS hostname in general. For example, this makes links anyone may post to a H@H client go NXDOMAIN after the record is cycled, which increases privacy and reduces spurious connections to the clients. Obviously, this is just a "nice to have" and not a hard requirement, but if we are forced to have a DNS infrastructure for this shit, we might as well take the advantages we can get. (Though the only other real advantage is enabling a dual IPv4/IPv6 stack at some point.)

Tenboro... Why not make subdomains equal to the ip address?

E.g. 200-123-52-12.hath.network has ip 200.123.52.12

If a client changes ip, that client also changes name.
DNS will then only have translations to clients that are active.

and you buy a *.hath.network certificate.
Additionally, you can have all h@h download the certificate when they start.

I think this would work, would it?

This post has been edited by Jay Low: Oct 12 2019, 18:42

Tenboro... Why not make subdomains equal to the ip address?

E.g. 200-123-52-12.hath.network has ip 200.123.52.12

I think this would work, would it?

Sure it'd work, but it has various drawbacks, like reduced privacy. Complexity-wise, it's not significantly less than the chosen solution, which use randomly generated 20-character subdomains.

I'm a bit lost, Sadpanda is running but it can't be normally accessed? How would someone who has no idea about complex-internet-security go about entering again, then?

Bear in mind there is no depressed animal image on display at the moment.