Send-to-relay security

[pepa65]

Is your feature request related to a problem? Please describe. The problem is described in the last section of https://schollz.com/blog/croc9/ A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like The solution was also hinted at in the same section, but I couldn't find whether it was implemented. The version number is still 9.

Describe alternatives you've considered I've looked through past issues and their closure from after 2021-04-23, but could find no clear indication that this got fixed.

Additional context Just curious if it was found to not be serious enough, or that it actually got fixed.

[schollz]

Here is the relevant code: https://github.com/schollz/croc/blob/main/src/tcp/tcp.go#L439-L548

croc connects to the relay using TCP so it uses SPAKE2 to ensure encryption over-the-wire, although as pointed out in the blog this does not guarantee authenticity of the relay. However, I will note that the relay-client connections shares very little information. The information that the is exchanged during this connection between the client and relay is the following:

• ip address of the client (for sharing with the other client)
• ports to connect to (for sharing with the client)
• room requested (which is later used by the clients to perform their PAKE to securely communicate through the relay)

Sure it would be better to ensure the relay-client connection authenticity to avoid the worst case scenario (and unlikely event) that an active attacker impersonates a relay and then uses the room requested to try to access the data. However, in such a scenario, the room information alone still won't let an attacker figure out the entire code phrase, and since they only have one attempt at the code phrase its extremely unlikely it will succeed. That said, I would happily take a PR that performs authentication of the relay server to totally eliminate this possibility.

[pepa65]

Good to hear it's all duly considered and not somehow forgotten. So nobody needs to wait for version 10 to appear before using croc (I myself have been using it, and I am grateful for it). But from your last sentence it sounds like there is a way that authentication of the relay server could happen that doesn't make it more complicated for users and cannot easily be emulated by an attacker, is that correct? It would just need to be implemented??

[schollz]

Yes that's correct. I have the implementation in my mind, and I aim to get it out unless someone beats me to it. Basically the relays will have to generate keypairs and the public key will need to be shared, then the relay communication can be authenticated. Sorry I haven't done this yet, so many life things are in the way!

[pepa65]

the public key will need to be shared

This sounds like it might be more difficult for users to start using croc. In that case, would it be possible to make it optional? If not, perhaps better leave it as-is..?

[schollz]

It actually should be really easy - everything would be done "under the hood" so to speak

[github-actions[bot]]

Stale issue message