feat(www): support server name on dynamic keys

[daniellacosse]

Adds the functionality for determining the server name that's on ss:// to ssconf://

[taxi-c]

Could it be possible to add support for extra fields over Dynamic Access Keys?
A way to redefined/overload some informations in the json files?
For example ssconf://s3.amazonaws.com/a-cool-s3-bucket/my-access-key.json:password=dfghjdfgh

[daniellacosse]

Could it be possible to add support for extra fields over Dynamic Access Keys? A way to redefined/overload some informations in the json files? For example ssconf://s3.amazonaws.com/a-cool-s3-bucket/my-access-key.json:password=dfghjdfgh

This could extend into that at some point - but what's your use case?

[taxi-c]

I don't want to have multiple bucket to update. The idea is : one bucket define one server { server, method and perhaps port}.
But the password is different for every users.
So the password (and perhaps port), could be in the ssconf:// link.
If i change the server ip, i just need to change one bucket.

It's like owning a domain, but it will be free of charge and anonymous (for the domain part)

[daniellacosse]

I don't want to have multiple bucket to update. The idea is : one bucket define one server { server, method and perhaps port}. But the password is different for every users. So the password (and perhaps port), could be in the ssconf:// link. If i change the server ip, i just need to change one bucket.

It's like owning a domain, but it will be free of charge and anonymous (for the domain part)

The issue is potenitally exposing a person's password in plaintext this way. Is that something we'd be comfortable with @fortuna or would it be a security issue

[fortuna]

@taxi-c thanks for sharing your use case.

We are looking into an advanced config format. For example:

{
  "type": "OutlineService",
  "dialer":  {
    "type": "Shadowsocks",
    "socket": { "host": "1.2.3.4", "port": 443},
    "encryption": {
      "cipher": "chacha20-ietf-poly1305", "secret": "1234"
    }
  }
}

I can imagine a world where the objects can be references instead. For example:

{
  "type": "OutlineService",
  "dialer":  {
    "type": "Shadowsocks",
    "socket": "https://example.com/server_info",
    "encryption": {
      "cipher": "chacha20-ietf-poly1305", "secret": "1234"
    }
  }
}

Or more explicitly:

{
  "type": "OutlineService",
  "dialer":  {
    "type": "Shadowsocks",
    "socket": { "type": "Ref", "location": "https://example.com/server_info"},
    "encryption": {
      "cipher": "chacha20-ietf-poly1305", "secret": "1234"
    }
  }
}

Then https://example.com/server_info, could contain:

{"host": "1.2.3.4", "port": 443}

But it will take some time to support these, we have a lot of work to do to decouple the networking logic from our per-platform code.

[taxi-c]

i'm not familiar with the "outline" model-threat but in the new version of shadowsocks 2022, it's seems that base64URL should be avoid. But not everybody agree. Whatever, if it's a security issue, the extra fields could be encoded in base64.

shadowsocks/shadowsocks-org#196 (comment)
Excessive and unnecessary usage of base64 encoding in URLs is a bad practice, and must be discouraged.

https://shadowsocks.org/guide/sip002.html
For AEAD-2022 (SIP022), userinfo MUST NOT be encoded with Base64URL.

[taxi-c]

@fortuna I understand. But in the online configuration Delivery (SIP008) of shadowsocks, the json file version 1, is different.
https://shadowsocks.org/guide/sip008.html
Perhaps, it's planned to have a new version?

And i also think for my convenience use case, Outline manager will not manage all the web references (one for the server and many for all the client), and probably none of them. So i'll have to manage these references. If i have just the server reference to maintain up to date, it will be easy. And i can expect outline-manager give me the extra field password (encoded or not) in the share access option.

I also don't know if you plan to implement the shadowsocks2022 version (SIP022), who sounds great against probing.