Hi Everyone, and Dear Shakiba
recently Iran government applied a new system to detect VPN addresses and IPs, when they find IP users in Iran can't connect to the server, and when trying to connect to the server get an error while Verifying the server certificate
It holds on the Verifying server certificate for a few seconds then the error can't connect
I'm wondering if there is a solution to bypass this issue.
when changing the server IP address problem will be solved but it's costly and hard way
thanks in advance
Verifiying Server Certificate Error
-
- Posts: 47
- Joined: Sun May 25, 2014 3:37 pm
Verifiying Server Certificate Error
You do not have the required permissions to view the files attached to this post.
-
- Posts: 1486
- Joined: Sun Feb 14, 2021 10:31 am
Re: Verifiying Server Certificate Error
A somewhat different objective but give it a try... https://www.vpnusers.com/viewtopic.php?f=7&t=68621
-
- Posts: 289
- Joined: Wed Dec 28, 2022 9:10 pm
Re: Verifiying Server Certificate Error
I noticed this issue about a month ago and other are sharing the same experience on github, here are some
- https://github.com/XTLS/Xray-core/issues/2451
- https://github.com/XTLS/Xray-core/discussions/2741
- https://github.com/XTLS/Xray-core/discussions/2450
I simple test with WireShark can show what is the issue.
We have 6 steps (maybe more) for TLS Handshake and the FWs in Iran throttle/disallow TLS Handshake completion. So it never completes.
Any VPN client that does TLS Handshake is no longer able to connect, including
- SSTP
- OpenVPN
- OpenConnect
- AnyConnect
- v2ray clients
- xray clients
- etc
With more test you can see (I tested) that the same server while port 80 is fine and cab be accessed but port 443 (HTTPS) cannot be accessed so they are deliberately targeting port 443 or any TLS Handshake completion
Plus you may see some random days that a blocked server is working fine which to me it means they are testing/experimenting a new FW setup/configuration.
Solution #1
SSH works fine (not always works , it should be tested)
Solution #2
As usual a double VPN (multi hop) either port forwarding or cascade connections
Solution #3
Some people told that WireGuard is able to handle net switch without renewing TLS Handshake so we can connect to a server with phone net-A and after a successful connection switching the phone net to net-B which is a blocked server. WireGuard remains connected
Solution #4
Some people on githbu said a correct Xray Realty configuration cannot be detected and works fine ( I personally do not think so)
Hint
I think mostly we should know how a server is detected , what/which pattern/fingerprint flags a server to a FW so we can avoid any detection at first place.
- https://github.com/XTLS/Xray-core/issues/2451
- https://github.com/XTLS/Xray-core/discussions/2741
- https://github.com/XTLS/Xray-core/discussions/2450
I simple test with WireShark can show what is the issue.
We have 6 steps (maybe more) for TLS Handshake and the FWs in Iran throttle/disallow TLS Handshake completion. So it never completes.
Any VPN client that does TLS Handshake is no longer able to connect, including
- SSTP
- OpenVPN
- OpenConnect
- AnyConnect
- v2ray clients
- xray clients
- etc
With more test you can see (I tested) that the same server while port 80 is fine and cab be accessed but port 443 (HTTPS) cannot be accessed so they are deliberately targeting port 443 or any TLS Handshake completion
Plus you may see some random days that a blocked server is working fine which to me it means they are testing/experimenting a new FW setup/configuration.
Solution #1
SSH works fine (not always works , it should be tested)
Solution #2
As usual a double VPN (multi hop) either port forwarding or cascade connections
Solution #3
Some people told that WireGuard is able to handle net switch without renewing TLS Handshake so we can connect to a server with phone net-A and after a successful connection switching the phone net to net-B which is a blocked server. WireGuard remains connected
Solution #4
Some people on githbu said a correct Xray Realty configuration cannot be detected and works fine ( I personally do not think so)
Hint
I think mostly we should know how a server is detected , what/which pattern/fingerprint flags a server to a FW so we can avoid any detection at first place.