Cloak seems detected by Gov firewall

[Evolve6996]

hello, recently (like a week or ago) there was a mass blockage of VPNs in my country, I am using openvpn+Cloak, a few days ago my domain address was blocked by the firewall, so I started investigating how they detected it.

last night, first my connection throttled and after a few hours, my VPS IP address was blocked!

I cannot say it 100% because of the cloak but it looks like the cloak is detected, cause symptoms happened when I was mostly using my cloak+openvpn server.

is Cloak using version 112 of Firefox maybe they just somehow figured this out because of the old fingerprints of the cloak?

[Evolve6996]

Update: finally, I managed to run the cloak with cdn.

The connection speed is not bad, but somehow connection drops after like 1 minute!

I have a somewhat similar setup with the same IP with Vmess+ws+cdn and it works fine!

[qwerttvv]

show your config and everything's fine with me

[Evolve6996]

hello, thanks for your replay,

btw I created the same topic on net4people and somebody confirmed cloak is detected. here is the link to other topic: https://github.com/net4people/bbs/issues/327

for the configs I used, I cannot remember exactly but I think I used hirboodbehnam

here is direct mode cloak client config:

{
    "Transport": "direct",
    "ProxyMethod":"openvpn",
    "EncryptionMethod":"aes-128-gcm",
    "UID":"example uid",
    "PublicKey":"example uid publickey",
    "ServerName":"photos.google.com",
    "NumConn":4,
    "BrowserSig":"firefox",
    "StreamTimeout": 300,
    "RemoteHost":"my domain",

}

Cloak server config:

{
  "ProxyBook": {
    "panel": [
      "tcp",
      "127.0.0.1:0"
    ],
    "openvpn": [
      "tcp",
      "127.0.0.1:1150"
    ]
  },
  "BypassUID": [
    "example uid",
    "example uid",
    "example uid",
    "example uid"
  ],
  "BindAddr": [
       ":8443",
  ],
  "RedirAddr": "photos.google.com",
  "PrivateKey": "example privatekey",
  "AdminUID": "example uid",
  "DatabasePath": "userinfo.db",
  "StreamTimeout": 300
}

openvpn client config:

client
proto tcp-client
remote 127.0.0.1 1984
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name server_O9sq2hGIRFpLXcGz name
auth SHA256
auth-nocache
cipher AES-128-GCM
tls-client
tls-version-min 1.3
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
ignore-unknown-option block-outside-dns
setenv opt block-outside-dns # Prevent Windows 10 DNS leak
verb 3
<ca>
-----BEGIN CERTIFICATE-----
MIIB2DCCAX2gAwIBAgIUfi8Tli5jRA9GXW4GWSjXHkBPh6AwCgYIKoZIzj0EAwIw
HjEcMBoGA1UEAwwTY25fTnJTbWNzWkJOVWY3aHc1SzAeFw0yMzExMDIxOTI5MjJa
Fw0zMzEwMzAxOTI5MjJaMB4xHDAaBgNVBAMME2NuX05yU21jc1pCTlVmN2h3NUsw
WTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASc0YV/BS0TcSdVkOvtxywMxdOVgbz2
oC71yYw1afjs+vaMV8wq8jk8IWzOvaaJjFzGDSTGXXrzVYDtEGONKDAXo4GYMIGV
A1UdIwRSMFCAFJKJ/rlJcf765DcPkJJASGN+gq5voSKkIDAeMRwwGgYDVQQDDBNj
bl9OclNtY3NaQk5VZjdodzVLghR+LxOWLmNED0ZdbgZZKNceQE+HoDALBgNVHQ8E
BAMCAQYwCgYIKoZIzj0EAwIDSQAwRgIhALV6yzM1fGMB/QEzO6XnigvxdJDytATa
kXgx8e9zbCetAiEApBQYdYar/LJe2c+DIwfVt367CW3HMI5kmDIRGblQd0w=
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
MIIB3TCCAYKgAwIBAgIRAJDzDivobmLCkanG8o1anY8wCgYIKoZIzj0EAwIwHjEc
MBoGA1UEAwwTY25fTnJTbWNzWkJOVWY3aHc1SzAeFw0yMzExMDIxOTMwMTNaFw0y
NjAyMDQxOTMwMTNaMBQxEjAQBgNVBAMMCW15b3BlbnZwbjBZMBMGByqGSM49AgEG
CCqGSM49AwEHA0IABOQ+RdHeo25sLo5eCpOUOAKuTibBQt0U1mmxZNSkc63pBQP2
9Injyruq4Tpjv3l7UIWD8SHVjkzkVRf4/Ph0JPijgaowgacwCQYDVR0TBAIwADAd
BgNVHQ4EFgQUuxmIltjBL/XDesffN1m6HIe79ggwWQYDVR0jBFIwUIAUkon+uUlx
/vrkNw+QkkBIY36Crm+hIqQgMB4xHDAaBgNVBAMME2NuX05yU21jc1pCTlVmN2h3
A1UdDwQEAwIHgDAKBggqhkjOPQQDAgNJADBGAiEA65XOM4DtDL3Jdfma59s3h6rL
N8VHzNoDz5sES5Aj4jUCIQCAf3eh2LzyeH9Zlcx1Ohw8r3VDtLuXUo0Wp4Jl511E
Fw==
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQglHY0PsZl6i9BcTjK
FNZpsWTUpHOt6QUD9vSJ48q7quE6Y795e1CFg/Eh1Y5M5FUX+Pz4dCT4
-----END PRIVATE KEY-----
</key>
<tls-crypt>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
4b83505dcfdabee9de53b2e2763c0d9e
fbe84abc90eb6ae31366e0b2d66213c5
08f416d90a20cb6899979605432bd11a
2d777034cbc79ac8c92f6dd0fe17e295
9b2378bda83186de7e8963aaa21bb9ea
ec7c71deb81e1680a2506e54af447687
f1d62ec26b202a2f0f484cb12abd8043
fe36bc59d9ba9386f990a6a05779f31e
4cc23bef40eee932334428d4286648ae
74f9406b66a7d3ec9b1b3cb7f38aedc7
b6fa19b2f56890037fec0abae31f7ff1
8846c49d83e31b66b4696dde81112962
49733f89bd3e344216c0247f7f198b22
98342f93ac54665f0fbf9ed19a596cba
-----END OpenVPN Static key V1-----
</tls-crypt>

