¿El sistema de cifrado de chat evita el rastreo del protocolo y luego la reproducción de la clave + descifrado?

0

Estoy trabajando en un sistema de chat y quiero agregarle algún tipo de seguridad (no solo HTTPS con SSL desde que lo leí puede ser detectado y descifrado con algunas herramientas). Ahora, mi conocimiento en criptografía es escaso, pero estoy dispuesto a aprender, siempre que lo que pido sea posible:

Teniendo en cuenta que hay un intruso (cliente C) que pasa por alto HTTPS al principio de todas las conexiones (por ejemplo, MITM, proxy, firewall, etc.), y que tengo mis propios conceptos, este es el procedimiento que tengo en mente:

Enviar :

  1. El cliente A se conecta a una interfaz web que contiene dentro del código de respuesta (javascript) una clave pública (por ejemplo, a123456789b) generada aleatoriamente en intervalos (la renegociación de la clave puede ocurrir más adelante).
  2. La contraseña del usuario está hash localmente y ese hash se envía para verificar que sea la misma en el servidor. Si es así, continúe (por ejemplo, DEADBEEF).
  3. Así que ahora tengo una clave pública (a123456789b) y una clave privada (DEADBEEF). Puedo usar ambos para cifrar un mensaje y enviarlo.

Recibir :

  1. El cliente B se conecta al servidor y obtiene la misma clave pública (a123456789b) y obtiene otro hash (ya que su contraseña es diferente, por ejemplo, FACEFINADA).
  2. El cliente B recibe un mensaje del cliente A y ...

Aquí está mi show-stopper: lo que B reciba, C podrá verlo Y reproducirlo, ya que tiene la clave pública y el hash (y al volver a reproducir me refiero a reproducir los datos en lugar de enviar las solicitudes a mi servidor nuevamente). invalidarlos, obviamente)).

Como lo veo, no importa si el mensaje se puede descifrar con DEADBEEF (si se envía junto con el mensaje cifrado) o con FACEFEED, ya que C está observando todo el protocolo y puede descifrar lo que B recibe (pero no lo que envía)

Estoy perplejo aquí. Sé que C puede piratear el código del cliente inyectando su propia clave pública o funciones, pero solo recibirá y enviará basura al otro lado. Si es así, estoy contento con eso porque entonces puedo mostrar una advertencia y todo eso. Lo que me preocupa es cómo puedo evitar que C reproduzca los paquetes y luego descifre los mensajes, ya que para descifrarlos necesito la clave pública y FACEFINADA o DEADBEEF, y esos 3 se envían por el mismo canal.

Cualquier ayuda es bienvenida! Por favor, recuerde que no sé mucho de criptografía, he estado vagando a través de muchos enlaces de wikipedia, (DH key exchange, PFS, MTProto, etc.) pero solo entendí alrededor del 50% de todos y esto es lo que encontré. con pero ahora necesito ayuda.

    
pregunta DARKGuy 28.09.2014 - 00:55
fuente

1 respuesta

1
  

no solo HTTPS con SSL desde que lo leí puede ser detectado y   descifrado con unas pocas herramientas

Esto no es cierto.

En general (y en el caso de SSL / TLS), los ataques de reproducción se evitan usando un "número que solo se usa una vez" (es decir, nonce ). Si la otra parte recibe el nonce dos veces, es obviamente un ataque de repetición.

Con respecto a la publicación del blog has vinculado:

  

Para hacerlo, genera dinámicamente un certificado y lo firma con un   la clave privada de un certificado de CA en la que el cliente debe confiar.

Para que esto sea exitoso, un atacante debe tener acceso físico a la máquina e instalar un nuevo certificado de CA de confianza (o, de lo contrario, comprometer la clave privada de una que ya es de confianza, lo que probablemente sea un problema de seguridad global). Ese ataque no funcionaría si fueras simplemente un hombre en el medio (sin tener también un certificado de CA para firmar certificados falsificados).

    
respondido por el thexacre 28.09.2014 - 02:35
fuente