Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

from verb doesn't behave as documented when using a different atSign #54

Open
cpswan opened this issue Mar 15, 2023 · 2 comments
Open
Assignees
Labels
bug Something isn't working

Comments

@cpswan
Copy link
Member

cpswan commented Mar 15, 2023

Describe the bug

The docs presently state:

If the user who is trying to connect is not the owner of the atServer, then the from verb should respond with the following response.

proof:<sessionid>@<@sign>:<UUID>

If the user is not allowed to connect to the atServer, then it should respond back with the following error and close the connection to the server.

error:AT0013-Connection Exception

But if I try from:anotheratsign then the actual response is:

error:AT0401-Exception: Certificate Verification Failed

Steps to reproduce

  1. First I lookup cpswan in the atDirectory, which is 8fe461b7-9d18-5ccf-9e3b-9ffe4cd09571.canary.atsign.zone:1912
  2. Then I openssl s_client 8fe461b7-9d18-5ccf-9e3b-9ffe4cd09571.canary.atsign.zone:1912
  3. And then I from:colin or from:@colin or from:infrafon_0058
  4. The response is error:AT0401-Exception: Certificate Verification Failed

Expected behavior

The response should be: proof:<sessionid>@<@sign>:<UUID>

Additional context

If I try to use an atSign that doesn't exist e.g. from:anywhere then I (correctly) get:

error:AT0007-Exception: Unable to find secondary address for atSign:anywhere
@cpswan cpswan added the bug Something isn't working label Mar 15, 2023
@gkc
Copy link
Contributor

gkc commented Mar 15, 2023

  • The only allowed scenario for an atSign client to connect to an atServer of another atSign is when that atSign client is itself an atServer.
  • The first step in the server-to-server handshake is to verify the certificate that the other server presents
  • A more user-friendly message can be presented when a client connects without a certificate, but the response should not be a proof: message

@cpswan
Copy link
Member Author

cpswan commented Mar 15, 2023

We should probably be clearer about things that can only be done atServer-atServer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants