Node running without TLS on port 443?

Website, Application, Performance DNS & Network
1

What is the name of the domain?

172.67.70.114

What is the issue you’re encountering

This server is currently running 443 but without TLS. I believe this is an error

What feature, service or problem is this related to?

I don’t know

What are the steps to reproduce the issue?

  • The server 172.67.70.114, which is one of the resolutions of the domain repo.protonvpn.com, appears to be running HTTP on port 80 and 443, but without running TLS on 443. This led to an error when trying to update packages for protonvpn.

Attempting connection to this node on 443 with TLS gives the error handshake error, or “SSL_ERROR_NO_CYPHER_OVERLAP”

I believe this is an error at some configuration level in CF.

I am on a network that appears to be filtering certain servers associated with VPNs, resetting peer connections on certain vpn sites, so it’s possible this is on my end, but this server issue appears to be an infrastructure issue.

Best,

2

This is definitely on your end.

curl -svo /dev/null https://repo.protonvpn.com --connect-to ::172.67.70.114:443
* Connecting to hostname: 172.67.70.114
* Connecting to port: 443
*   Trying 172.67.70.114:443...
* Connected to 172.67.70.114 (172.67.70.114) port 443
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [19 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [2535 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [79 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=protonvpn.com
*  start date: Apr  3 01:19:41 2025 GMT
*  expire date: Jul  2 02:19:35 2025 GMT
*  subjectAltName: host "repo.protonvpn.com" matched cert's "*.protonvpn.com"
*  issuer: C=US; O=Google Trust Services; CN=WE1
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA256
*   Certificate level 1: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 2: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using ecdsa-with-SHA384
} [5 bytes data]
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://repo.protonvpn.com/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: repo.protonvpn.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.5.0]
* [HTTP/2] [1] [accept: */*]
} [5 bytes data]
> GET / HTTP/2
> Host: repo.protonvpn.com
> User-Agent: curl/8.5.0
> Accept: */*
>
{ [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [238 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [238 bytes data]
* old SSL session ID is stale, removing
{ [5 bytes data]
< HTTP/2 403
< date: Wed, 23 Apr 2025 16:02:47 GMT
< content-type: text/html
< cf-cache-status: DYNAMIC
< vary: accept-encoding
< report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=tnrWSXMusjN6b18GROpx3x3uNEvPucZru5%2BBmDG5BF6ifOR%2FxFvaLtWYG1jxr81rbIVVEVSiBZlwSdIawWGq6bRRfTOKExGfhRdHDtZQSou8pyKRJLWfxAtaMLxvTIFIqoA97Q%3D%3D"}],"group":"cf-nel","max_age":604800}
< nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
< server: cloudflare
< cf-ray: 934e96591d74376e-HEL
< alt-svc: h3=":443"; ma=86400
< server-timing: cfL4;desc="?proto=TCP&rtt=762&min_rtt=744&rtt_var=191&sent=6&recv=9&lost=0&retrans=0&sent_bytes=3409&recv_bytes=778&delivery_rate=3840848&cwnd=252&unsent_bytes=0&cid=1f53331656c97307&ts=65&x=0"
<
{ [5 bytes data]
* Connection #0 to host 172.67.70.114 left intact
1 Like
3

ok, thanks!
sorry for the noise

4

Sorry, this is actually happening on multiple networks though.

Happening from US East, when connected on cable line networks like Cox, Comcast. It happened on another internet access node which isn’t doing the same connection reset blocking of VPN sites.

Are you able to check regionally if this is some multicast issue or something?

5

With the same device or different devices?

I’d expect a large number of complaints if a Cloudflare location didn’t work via https anymore, so it’s incredibly unlikely.

I’d start by checking what actually happens during the handshake.

6

It happens on multiple devices from different egress networks (with different providers), all in US East region (now tested on 3). Tested on macOS, iOS and Ubuntu, same result.

It seems like it ends up serving a nonsecure plain HTTP instance on 443 as well as 80 for these.

Will be curious to see if you can find anything on CF end, and what is going on.

Best,

7

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.