SS es el original, SSR es una versión de terceros derivada del original, compatible con el protocolo original y tiene algunas funciones de camuflaje más específicas (protocolo y confusión) que el original.
También hay mucha discusión sobre SSR en Internet, tanto a favor como en contra, pero también para usuarios corrientes. Ya sea SSR o SSR, puede ayudarte a escalar el muro normalmente en este momento.
En cuanto a la versión del cliente que descargues, todo depende de si SSR o SSR está instalado en el servidor de la cuenta de SS que compraste. La función SS más original puede usarse independientemente del cliente que se descargue, pero si quieres usar las funciones del SSR (protocolo y confusión), debes descargar el cliente SSR.
Pero no te preocupes, todos los nodos que ofrecemos soportan compatibilidad con SS y SSR. Se recomienda usar SSR. ¡Más rápido para evitar que te armonez!
Hace un tiempo hubo mucho ruido sobre Shadowsocks, y últimamente está claro que un gran número de novatos se han sentido atraídos por los llamados "Shadowsocks Enhanced" (ShadowsocksR). Como desarrollador aficionado a la implementación de Shadowsocks en C++/Qt, me gustaría expresar brevemente mi opinión sobre estos dos pollos fritos.
Socalcetines Sombrombra
No sé si el desarrollador tiene experiencia o equipo, pero lo que sí sé es que su autor sí hizo un código cerrado del cliente Shadowsocks C# para su desarrollo secundario, violando la GPL. No hablaremos de otros factores aquí, el hecho es que la GPL es muy clara en blanco y negro, violar es violar. Pero el autor entonces abrió la base de código, lo que puede considerarse el final de un incidente, y no hay necesidad de profundizar más.
Las cosas cambiaron después de que Clowwindy vació su tienda de códigos Shadowsocks. A continuación se presentan solo una lista de hechos:
El autor de ShadowsocksR ha dicho que quiere empezar de cero para escribir una nueva herramienta proxy que no esté relacionada con shadowsocks, y que ya no actualizará ShadowsocksR
Dos o tres días después, se ordenó eliminar ShadowSocks y el proyecto original de ShadowSocks prácticamente desapareció
El autor de ShadowsocksR dijo que el protocolo original de Shadowsocks tenía fallos (se discute en la siguiente sección) y volvió a centrarse
El autor de ShadowsocksR ha creado un Grupo de Google+ y ha actualizado el código relacionado con ShadowsocksR
Seguridad de los Shadowsocks
Ahora, empecemos con la descripción de la afirmación del autor de ShadowsocksR de que el fallo del protocolo de Shadowsocks es que la longitud del IV es de 16 bytes en la mayoría de los casos. La segunda mitad es correcta, muchos algoritmos de cifrado usan IVs de 16 bytes (especialmente los populares AES y RC4-MD5), ¿y qué? Esto no introduce los llamados "defectos" por las siguientes razones:
El IV de cada conexión TCP en la etapa de handshake se genera aleatoriamente, no se calcula a partir de la contraseña, por lo que el IV es impredecible.
Sin la clave, incluso si esta parte del IV es interceptada, el texto cifrado no puede ser descifrado. Y cada nueva conexión TCP utiliza un IV generado aleatoriamente, es decir, los datos interceptados de diferentes conexiones TCP tienen poco en común. Descifrar el texto cifrado requiere tanto el IV correcto como el cifrado, y cualquier conexión no tiene características sobre el cifrado.
La mayoría de los IVs tienen 16 bytes, lo que es una posible combinación de 256 contra la potencia de 16, y es imposible romper a la fuerza bruta cuando todos los IVs son iguales, y mucho menos añadir un segundo punto.
Según el enfoque de ShadowsocksR, es inútil añadir el llamado encabezado de ofuscación antes de la primera conexión, sus propias características son evidentes y no cambia en absoluto la esencia del IV posterior ni de la longitud fija. Como el cuarto byte te indica la longitud de los datos rellenados aleatoriamente, mientras te saltes la pila anterior al realizar la llamada "sondeo", aún puedes interceptar IV. Y como dije hace unos puntos, es inútil si te sale este IV aleatorio. Si se usa para la detección, la primera versión fija del logotipo es la característica desnuda enviada para identificación.
El autor de ShadowsocksR proporciona actualmente un script de detección activa que puede usarse para detectar si el servidor está ejecutando shadowsocks, y según los informes de pruebas online actuales, la tasa de éxito no es baja (pero tampoco del 100%). En este sentido, Clowwindy ya ha dado una solución de baneo automático en la versión original, bloqueando automáticamente estas IPs maliciosas. Acabo de añadir un parche a libQtShadowsocks y este parche bloquea la detección de este método, que devuelve cadenas aleatorias de longitudes aleatorias según la probabilidad aleatoria.
Sin embargo, esto no significa que el protocolo Shadowsocks sea perfecto, sino que la "solución" de ShadowsocksR es torcida porque su enfoque es torcido. Mi idea personal es usar claves públicas y privadas para mejorar la seguridad, aunque no sea muy amigable para principiantes, pero la seguridad mejorará y las características se reducirán (no es necesario enviar IVs en la etapa de handshake), y el protocolo shadowsocks debe desarrollarse en la dirección de la seguridad CCA.
Actualizado el 5-sep-2015
Una vez que se encuentra el error en la cabecera (que no puede resolverse), se añadirán el IV y la IP incorrectos a la lista de IV y IP fallidos; si el IV ya existe en la lista de IV fallidos, o la IP ya existe en la lista de IP fallida, la IP que envió la solicitud de conexión se añadirá a la lista negra y la IP de la lista negra rechazará directamente la conexión. Para los últimos detalles sobre antidetección, consulte este número, y este artículo no actualizará las contramedidas para la antidetección.
Actualizado el 06-sep-2015
Este artículo solo quiere decirte que no te preocupes demasiado por la seguridad de Shadowsocks, el protocolo actual aún no ha tenido vulnerabilidades importantes y los servidores de los puertos principales también se están actualizando para solucionar posibles amenazas. También me he comunicado bien con el autor de ShadowsocksR, y pasará un tiempo antes de que llegue la lista blanca.
Actualizado el 24-sep-2015
La seguridad de Shadowsocks mencionada en este artículo se refiere más a la seguridad del servidor, y el protocolo actual conlleva el riesgo de exponer el servidor a una detección por fuerza bruta y luego ser bloqueado por cortafuegos (aunque el coste de detección es muy alto). No hay que preocuparse por la seguridad del contenido transmitido, todos ellos son algoritmos de cifrado de alta resistencia de grado industrial (excepto RC4 y TABLE), y es casi imposible descifrar el contenido transmitido.
Actualizado el 18-Nov-2015
Shadowsocks ha mejorado su seguridad frente al CCA añadiendo una única verificación, y los principales ports ya han completado su soporte. Es importante reiterar que el objetivo de Shadowsocks no es ser 100% libre de errores ni 100% a prueba de balas, sino asegurar que la conexión sea ligera y rápida, haciendo que los métodos de ataque convencionales sean demasiado caros de implementar.
|
Publicado en 10/11/2017 12:41:35
|
|
|
