ShadowsocksR Best Practices

johnny

This thread proposes a configuration for ShadowsocksR (SSR). If you have ideas for improving this configuration, please add your ideas in the comments.

We will start with the password. I suggest using 96 random bits (12 random bytes). On any Linux system with OpenSSL, you can generate a 12-byte random password, expressed as 16 base-64 characters, with the command:

openssl rand -base64 12

The response will look something like this (this is just an example):

wUYeXnuJGSCAwach

For the protocol, I suggest auth_chain_a. This protocol aims to resist two kinds of attack:

• In a chosen-ciphertext attack (CCA), an adversary probes the server by transmitting thousands of messages and observing the responses
• In a replay attack, an adversary records valid messages then retransmits them, attempting to trick the server into responding
  

The encryption method is set to "none" in the configuration, since auth_chain_a automatically implements Rivest Cipher 4 (RC4) encryption. RC4 is not considered secure by itself, but in auth_chain_a, the hash of each message is used to obfuscate the next message. The use of one message to obfuscate the next message is why the word "chain" appears in the protocol name. This makes auth_chain_a more secure than RC4 on its own.

After the sender has applied RC4 encryption, the sender calculates a Message Authentication Code (MAC). The receiver uses the MAC to authenticate the payload. Authentication works as follows. Both sender and receiver know a shared secret key. The sender uses the shared secret key to calculate the MAC. The receiver independently recalculates the MAC using the shared secret key. If the receiver's calculated MAC is the same as the MAC it received from the sender, it knows the payload has not been tampered with.

For auth_chain_a to work, the client and server must have their clocks coordinated, so that they are at least on the same UTC date.

The protocol_param in auth_chain_a defines the maximum number of concurrent clients. If protocol_param is not set, SSR will not place a fixed limit on the number of concurrent clients.

For server port and obfuscation, I divide the possibilities into three categories:

• Port 80 and http_simple obfuscation
• Port 443 and tls1.2_ticket_auth obfuscation
• Some random port, with frequent changes of port and password
  

In the cases of port 80 and port 443, the recommendation is to build a real website and have your web server listen on port 80 or port 443, as appropriate. As a starting point for discussion, I propose the simplest possibility, which is port 80 with http_simple obfuscation.

We make realistic use of the SSR server's redirect capability:

• SSR listens on the public IP address port 80
• Nginx web server listens on localhost port 80
• SSR redirects invalid SSR messages to Nginx
• Nginx returns a real web page
  

The Nginx site configuration listen line looks like this:

listen 127.0.0.1:80 default_server;

The proposed SSR server configuration file looks like this:

{
    "server": "SERVER.PUBLIC.IPv4.ADDRESS",
    "server_ipv6": "::",
    "server_port": 80,
    "local_address": "127.0.0.1",
    "local_port": 1080,
    "password": "wUYeXnuJGSCAwach",
    "method": "none",
    "protocol": "auth_chain_a",
    "protocol_param": "",
    "obfs": "http_simple",
    "obfs_param": "",
    "speed_limit_per_con": 0,
    "speed_limit_per_user": 0,
    "additional_ports" : {},
    "additional_ports_only" : false,
    "timeout": 120,
    "udp_timeout": 60,
    "dns_ipv6": false,
    "connect_verbose_info": 0,
    "redirect": "*:80#127.0.0.1:80",
    "fast_open": false
}

Replace SERVER.PUBLIC.IPv4.ADDRESS with your server's actual IP address. In cloud services such as Amazon Web Services (AWS), replace the SERVER.PUBLIC.IPv4.ADDRESS with the server's internal IPv4 address. You can use the Linux ifconfig command to determine the internal IPv4 address.

In the server configuration, obfs_param is left empty.

In the client configuration, obfs_param is set to the real hostname, e.g. http://www.example.com.]www.example.com. This should be the actual hostname of your server. There should be a DNS "A" record for the hostname, which points to the server's public IPv4 address. Hence, to a casual visitor, it looks like a normal website.

The SSR client configuration looks like this:



Comments and improvements are welcome.

Sources

https://www.zfl9.com/ssr.html https://www.zfl9.com/ssr.html

https://doubibackup.com/hi10k-7p-3.html https://doubibackup.com/hi10k-7p-3.html

https://web.archive.org/web/20170607110114/  https://breakwa11.blogspot.com/2017/05/auth-chain-a.html https://web.archive.org/web/20170607110114/  https://breakwa11.blogspot.com/2017/05/auth-chain-a.html

https://github.com/shadowsocksrr/shadowsocks-rss/blob/master/doc/auth_chain_a.mdhttps://github.com/shadowsocksrr/shadowsocks-rss/blob/master/doc/auth_chain_a.md

https://www.tipsforchina.com/how-to-setup-a-fast-shadowsocks-server-on-vultr-vps-the-easy-way.html https://www.tipsforchina.com/how-to-setup-a-fast-shadowsocks-server-on-vultr-vps-the-easy-way.html

jichang

Wannaflix recommend:

Encryption algorithm: chacha20 (Recommended). Chacha20 is a 256-bit encryption algorithm that is used by big companies such as Google and in https encryption. It is faster than AES and provides faster internet (Mbps) on routers and mobile devices. AES 256-bit encryption is the standard for most VPNs.

Transmission Protocol: auth_sha1_v4 (Recommended). Our VPN disguises its traffic as the protocol chosen above. We recommend auth_sha1_v4 at this time.

Obfuscation Type: http_simple (Recommended). http_simple disguises VPN traffic as http traffic and so can be useful in bypassing ISP throttling. plain has no special identifying marks, so is harder to be detected as a VPN than http_simple but may be subject to ISP throttling. We recommend plain for users in China, and http_simple for everywhere else.