A lot of fediverse instances for some weird reason use Cloudflare for captchas and espionage. I assume it’s a sort of “genre-blind” offloading hardware work moment, if not something like being Class Traitors, because one of the big reasons people come to the Fediverse is precisely to escape the grip and decision power of giants like CF.
wow. uh okey, quite a complex setup. But in this specific case it’s not even reaching Angie Guardian… Let alone Angie/Nginx… It fails clearly at TLS handshaking and the non-TLS is unclear why it fails.
Here is an example if what I would have expected using curl via httpS:
curl -v https://angieguardian.org/
* Host angieguardian.org:443 was resolved.
* IPv6: (none)
* IPv4: 77.61.56.117
* Trying 77.61.56.117:443...
* Connected to angieguardian.org (77.61.56.117) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
* subject: CN=angieguardian.org
* start date: Jul 25 12:33:40 2026 GMT
* expire date: Oct 23 12:33:39 2026 GMT
* subjectAltName: host "angieguardian.org" matched cert's "angieguardian.org"
* issuer: C=US; O=Let's Encrypt; CN=YE2
* SSL certificate verify ok.
* Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
* Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
* Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
* Certificate level 3: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://angieguardian.org/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: angieguardian.org]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.5.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2> Host: angieguardian.org> User-Agent: curl/8.5.0> Accept: */*>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/2 403
< server: Angie
< date: Thu, 13 Aug 2026 20:17:31 GMT
< content-type: text/plain; charset=utf-8
< content-length: 93
< cache-control: no-store
< referrer-policy: no-referrer
< x-content-type-options: nosniff
< content-security-policy: default-src 'none'; script-src 'unsafe-inline'; style-src 'unsafe-inline'; worker-src blob:; connect-src 'self'; base-uri 'none'
<
proof-of-work challenge requires a document navigation: Accept must list text/html or text/*
* Connection #0 to host angieguardian.org left intact
But your non SSL is maybe even more interesting… since that is also failing (port 80 has NO angie guardian protection btw), here I would expected the following:
curl -v http://angieguardian.org/
* Host angieguardian.org:80 was resolved.
* IPv6: (none)
* IPv4: 77.61.56.117
* Trying 77.61.56.117:80...
* Connected to angieguardian.org (77.61.56.117) port 80
> GET / HTTP/1.1
> Host: angieguardian.org
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: Angie
< Date: Thu, 13 Aug 2026 20:22:16 GMT
< Content-Type: text/html
< Content-Length: 205
< Connection: keep-alive
< Location: https://angieguardian.org/
<
<html><title>301 Moved Permanently</title><style>html{color-scheme:light dark;}</style></head><body><center><h1>301 Moved Permanently</h1></center><hr><center>Angie</center></body></html>
* Connection #0 to host angieguardian.org left intact
TDLR; clearly something else goes wrong with this setup.
A lot of fediverse instances for some weird reason use Cloudflare for captchas and espionage. I assume it’s a sort of “genre-blind” offloading hardware work moment, if not something like being Class Traitors, because one of the big reasons people come to the Fediverse is precisely to escape the grip and decision power of giants like CF.
I guess if you have to defend against DDOS attacks going big is the only way.
It’s not.
Care to elaborate?
There’s loads of DDoS alternatives.
It’s a national security threat to give your httpa private keys to a US company. As a result, loads of alternatives exist for real DDoS attacks.
But also, almost any nonprofit social media site can just get away with a self hosted pow solution.
Ok, seems we have different ideas of what a real ddos attack is. I was thinking level 3 attacks.
No, that is why I created https://angieguardian.org/
But this only covers layer 7, doesn’t it?
That is right. I tried to be transparent what is it NOT: https://angieguardian.org/guide/threat-model#what-guardian-does-not-defend-against
Yeah something ain’t right here chief. Now I have to ask, what was the LLM policy in regards to the development of this software?
Uhm that is interesting. Are you using a VPN or some browser without cookie support maybe? I would like to debug this specific issue.
I’m using let’s encrypt certificates. Please I would really like to debug this problem, I can’t reproduce it.
iPhone > Safari webkit > WireGuard tunnel home network > PiHole DNS (Quad9 upstream) > WireGuard tunnel ProtonVPN endpoint
That is the flow of my current network.
Edit: I ran curl from my server
┌─[user@debian] - [~/compose] - [Thu Aug 13, 12:26] └─[$]> curl -v https://angieguardian.org/ * Host angieguardian.org:443 was resolved. * IPv6: (none) * IPv4: 77.61.56.117 * Trying 77.61.56.117:443... * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * Recv failure: Connection reset by peer * TLS connect error: error:00000000:lib(0)::reason(0) * OpenSSL SSL_connect: Connection reset by peer in connection to angieguardian.org:443 * closing connection #0 curl: (35) Recv failure: Connection reset by peer ┌─[user@debian] - [~/compose] - [Thu Aug 13, 12:27] └─[$]> curl -v angieguardian.org * Host angieguardian.org:80 was resolved. * IPv6: (none) * IPv4: 77.61.56.117 * Trying 77.61.56.117:80... * Connected to angieguardian.org (77.61.56.117) port 80 * using HTTP/1.x > GET / HTTP/1.1 > Host: angieguardian.org > User-Agent: curl/8.14.1 > Accept: */* > * Request completely sent off * Recv failure: Connection reset by peer * closing connection #0 curl: (56) Recv failure: Connection reset by peerCan confirm my PiHole is resolving the requests and forwarding them to Quad9.
wow. uh okey, quite a complex setup. But in this specific case it’s not even reaching Angie Guardian… Let alone Angie/Nginx… It fails clearly at TLS handshaking and the non-TLS is unclear why it fails.
Here is an example if what I would have expected using curl via httpS:
curl -v https://angieguardian.org/ * Host angieguardian.org:443 was resolved. * IPv6: (none) * IPv4: 77.61.56.117 * Trying 77.61.56.117:443... * Connected to angieguardian.org (77.61.56.117) port 443 * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey * ALPN: server accepted h2 * Server certificate: * subject: CN=angieguardian.org * start date: Jul 25 12:33:40 2026 GMT * expire date: Oct 23 12:33:39 2026 GMT * subjectAltName: host "angieguardian.org" matched cert's "angieguardian.org" * issuer: C=US; O=Let's Encrypt; CN=YE2 * SSL certificate verify ok. * Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384 * Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384 * Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384 * Certificate level 3: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384 * using HTTP/2 * [HTTP/2] [1] OPENED stream for https://angieguardian.org/ * [HTTP/2] [1] [:method: GET] * [HTTP/2] [1] [:scheme: https] * [HTTP/2] [1] [:authority: angieguardian.org] * [HTTP/2] [1] [:path: /] * [HTTP/2] [1] [user-agent: curl/8.5.0] * [HTTP/2] [1] [accept: */*] > GET / HTTP/2 > Host: angieguardian.org > User-Agent: curl/8.5.0 > Accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing < HTTP/2 403 < server: Angie < date: Thu, 13 Aug 2026 20:17:31 GMT < content-type: text/plain; charset=utf-8 < content-length: 93 < cache-control: no-store < referrer-policy: no-referrer < x-content-type-options: nosniff < content-security-policy: default-src 'none'; script-src 'unsafe-inline'; style-src 'unsafe-inline'; worker-src blob:; connect-src 'self'; base-uri 'none' < proof-of-work challenge requires a document navigation: Accept must list text/html or text/* * Connection #0 to host angieguardian.org left intactBut your non SSL is maybe even more interesting… since that is also failing (port 80 has NO angie guardian protection btw), here I would expected the following:
curl -v http://angieguardian.org/ * Host angieguardian.org:80 was resolved. * IPv6: (none) * IPv4: 77.61.56.117 * Trying 77.61.56.117:80... * Connected to angieguardian.org (77.61.56.117) port 80 > GET / HTTP/1.1 > Host: angieguardian.org > User-Agent: curl/8.5.0 > Accept: */* > < HTTP/1.1 301 Moved Permanently < Server: Angie < Date: Thu, 13 Aug 2026 20:22:16 GMT < Content-Type: text/html < Content-Length: 205 < Connection: keep-alive < Location: https://angieguardian.org/ < <html> <title>301 Moved Permanently</title> <style>html{color-scheme:light dark;}</style> </head> <body> <center><h1>301 Moved Permanently</h1></center> <hr><center>Angie</center> </body> </html> * Connection #0 to host angieguardian.org left intactTDLR; clearly something else goes wrong with this setup.