SIP002 - Optional extension configurations as query strings in ss URLs

[Mygod]

Shadowsocks Improvement Proposal 002 (actually why don't we just use issue number to refer to them instead)

Optional configurations as query strings in ss URLs

Since #26, there are at least two optional extension for shadowsocks as far as I can tell:

• Kcptun
• HTTP/TLS obfuscation

There may be more extensions in the future. So what about adding them to ss URLs? For example, we can have ss://...?kcpport=8839&kcpcli=--crypt+none......#a+name for easier configuration. Clients that don't support the extensions can safely ignore them.

What should be included:

• Values that should be consistent with server configuration.

What shouldn't:

• Arbitrary values that can be configured by users, like whether the extension is enabled.
• Values that could need changing when copying to other device (except that configuration for client and server can be different), like per-app proxy settings in Android client.

Problems:

• Should client enable the extension that's been configured when importing?
• Should client export the extension configuration even if it's not enabled?

Final version:

SIP002 purposed a new URL schema, following RFC3986:

SS-URI = "ss://" userinfo "@" hostname ":" port [ "/" ] [ "?" query ] [ "#" fragment ]
userinfo = websafe-base64-encode-utf8(method  ":" password)

The last / should be appended if query or fragment is present. Example: ss://YmYtY2ZiOnRlc3Q@192.168.100.1:8888/?plugin=url-encoded-plugin-argument-value&unsupported-arguments=should-be-ignored#Dummy+profile+name. This kind of URIs can be parsed by standard libraries provided by most languages.

For plugin argument, we use the similar format as TOR_PT_SERVER_TRANSPORT_OPTIONS, which have the format like simple-obfs;obfs=http;obfs-host=www.baidu.com where colons, semicolons, equal signs and backslashes MUST be escaped with a backslash.

[Mygod]

I don't think that's a good idea.

[shinku721]

Well can we set up a standard of URIs? Could someone please tell me what currently used URIs look like?

Edit: Standardize one, deprecate others

[Mygod]

@madeye Should we settle this now?

[madeye]

Yes, could you also add a wiki page about the new URL?

[Mygod]

No. :upside_down_face:

[madeye]

😓

[Mygod]

@madeye I'll let you decide which one we would use. :stuck_out_tongue:

[Mygod]

So what's the conclusion?

[madeye]

@Mygod I think it's settled as https://github.com/shadowsocks/shadowsocks-org/issues/27#issuecomment-272366304.

[jibon57]

@madeye Will you please give an example of KCPTun? Is that like this:

Plugin: client_windows_amd64.exe
Plugin Options: ss://passwd@host:port/kcptun;mode=fast;crypt=aes-128

[zonyitoo]

Since SIP022 have already make "password" to become a base64 of the PSK, we may not need to base64 encode the userinfo anymore.

Futher more, go2-shadowsocks2 assumes userinfo is not encoded: https://github.com/shadowsocks/go-shadowsocks2/blob/71a35d3383128957db1327991445fca643feb4e2/main.go#L189-L201

So here I suggest SIP002 should allow userinfo to not being encoded, and implementations should handle both 2 forms. For AEAD-2022 ciphers, userinfo in SIP002 MUST NOT be encoded (just for unifying all implementations' behaviors).

Suggestions have been added to https://github.com/shadowsocks/shadowsocks-org/wiki/SIP002-URI-Scheme

cc @madeye @Mygod @riobard

[madeye]

I think it's too late to change SIP002. A alternative change is adding ss2:// scheme in SIP022.

[zonyitoo]

I think it is Ok to just change SIP002's spec about allowing plain text user-info, because you can always use the old SIP002 URL to represent SIP022 methods. So plain text user-info is just an extension of SIP002.

[madeye]

So, some clients have to implement fallback logic for the initial scheme and previous SIP002 scheme, which seems too complicated.

[database64128]

So, some clients have to implement fallback logic for the initial scheme and previous SIP002 scheme, which seems too complicated.

It's actually quite simple: just look for :. All clients I know, including shadowsocks-android, already support it.

[database64128]

A alternative change is adding ss2:// scheme in SIP022.

That's basically what I proposed initially (except I went with ss-2022://). But @zonyitoo had me convinced that a new scheme is not necessary. So I removed the proposal from SIP022.

[madeye]

Seems no further objections to the change. Let's finalize SIP002 to allow non-encoded user-info.

[cloverzrg]

ss://v2;xxx