openvpn server config:

port 1150
proto tcp
dev tun
user nobody
group nogroup
persist-key
persist-tun
keepalive 10 120
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 76.76.10.144"
push "dhcp-option DNS 76.76.2.140"
server-ipv6 fd42:42:42:42::/112
tun-ipv6
push tun-ipv6
push "redirect-gateway ipv6 def1 bypass-dhcp"
push "route-ipv6 2000::/3"
dh none
ecdh-curve prime256v1
tls-crypt tls-crypt.key
crl-verify crl.pem
ca ca.crt
cert server_O9sq2hGIRFpLXcGz.crt
key server_O9sq2hGIRFpLXcGz.key
auth SHA256
cipher AES-128-GCM
ncp-ciphers AES-128-GCM
tls-server
tls-version-min 1.3
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
client-config-dir /etc/openvpn/ccd
status /var/log/openvpn/status.log
verb 3

#local 2a:4951

[cbeuw]

Browser fingerprints are updated in the latest release https://github.com/cbeuw/Cloak/releases/tag/v2.8.0. I'll update the fingerprints a lot more frequently in the future as I've migrated to use utls for producing ClientHello fingerprints

[Evolve6996]

Browser fingerprints are updated in the latest release https://github.com/cbeuw/Cloak/releases/tag/v2.8.0. I'll update the fingerprints a lot more frequently in the future as I've migrated to use utls for producing ClientHello fingerprints

hello, thanks. cloak was one of the first methods I have seen introduced fingerprints this is a good idea 👍

unfortunately, currently, I do not have access to a clean IP address, I will test on CDN to see what happens.

[Evolve6996]

still, no luck on cdn mode connection drops after 1 to 2 minutes. maybe my cdn config is wrong, here is cdn config file :

{
    "Transport": "CDN",
    "ProxyMethod":"openvpn",
    "EncryptionMethod":"aes-128-gcm",
    "UID":"example uid",
    "PublicKey":"example public key",
    "ServerName":"my cloudflare worker domain",
    "NumConn":4,
    "BrowserSig":"firefox",
    "StreamTimeout": 300,
    "RemoteHost":"cloudflare clean ip address",
    "CDNOriginHost": "my cloudflare worker domain"
}

[Evolve6996]

Update: I used Cloudflared (previously known as Argo) tunnel to connect, but the same thing happened as above.

I don't think the problem is the Cloudflare network or my server, something closing the connection. 😕

[sorganov]

Hello!

I'm newbie with this, and once I've installed Cloak server, I tried to connect to it over https:433 from web browser. What I got was "wrong certificate" error from Firefox, as certificate from the site (www.google.com in my case) where Cloack re-directs obviously doesn't match server IP/name where Cloak runs. The first thing I thought was that this fact could be easily used to detect and block Cloak servers using very simple probing for a site that pretends to be something else. Don't we rather need to imitate some "working" www site?

