Received an error while attempting to accept a connection:clientConfirmationCode and server copy not equal

[otonoton]

I recently updated from an old version of this program which was working fine using obfs4, but now so many things have changed and there is so little documentation I am completely lost. I didn't even know obfs4 is no longer supported and could not find any info on this except for a closed github issue.

Also, there seems to be no documentation on how to generate a config anymore. The only reference to using -generateConfig anywhere on the internet is in that same closed github issue on this repo. I'm probably just doing something wrong so please correct my commands as necessary.

Anyways, I tried to generate a config with:

shapeshifter-dispatcher -transport shadow -serverIP my.public.ip.here:443 -generateConfig

Which produces the two client/server json files. Also "my.public.ip.here" is indeed the external IP of my server, however it is NOT a local IP that's actually attached to an interface on the machine because this is a cloud VM, if that matters. The only local address is in a private range.

The server config:

{
  "serverAddress": "my.public.ip.here:443",
  "serverPrivateKey": "<redacted>",
  "cipherName": "darkstar",
  "transport": "Shadow",
  "logDir": null
}

I had to change "my.public.ip.here" in the server config to 0.0.0.0 in order to get the server to start. No idea if this is confusing anything. Also why is serverAddress and bindaddr needed? This doesn't make sense to me.

I start the server with:

shapeshifter-dispatcher -transparent -server -state state -target 127.0.0.1:22 -transport shadow -bindaddr shadow-0.0.0.0:443 -optionsFile ShadowServerConfig.json -logLevel DEBUG -enableLogging

The client config is:

{
  "serverAddress": "my.public.ip.here:443",
  "serverPublicKey": "<redacted>",
  "cipherName": "darkstar",
  "transport": "Shadow",
  "logDir": null
}

And I start the client with:

shapeshifter-dispatcher -transparent -client -state state -transports shadow -proxylistenaddr 127.0.0.1:8888 -optionsFile ShadowClientConfig.json -logLevel DEBUG -enableLogging

But then upon trying to telnet 127.0.0.1 8888 on the client, I look at the server and it has printed out:

shadow listening on 0.0.0.0:443
accepted
Received an error while attempting to accept a connection:clientConfirmationCode and server copy not equal

With nothing relevant in dispatcher.log on either side. The client side printed out this:

Dialing
--> Unable to dial transport server:  EOF
-> Name:  shadow
-> Options:  {
  "serverAddress": "my.public.ip.here:443",
  "serverPublicKey": "<redacted>",
  "cipherName": "darkstar",
  "transport": "Shadow",
  "logDir": null
}

Any idea what is going on? I've not been able to get any other similar program to work at all or even remotely gotten this close, so this is my last hope. Thanks

[otonoton]

I should mention this is all using the latest HEAD commit of 5a0a004883c31e7e673e75fa323f3f5edc61c5bf. I tried going back to the current tagged release of v3.0.1 but it would not build for me, it seemed to need a change in shapeshifter-ipc that was made in its 3.0.2 version but trying to change that version in go.mod still wouldn't build due to other issues, and with the latest commit in this repo it seems the ipc package isn't even used anymore so I'm quite confused. Admittedly I'm not a go programmer so I'm not familiar with all these details.

[CryptoSax]

Your commands to run dispatcher, your configs, and the commands you used to generate them all look fine. The issue is that 443 is a dedicated port for https traffic and the telnet client isn't going to know how to send a properly constructed request to initiate a https handshake. Bindaddr and ServerAddress are both needed because proxies always need two addresses. The ServerAddress in the config is the destination address to the server. The bind address is the listening address on the client. Additionally, I made some changes to the README to reflect some of the missing information you mentioned. Thank you for bringing that to our attention! Let us know if there's anything else you can help with.

[blanu]

You cannot use 0.0.0.0 for the server address. Part of the cryptographic handshake is verifying that the server and client have the same address for the server. Using 0.0.0.0 on the server configuration and a different IP for the server on the client confirmation will cause the cryptographic handshake to fail, giving the "clientConfirmationCode and server copy not equal" that you see. If the public IP of the server and the bind address IP of the server do not match, you will be unable to run the Shadow transport. However, this is usually not a problem for Cloud VMs as it would mean that the Cloud VM was behind NAT. You generally cannot run any kind of server behind NAT and you certainly can not run the Shadow transport behind NAT due to the feature of IP address verification.

My recommendation would be to try setting the IP address for the server to the same IP on both the client and the server (the public IP of the server) and see if that works.

[otonoton]

In my experience servers work just fine behind NAT when used with proper port forwarding. Not being able to support this means shutting out most of the largest cloud providers because they assign private IPs to the local interfaces, and public IP's are configured outside of the VM instance through loud balancers, NAT gateways and the like. Off the top of my head, Amazon, IBM, Rackspace, AliYun, DigitalOcean and probably many others, all use some type of NAT. Please consider supporting this as it is a non-starter for me and many others without dedicated server colocation.

[blanu]

For the benefit of others reading these issue comments on github, I do not think that this analysis of the widespread use of NAT by cloud server providers is accurate. It is possible to get a cloud provider where the local IP and the public IP are the same. There are many instances of this application running on production servers on many cloud providers. In particular, we have tested extensively with Digital Ocean and we haven't had any problems, so I can say for sure that it should work fine on Digital Ocean without any special configuration.

We will certainly take note of your feature request to develop a version of the Shadow transport that works behind NAT. I think this should be possible to enable in the future by simply providing an option to give two IPs to the transport: one that it should bind to locally and the public IP to use in the cryptographic protocol exchange. I don't think this seems too difficult, so we'll get working on this straight away and update this issue when the feature is available. Thanks so much for the helpful feedback!