¿Es SSL más seguro que la codificación?

-8

Estoy escribiendo un par de programas cliente / servidor. He establecido mi propio protocolo y me estoy comunicando con TCP. Actualmente, cuando el cliente envía un mensaje al servidor, agrega 42 a cada byte (bucle, 127 + 1 = -128) e invierte la matriz de bytes para enviar. El lado del servidor resta 42 de cada byte e invierte la matriz de bytes nuevamente. Esto ofrece, para mí, una seguridad fácil de implementar.

Comparado con SSL de nivel SSH / HTTPS con protocolo de enlace, claves privadas y públicas de 128 bits, etc. ¿Cuál es más seguro? Es decir, si hago HTTPS en algún cibercafé de Internet, el propietario puede hacer algunos trucos para hacer conexiones "seguras" entre sus computadoras de préstamo y GMail, por ejemplo, para hacer que mi tráfico sea al estilo de Wireshark, mientras que, si es un cibercafé el propietario mira una captura de paquete de codificación (+42, inversa), probablemente no tendrían que descifrarla.

    
pregunta Scruffy 18.12.2014 - 11:42
fuente

5 respuestas

10

Lo que has definido no es seguridad.

SSL puede darle seguridad.

Entonces ... tu pregunta es fácil de responder:

Sí: SSL es hasta un 100% más seguro que la codificación. Si bien los elementos de su segundo párrafo tienen alguna base de hecho (existen ataques MITM maliciosos, etc.), pueden protegerse, mientras que su solución no tiene protección y cualquiera puede decodificarla fácilmente.

Tu suposición "estarían en una pérdida" es completamente falsa, me temo. Cualquier cosa que parezca una codificación es increíblemente fácil de encontrar y romper.

    
respondido por el Rory Alsop 18.12.2014 - 11:50
fuente
2

Se encuentra en la situación de que su cliente y su servidor ya comparten un secreto (su algoritmo agrega 42 a cada byte). Si bien esta es una implementación muy insegura, sería posible cifrar el contenido con una clave segura y su mensaje sería seguro.

El problema es que, tan pronto como alguien obtiene el secreto (sin embargo lo hace), puede leer su mensaje. Un texto codificado no es un problema para cualquier atacante, el cifrado es.

SSL en el otro lado es capaz de cifrar su mensaje, incluso si su cliente no tiene instalado nada (no hay secreto compartido disponible). Lo hace con los certificados, que pueden verificarse con los certificados raíz instalados de su navegador.

    
respondido por el martinstoeckli 18.12.2014 - 11:53
fuente
2

No estoy seguro de a quién está destinado a detener esto: el esquema de codificación descrito es apenas lo suficientemente fuerte como para derrotar a una "clase despistada", y es incapaz de detener o incluso de frenar significativamente a un "pequeño hermano curioso" atacante de clase. Alguien con las capacidades técnicas para realizar un exitoso ataque SSL "man-in-the-middle" como se describe en la pregunta debería poder verlo de inmediato.

    
respondido por el Mark 18.12.2014 - 12:08
fuente
1

Lo que has implementado es algo muy similar al "cifrado César" que ya se ha utilizado en el siglo VIII. Es fácilmente rompible con lápiz y papel. Consulte este artículo para obtener más información: enlace

Básicamente, no, su algoritmo no se compara con las implementaciones actuales de TLS. También vea este hilo por qué no debe rodar su propia criptografía: Por qué no deberíamos rodar el nuestro?

    
respondido por el Julian Hansmann 18.12.2014 - 17:08
fuente
-2

Ves muchas herramientas para romper protocolos específicos, pero ¿hay herramientas genéricas para codificaciones hechas a mano? En cuyo caso, este podría ser un método adecuado para el público en general.

    
respondido por el mincewind 18.12.2014 - 14:38
fuente

Lea otras preguntas en las etiquetas