Am I missing something obvious here? Did I misconfigure Cloak?

[uprtdev]

@sorganov you are testing it wrong. If you try to open a real Google (or any other popular service) server through HTTPS using its IP address and 443 port from the browser, you will get the same error message, because the certificate is issued for the domain, not for the IP address. So its absolutely normal that you receive such a certificate error message, it doesn't mean that your Cloak server is vulnerable to probing.

What you need to test if Cloak is working and the camouflage acts as expected, is to try to reach your Cloak's server IP with a "SNI" field equal to the website you are trying to masquerade for. There are two ways how to do it:

1. If you want to test using the browser, you need to first add a record to the /etc/hosts (on Linux), or c:\windows\system32\drivers\etc\hosts (on Windows) with your server IP address and the domain of the site you are masquerading for, for example, if your Cloak server pretends to be www.microsoft.com, you need to add xx.xx.xx.xx www.microsoft.com. After it, you try to open "www.microsoft.com" in your browser, you should see a real Microsoft website without certificate errors, but in fact you'll get a reply from your Cloak server
2. you can try using cURL, curl -v --resolve www.microsoft.com:443:xx.xx.xx.xx https://www.microsoft.com (xx.xx.xx.xx is your Cloak server IP addree) - there should be no certificate errors in cURL output, you should see some valid HTTP headers or even HTML code.

[sorganov]

@uprtdev Thank you for explanations, but probably I was not clear enough in describing my worry. When I connect over HTTPS to my host running Cloack, what I get, say, in Firefox, is:

"Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for . The certificate is only valid for www.google.com."

Isn't it alarming that random sends certificate issued for www.google.com? How much effort would it take to figure that IP has nothing to do with any of www.google.com IPs, and then block such a suspect site?

Anyway, is there a way to re-direct to a HTTP server running on the same host where Cloack is running? That server will supposedly output "site under construction" or something. Is it a sound idea in the first place?

[uprtdev]

Your Cloak client will not try to reach your Cloak server with your_host_name in SNI field, it will do it with www.google.com SNI, and the server will reply with a valid www.google.com certificate. If the censors suspect something, then when they do the request to your server they will get a valid and authentic request, as a real www.google.com does. This is the main idea and purpose of Cloak, that your server pretends to be something it is not :)

The only question may be is that www.google.com domain is not resolved to your server IP address, but in fact that means nothing - such popular resources are usually served with big CDNs, that can have hundreds of different frontend IP addresses.

If you want to have a web server together with your Cloak server, just point Cloak server to 127.0.0.1 and use your own domain in the configuration. But using Cloak for such scheme is in fact an overkill and doesn't make much sense, you can use something simpler like naiveproxy or trojan-go. The purpose of Cloak is bypassing domain whitelists, that's why it is usually used with well-known websites like www.google.com and others.

[sorganov]

I'm positive Cloak-client-to-Cloack-server protocol is fine, so let's get it aside of the issue.

I also admit I have no idea how hard it is to figure that particular suspect IP has nothing to do with www.google.com, so I can only believe you that it's safe enough. If so, the rest is not that important anymore, and is kinda wishful thinking.

I do see how bypassing domain whitelists makes sense in general, thanks for pointing that out. However, as it's not an issue for me yet, I wanted to replace www.google.com as redirect target by the same where Cloack is already running. Besides different safety policy this indeed would give me an opportunity to run my own HTTP server on the same host that runs Cloak server, but that's not the primary goal. Unfortunately it caused me trouble as Cloak seems to have no way to re-direct HTTP to a different port, and I want to ask if such feature makes no sense, or is it just missed?

From your suggestion I didn't understand how will I then be able to connect to Cloak server listening on 127.0.0.1 with Cloak client running on another host? Apparently some IP filtering will be required, and I'd prefer native Cloak feature if it existed.

Thank you for the suggested alternatives, but the Cloak happens to be very easy to configure and use, has a huge benefit of already being up and running, and then it's targeted exactly at my actual use-case, where HTTP (if any at all) is very secondary. It still looks like a nice feature though if it were able to re-direct regular HTTP traffic from host:443 not only to another.host:443, but to, say, host:8443 as well (where supposedly a HTTP server will be listening).

[uprtdev]

According to this it should be possible to specify no-standard port (e.g. 8443) in RedirAddr server parameter.

If it doesn't work, then probably similar behaviour can be achieved by some iptables magic (e.g. DNAT connections to localhost's 443 port to 8443)