The Amazon instruction is not working out for me (probably some Mystery Setting in the distribution)

[LindaFerum]

Server config:

{
  "ProxyBook": {
    "openvpn": [
      "udp",
      "127.0.0.1:2048"
    ],
    "test": [
      "udp",
      "127.0.0.1:9999"
    ],
    "tor": [
      "tcp",
      "127.0.0.1:9001"
    ]
  },
  "BindAddr": [
    ":443",
    ":80"
  ],
  "BypassUID": [
    "foo",
    "bar"
  ],
  "RedirAddr": "some.site.also.hosted.on.AWS.com",
  "PrivateKey": "bar",
  "AdminUID": "foo",
  "DatabasePath": "userinfo.db"
}

Client config

{
  "Transport": "CDN",
  "ProxyMethod": "openvpn",
  "EncryptionMethod": "aes-128-gcm",
  "UID": "foo",
  "PublicKey": "bar=",
  "ServerName": "d1BLABLABLAj5o.cloudfront.net",
  "CDNOriginHost": "ec2-my-servers-ip-.eu-north-1.compute.amazonaws.com",
  "NumConn": 4,
  "BrowserSig": "chrome",
  "StreamTimeout": 300
}

Not getting anything in server log and getting endless stream of

"Failed to prepare connection to remote: failed to handshake: websocket: bad handshake"

in the client log.

What magic part of amazon config am I missing?

Dear @cbeuw please help :)

may be related to: #63

P.S. edit and yep, "direct" connection establishes session instantly!

[cbeuw]

Cloudfront definitely used to work ~3 years ago. I haven't tested it since but will look into it again. It's possible though that they just shut off domain fronting like cloudflare did.

[cbeuw]

Also I see that you're using UDP. UDP support isn't the best polished and I don't think I ever tested it through CDN (in theory it should work, but in practice...). Could you try to run OVPN on a TCP port?

[LindaFerum]

Hi @cbeuw ! Thank you for prompt response!
I tried running openvpn with TCP and also tried TOR (as a "well understood" TCP service)

In CDN mode it immediately results in "failed to handshake: websocket: bad handshake"

So it looks like either CDN mode is fully broken or Amazon tweaked something that needs to be accounted for (I suspect caching / response policies on Cloudfront side may be to blame, but I tried running both with caching disabled and with several policy variants, with exactly same response)

[cbeuw]

I'm sorry but I probably won't have time to investigate this until August as I have a thesis deadline in a week. While there is definitely something to be fixed, for now may I ask if it's fully necessary that you run it behind a CDN? Because a *.compute.amazonaws.com is highly unlikely to be blocked, and even if one did you could restart your EC2 instance to get a new domain.

[LindaFerum]

No problem, I think I can get away using direct connection for the time being (worst come to worst I'll have to shut down + start up the EC2 instance to get new IPs every now and then)

I'll report back about how it goes

BTW, when you get some time for CDN fixes in august, could you also please look into figuring out the right settings for FLY.IO ?
They have very appealing free tier offering and are "CDN by default" (mandatory CDN for free tier dwellers, functionally)

[notsure2]

CDN mode means that Cloak client expects to connect to a real HTTPS server, and then do a websocket connection to your origin server. So you have to setup your origin server web server to proxy websocket connection to Cloak, or you have to run Cloak itself as the origin webserver (aka port 80). Then CDN mode will work.

Cloak server to accept CDN mode, it accepts an incoming HTTP (not HTTPS) connection with websocket form and a magic header sent by Cloak client containing the crypto challenge. Cloak cannot accept CDN mode on HTTPS simply because it doesn't have a real SSL certificate and cannot do a full proper SSL handshake in response to the incoming HTTPS connection. However, you can engineer a complicated solution that works both ways as follows:

Run cloak on port 443 and make the rediraddr your local nginx instance setup with a real SSL certificate, then setup your nginx to redirect http connections with the Cdn origin path you set in the config (or the magic header I can't remember its name I think it was called "Hidden") back to cloak on port 443 using the http (not https) protocol.

[LindaFerum]

Well, for what it's worth when I was trying to set it up I had Cloak listen both on 80 and 443 and that did not help, but I'll try again when I'm back to civilized country