zonyitoo

commit time in 3 days ago

zonyitoo

add stargazers

commit sha： 81c3fbe60ef14f2116d092285d806f6c4d0bd845

push time in 3 days ago

commit time in 3 days ago

zonyitoo

make "password" optional for none/plain method (#838)

commit sha： 77d343eb980234db14e2a179de98a7de408a3cfd

push time in 3 days ago

issue

zonyitoo issue shadowsocks/shadowsocks-rust

zonyitoo

zonyitoo NONE

createdAt 3 days ago

Make password optional.

I just found out that when I use plain/none I still have to write something here even if it will do nothing. So, maybe we can make password optional? I use TLS to protect transport security and I already set a specific path for it.

commit time in 3 days ago

zonyitoo

make "password" optional for none/plain method (#838)

commit sha： d8ba402b2f7616bb2e3f094d9186ad3d474f1e76

push time in 3 days ago

May

4 days ago

zonyitoo

fixed PingBalancer checker panic when servers is empty

commit sha： 76f8b021c8fb6f4cd53530b4088f57e5bd8617a0

push time in 4 days ago

zonyitoo

allow sslocal run without servers (#818)

If no server was configured, then sslocal will bypass all connections and packets.

commit sha： 855f7fa8f126586d3fafcc8a94ee5cb32259fa72

push time in 4 days ago

zonyitoo

apply timeout on server handshake

commit sha： 5146c7d20bf5d3306976aa0bc66dea55df30178d

push time in 4 days ago

issue

zonyitoo issue comment shadowsocks/shadowsocks-org

zonyitoo

zonyitoo CONTRIBUTOR

createdAt 4 days ago

enhancement

SIP002 - Optional extension configurations as query strings in ss URLs

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://[email protected]: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.

zonyitoo

comment in 4 days ago

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.

zonyitoo

check REQUEST_SALT only when received at least 1 data chunk

commit sha： 365740a0a171db110da55491307538822358e673

push time in 4 days ago

zonyitoo