#daggerverse.dev not available on Swiss mobile network

1 messages · Page 1 of 1 (latest)

harsh hound
#

Hello.
When I try to connect to https://daggerverse.dev/ by mobile phone or with a laptop with a SIM card for mobile networks, I get errors.
Chrome:

This site can’t provide a secure connection
daggerverse.dev sent an invalid response.
ERR_SSL_PROTOCOL_ERROR
Firefox:
Secure Connection Failed
An error occurred during a connection to daggerverse.dev. PR_END_OF_FILE_ERROR
Error code: PR_END_OF_FILE_ERROR
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.
Any ideas?

low sparrow
harsh hound
#

No worries. Thank you Jeremy!

shell cloud
#

cc @pseudo verge @valid moth

pseudo verge
# harsh hound Hello. When I try to connect to https://daggerverse.dev/ by mobile phone or with...

Which IP address is daggerverse.dev resolving for you? It should be 54.146.204.208 or 107.20.229.45

This is what you should be seeing:

❯ curl -o /dev/null https://daggerverse.dev -v
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Host daggerverse.dev:443 was resolved.
* IPv6: (none)
* IPv4: 107.20.229.45, 54.146.204.208
*   Trying 107.20.229.45:443...
* Connected to daggerverse.dev (107.20.229.45) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
} [320 bytes data]
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
{ [100 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [4947 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=daggerverse.dev
*  start date: Jun  3 00:00:00 2024 GMT
*  expire date: Jul  2 23:59:59 2025 GMT
*  subjectAltName: host "daggerverse.dev" matched cert's "daggerverse.dev"
*  issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M02
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://daggerverse.dev/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: daggerverse.dev]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.6.0]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: daggerverse.dev
> User-Agent: curl/8.6.0
> Accept: */*
>
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0< HTTP/2 200
< date: Thu, 04 Jul 2024 17:15:34 GMT
< content-type: text/html; charset=utf-8
< link: <https://daggerverse.dev/>; rel="canonical"
< vary: Accept-Encoding
<
{ [16253 bytes data]
100  800k    0  800k    0     0   804k      0 --:--:-- --:--:-- --:--:--  804k
* Connection #0 to host daggerverse.dev left intact

Also: https://www.ssllabs.com/ssltest/analyze.html?d=daggerverse.dev&s=54.146.204.208&latest

#

If anything, we are supporting too many TLS protocols (compatibility with older devices) and we should remove TLS 1.0 & 1.1

But I have a suspicion that you may be connecting via an ISP proxy, meaning that you will get a different IP for daggerverse.dev, and that proxy must be doing something funky behind the scenes.

harsh hound
#

This is the output for your command:

curl -o /dev/null https://daggerverse.dev -v
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 195.186.210.241:443...
* Connected to daggerverse.dev (195.186.210.241) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS header, Unknown (21):
{ [5 bytes data]
* TLSv1.3 (IN), TLS alert, close notify (512):
{ [2 bytes data]
* error:0A0003E8:SSL routines::reason(1000)
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection 0
curl: (35) error:0A0003E8:SSL routines::reason(1000)

Or nslookup:

nslookup daggerverse.dev
Server:        127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:    daggerverse.dev
Address: 195.186.210.241
#

When I use a network where the page is working, this is the ip:

nslookup daggerverse.dev
Server:        127.0.0.53
Address:    127.0.0.53#53

Non-authoritative answer:
Name:    daggerverse.dev
Address: 54.146.204.208
Name:    daggerverse.dev
Address: 107.20.229.45
#

My telco company is Swisscom

pseudo verge
#

This is super helpful! It basically confirms that you are going to a different IP address - that proxy that I was mentioning.

#

What happens if you change your DNS server to Google (8.8.8.8) or Cloudflare (1.1.1.1)?

harsh hound
#

Changing DNS did not help.
I have still the same behavior.

low sparrow
#

Want I see from my grandmother's apartment.
Xfinity with known over-agressive firewall/proxy.

curl -o /dev/null https://daggerverse.dev -v
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 192.73.240.22:443...
* Connected to daggerverse.dev (192.73.240.22) port 443 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
} [320 bytes data]
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* (304) (IN), TLS handshake, Unknown (8):
{ [6 bytes data]
* (304) (IN), TLS handshake, Certificate (11):
{ [2618 bytes data]
* (304) (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* (304) (IN), TLS handshake, Finished (20):
{ [36 bytes data]
* (304) (OUT), TLS handshake, Finished (20):
} [36 bytes data]
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=pxy.prd.live.c2szps.spscld.net
*  start date: Apr 22 13:33:14 2024 GMT
*  expire date: Jul 21 13:33:13 2024 GMT
*  subjectAltName does not match daggerverse.dev
* SSL: no alternative certificate subject name matches target host name 'daggerverse.dev'
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection 0
curl: (60) SSL: no alternative certificate subject name matches target host name 'daggerverse.dev'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
low sparrow
#

if I use insecure -k

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 192.73.240.22:443...
* Connected to daggerverse.dev (192.73.240.22) port 443 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
} [320 bytes data]
* (304) (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* (304) (IN), TLS handshake, Unknown (8):
{ [6 bytes data]
* (304) (IN), TLS handshake, Certificate (11):
{ [2618 bytes data]
* (304) (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* (304) (IN), TLS handshake, Finished (20):
{ [36 bytes data]
* (304) (OUT), TLS handshake, Finished (20):
} [36 bytes data]
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=pxy.prd.live.c2szps.spscld.net
*  start date: Apr 22 13:33:14 2024 GMT
*  expire date: Jul 21 13:33:13 2024 GMT
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* using HTTP/1.x
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0> GET / HTTP/1.1
> Host: daggerverse.dev
> User-Agent: curl/8.1.2
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< Connection: keep-alive
< Content-Length: 0
<
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Connection #0 to host daggerverse.dev left intact
low sparrow
#

@valid moth do you know if our IPs for Daggerverse are static or dynamic?

;; ANSWER SECTION:
daggerverse.dev.    60    IN    A    107.20.229.45
daggerverse.dev.    60    IN    A    54.146.204.208
valid moth
#

They are behind an ALB so they are dynamic

low sparrow
#

So I figured that maybe daggerverse is on a "not safe" list somewhere that is ingested by various products.

#

In this sort of situation, if folks turn off the "extra protection" it usually resolves.

low sparrow
pseudo verge
# harsh hound Changing DNS did not help. I have still the same behavior.
  1. The first thing is to ensure that daggerverse.dev is resolving to the expect IP. It should be either 107.20.229.45 or 54.146.204.208

  2. Second step is to share curl https://daggerverse.dev -v . In Jeremy's example above, we can see Connected to daggerverse.dev (192.73.240.22) port 443 (#0) . This means that he is not connecting to daggerverse.dev, but instead is going to a proxy. As this proxy could be doing all sorts of things, we can only guess and, more importantly, we have no control over it.

  3. When you have done all three, please try using this WireGuard instance which I have setup in Zurich: http://37.143.131.194:51821/ . To login, please use this password gambit-KANT9shack . You will notice 4 clients (see screenshot). One of the configuration is for you @harsh hound . The first client is my phone which I used to confirm that I am able to establish a connection & route all my phone network traffic via this instance (see the other screenshots attached - https://ip.guide will show you public IP address, ASN, etc.). I have confirmed that https://daggerverse.dev behaves as expected when I connect via Zurich using this instance. I have created profiles for you @low sparrow & @valid moth in case you want to try this out. FYI https://www.youtube.com/watch?v=gBnbqulTuqI

  4. Once you confirm that all previous steps work as expected, I would recommend to:
    a. Try steps 1. & 2. from different ISPs in Switzerland. I imagine that your office ISP is different from your home ISP / mobile ISP.
    b. Ask your ISP if they can fix daggerverse.dev. This will help everyone in Switzerland that is using it!

Let us know how it goes!

low sparrow
#

Thanks, @pseudo verge. I haven't tried a VPN while on my grandmother's network, I usually just switch to an iPhone tether and it works perfectly. In her case it's possibly the known issues with the Security Edge product from Comcast/Xfinity that blocks lots of legitimate websites. I did a little digging and found some lists of known malicious websites that start with the word dagger, though daggerverse was not on any list I saw. Also found this article about the .dev top-level-domain possibly being an issue: https://macarthur.me/posts/dot-dev-problems/ It would be interesting to try it on daggerverse.io...

Alex MacArthur

Thinking back on the process of troubleshooting why a small number of people weren't able to access PicPerf’s .dev domain. Best guess: old firewall rules still block certain TLDs out of caution.

low sparrow
#

I tried via wireguard at my Grandmother's place again and it works as you'd expect.

pseudo verge
pseudo verge
harsh hound
#

Swisscom is fast and removed daggerverse.dev from the blocked list 🎉
It is now working on my mobile phone.

Dear Sir,

Thank you for your message. We assume that the security problem on your website has been corrected by you or the provider (hoster) of the website daggerverse.dev. During our check, we could no longer detect any harmful content. We have therefore removed the Internet Guard warning message before visiting your website.

Please note: Despite the warning message, your website was accessible at all times and could be accessed by visitors at their own risk.

Kind regards

Swisscom (Switzerland) AG
Internet Guard Team
#

@pseudo verge I tested with WireGuard before the changes at Swisscom.
It worked over your VPN Tunnel.
Now, after that Swisscom removed it from the block list, the right IP is used:

curl -k -o /dev/null https://daggerverse.dev -v
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 107.20.229.45:443...
* Connected to daggerverse.dev (107.20.229.45) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS header, Certificate Status (22):
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [104 bytes data]

...

* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=daggerverse.dev
*  start date: Jun  3 00:00:00 2024 GMT
*  expire date: Jul  2 23:59:59 2025 GMT
*  issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M02
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0

...

100  802k    0  802k    0     0   312k      0 --:--:--  0:00:02 --:--:--  312k
* Connection #0 to host daggerverse.dev left intact
pseudo verge
pseudo verge