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

Make using insecure http/ws connections an explicit opt-in #1239

Closed
jsdw opened this issue Nov 3, 2023 · 0 comments · Fixed by #1309
Closed

Make using insecure http/ws connections an explicit opt-in #1239

jsdw opened this issue Nov 3, 2023 · 0 comments · Fixed by #1309
Assignees

Comments

@jsdw
Copy link
Collaborator

jsdw commented Nov 3, 2023

Currently, connecting to insecure http or ws endpoints is just as easy as connecting to secure https/wss once (via either the Subxt library or the CLI tool).

A suggestion from @uzeyirdestan (who has been looking at potential sexurity issues in Subxt) is to make it a more explicit action to "opt-in" to insecure connections.

So, let's define any HTTP/WS connection apart from to localhost/127.0.0.1 as insecure.

Given this, one option would be something like:

  1. On the CLI tool, require an --allow-insecure flag to be allowed to make an insecure connection (else, it will be rejected), and
  2. In the library, for OnlineClient, add a from_insecure_url which allows insecure URLs, and prevent them via from_url
  3. In the library, for LightClient connections to URLs, have something like build_from_insecure_url to complement build_from_url.
  4. The macro also allows fetching metadata from any URL via from_runtime_url, but that's already meant to be dev only, so just make sure we document that it should be avoided in general.

Have I missed any other places where we establish a connection?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants