SS é o original, SSR é uma versão de terceiros derivada do original, compatível com o protocolo original, e possui algumas funções de camuflagem (protocolo e confusão) mais do que o original.
Também há muita discussão sobre SSR na Internet, tanto a favor quanto contra, mas também para usuários comuns. Seja SSR ou SSR, pode ajudar você a escalar a parede normalmente no momento.
Quanto à versão do cliente que você baixa, tudo depende se o SSR ou SSR está instalado no servidor da conta SS que você comprou. A função SS mais original pode ser usada independentemente do cliente que seja baixado, mas se você quiser usar as funções do SSR (protocolo e confusão), deve baixar o cliente SSR.
Mas não se preocupe, todos os nós que fornecemos suportam compatibilidade com SSR e SSR. Recomenda-se usar SSR. Mais rápido para evitar ser harmonizado!
Houve muito barulho sobre Shadowsocks há algum tempo, e recentemente ficou claro que um grande número de novatos foi atraído pelos chamados "Shadowsocks Aprimorados" (ShadowsocksR). Como desenvolvedor amador implementando Shadowsocks em C++/Qt, gostaria de expressar brevemente minha opinião sobre esses dois frangos fritos.
ShadowsocksR
Não sei se o desenvolvedor por trás disso tem experiência ou equipe, mas o que sei é que o autor dele fez um código fechado para o cliente Shadowsocks C# para seu desenvolvimento secundário, violando a GPL. Não vamos falar sobre outros fatores aqui, o fato é que a GPL é muito clara em preto no branco, violar é violar. Mas o autor então abriu o código, o que pode ser considerado o fim de um incidente, e não há necessidade de investigar mais.
As coisas mudaram depois que Clowwindy esvaziou sua loja de códigos Shadowsocks. A seguir estão apenas uma lista de fatos:
O autor do ShadowsocksR disse que quer começar do zero para criar uma nova ferramenta proxy que não esteja relacionada ao shadowsocks, e não vai mais atualizar o ShadowsocksR
Dois ou três dias depois, ordenaram que o ShadowSocks fosse excluído, e o projeto original do ShadowSocks basicamente desapareceu
O autor de ShadowsocksR disse que o protocolo original de shadowsocks estava falho (discutido na próxima seção) e voltou ao foco
O autor do ShadowsocksR criou um Grupo do Google+ e atualizou o código relacionado ao ShadowsocksR
Segurança dos Shadowsocks
Agora, vamos começar com a descrição da afirmação do autor do ShadowsocksR de que a falha do protocolo Shadowsocks é que o comprimento do IV é de 16 bytes na maioria dos casos. A segunda metade está correta, muitos algoritmos de criptografia usam IVs com 16 bytes de comprimento (especialmente os populares AES e RC4-MD5), e daí? Isso não introduz os chamados "defeitos" pelos seguintes motivos:
O IV de cada conexão TCP na etapa de handshake é gerado aleatoriamente, não calculado a partir da senha, então o IV é imprevisível.
Sem a chave, mesmo que essa parte do IV seja interceptada, o texto cifrado não pode ser descriptografado. E cada nova conexão TCP usa um IV gerado aleatoriamente, ou seja, os dados interceptados de diferentes conexões TCP têm pouco em comum. Decifrar texto cifrado requer tanto o IV correto quanto a cifra, e qualquer conexão não possui características sobre a cifra.
A maioria dos IVs tem 16 bytes de comprimento, o que é uma possível combinação de 256 para a potência de 16, e é impossível forçar a quebra quando todos os IVs são iguais, muito menos adicionar um segundo ponto.
De acordo com a abordagem do ShadowsocksR, é inútil adicionar o chamado cabeçalho de ofuscação antes da primeira conexão, suas próprias características são óbvias, e isso não altera a essência do IV posterior ou do comprimento fixo de forma alguma. Como o quarto byte mostra o comprimento dos dados preenchidos aleatoriamente, desde que você pule a pilha anterior ao realizar a chamada "sondagem", você ainda pode interceptar IV. E como eu disse alguns pontos atrás, é inútil se você pegar esse IV aleatório. Se for usado para detecção, a primeira versão fixa do logo é o recurso nu enviado para identificação.
O autor do ShadowsocksR atualmente fornece um script de detecção ativa que pode ser usado para identificar se o servidor está rodando shadowsocks, e de acordo com os relatórios de testes online atuais, a taxa de sucesso não é baixa (mas não é 100%). Nesse sentido, a Clowwindy já ofereceu uma solução de banimento automático na versão original, bloqueando automaticamente esses IPs maliciosos. Acabei de adicionar um patch ao libQtShadowsocks e esse patch bloqueia a detecção desse método, que retorna cadeias aleatórias de comprimento aleatório de acordo com a probabilidade aleatória.
No entanto, isso não significa que o protocolo Shadowsocks seja perfeito, mas que a "solução" de ShadowsocksR é tortuosa porque seu foco é torto. Minha ideia pessoal é usar chaves públicas e privadas para melhorar a segurança, embora não seja muito amigável para iniciantes, mas a segurança será melhorada, as características serão reduzidas (não é necessário enviar IVs na fase de handshake), e o protocolo Shadowsocks precisa se desenvolver na direção da segurança CCA.
Atualizado em 05-set-2015
Uma vez que o erro no cabeçalho (que não pode ser resolvido) seja encontrado, o IV e IP errados serão adicionados à lista de IV e IP falhados; se o IV já existir na lista de IV falhado, ou se o IP já existir na lista de IP falhado, o IP que enviou a solicitação de conexão será adicionado à lista negra, e o IP na lista negra rejeitará diretamente a conexão. Para os detalhes mais recentes sobre antidetecção, consulte esta edição, e este artigo não atualizará as contramedidas para antidetecção.
Atualizado em 06-set-2015
Este artigo só quer dizer para você não se preocupar tanto com a segurança do Shadowsocks, o protocolo atual ainda não teve vulnerabilidades graves, e os servidores das portas principais também estão sendo atualizados para corrigir ameaças potenciais. Também me dei bem com o autor de ShadowsocksR, e vai demorar um pouco até a whitelist chegar.
Atualizado em 24-set-2015
A segurança do Shadowsocks mencionada neste artigo refere-se mais à segurança do servidor, e o protocolo atual tem o risco de expor o servidor à detecção por força bruta e depois ser bloqueado por firewalls (embora o custo da detecção seja muito alto). A segurança do conteúdo transmitido não deve ser preocupada, todos eles são algoritmos de criptografia de alta força de nível industrial (exceto RC4 e TABLE), e é quase impossível decifrar o conteúdo transmitido.
Atualizado em 18-Nov-2015
O Shadowsocks melhorou sua segurança contra CCA ao adicionar uma única verificação, e os principais ports já concluíram seu suporte. É importante reiterar que o objetivo do Shadowsocks não é ser 100% livre de bugs ou 100% à prova de balas, mas garantir que a conexão seja leve e rápida, tornando os métodos de ataque comuns caros demais para implementar.
|
Publicado em 10/11/2017 12:41:35
|
|
|
