Seems a little odd that the fediverse uses Cloudfare.

  • melroy@kbin.melroy.org
    link
    fedilink
    arrow-up
    1
    ·
    3 days ago

    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@lemmy.halstead.host
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      3 days ago

      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@kbin.melroy.org
        link
        fedilink
        arrow-up
        1
        ·
        3 days ago

        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.