Why is no one using Quad9 instead of Cloudfare?
fedilink
95
Why is no one using Quad9 instead of Cloudfare?
fedilink

Seems a little odd that the fediverse uses Cloudfare.

melroy
link
fedilink
1•4d

No, that is why I created https://angieguardian.org

@zombiebikini@lemmy.zip
link
fedilink
3•4d

But this only covers layer 7, doesn’t it?

melroy
link
fedilink
3•4d

That is right. I tried to be transparent what is it NOT: https://angieguardian.org/guide/threat-model#what-guardian-does-not-defend-against

ohshit604
link
fedilink
2•
edit-2
4d

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?

melroy
link
fedilink
1•4d

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.

ohshit604
link
fedilink
2•
edit-2
4d

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 peer

Can confirm my PiHole is resolving the requests and forwarding them to Quad9.

melroy
link
fedilink
1•4d

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.

Create a post

A place to discuss privacy and freedom in the digital world.

Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.

In this community everyone is welcome to post links and discuss topics related to privacy.

Some Rules

  • Posting a link to a website containing tracking isn’t great, if contents of the website are behind a paywall maybe copy them into the post
  • Don’t promote proprietary software
  • Try to keep things on topic
  • If you have a question, please try searching for previous discussions, maybe it has already been answered
  • Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
  • Be nice :)

Related communities

much thanks to @gary_host_laptop for the logo design :)

  • 0 users online
  • 108 users / day
  • 435 users / week
  • 1.32K users / month
  • 4.54K users / 6 months
  • 1 subscriber
  • 4.77K Posts
  • 119K Comments
  • Modlog