Cómo arreglar el algoritmo SSL para mayor seguridad [duplicar]

Navega tus respuestas
4

SSL utiliza un cifrado asimétrico como este:

  1. El servidor envía una copia de su clave pública asimétrica.
  2. El navegador crea una clave de sesión simétrica y la cifra con la clave pública asimétrica del servidor.
  3. El servidor descifra la clave pública asimétrica con su clave privada asimétrica para obtener la clave de sesión simétrica.
  4. El servidor y el navegador ahora cifran y descifran todos los datos transmitidos con la clave de sesión simétrica.

Pero, ¿qué sucede si alguien escucha esta comunicación en el "paso 1" y hace esto?

  1. Escuche la comunicación entre el servidor y el cliente en el paso 1.
  2. Cuando el servidor envía una copia de su clave pública asimétrica, el pirata informático la cambia a su propia clave pública (que también tiene su clave privada) y la envía al cliente.
  3. El cliente crea una clave de sesión y la cifra con la clave pública del pirata informático.
  4. Hacker escucha la línea, obtiene la clave de sesión y la desencripta con su clave privada.

Entonces él consigue la clave de sesión aquí. y luego ..

  1. Hacker cifra la clave de la sesión (que se descifra) con la última clave pública (el servidor enviado)
  2. Entonces el hacker tiene la clave de sesión ahora ...

Utilicé este algoritmo en mi proyecto para la comunicación entre el servidor y el cliente. No hay ninguna certificación entre ellos. ¿Es correcto agregar algunos caracteres en la clave pública y el cliente los comprueba y los hace válidos?

¿Cómo podemos arreglarlo? alguna idea?

    
pregunta Elahe 02.10.2014 - 07:28
fuente

3 respuestas

8

TLS no está dañado, solo entiendes TLS;)

La TLS completa se explica en esta respuesta pero para responder a su pregunta concreta:

  • El servidor no envía la clave pública simplemente al cliente. El servidor envía un certificado (cadena) al cliente.
  • El cliente verifica los certificados del servidor con uno de los certificados de confianza en su almacén.

Por lo tanto, para utilizar un Ataque MitM (Man in the Middle) como lo describió, el atacante debe reemplazar el certificado del servidor (que también es posible pero mucho más difícil).

Un certificado es la clave pública firmada por una CA (Autoridad de Certificación). Por lo tanto, el cliente puede verificar el certificado de los servidores al verificar la firma en ese certificado.

Todos los certificados tienen una cadena de certificados firmados hasta un certificado autofirmado. Este certificado autofirmado se llama certificado raíz y ya está incluido en su navegador.

Puede crear su propia CA emitiendo un certificado raíz y usarlo para firmar sus propios certificados. Solo tendrá que importar el certificado raíz creado en el almacén de certificados de los navegadores. Esto solo es factible para pequeñas bases de usuarios o para compañías con actualizaciones para los navegadores.

    
respondido por el Uwe Plonus 02.10.2014 - 07:45
fuente
2

Lo que te falta es la autenticación, es decir, confirmar que la clave pública que recibiste realmente fue enviada por el servidor.

En https, por ejemplo, se usa el sistema de Autoridad de Certificación. Ciertas organizaciones son elegidas como aquellas en las que podemos confiar. Estas organizaciones producen una clave pública que luego se incluye en los navegadores. Por lo tanto, cuando descarga Firefox, por ejemplo, se incluye un conjunto de Certificados CA de confianza. Luego, cuando se conecta a un sitio a través de https, el navegador comprueba si el certificado otorgado por el servidor está firmado por uno de los Certificados CA de confianza.

Las CA tienen el trabajo de recibir solicitudes para firmar certificados y verificar que los verdaderos propietarios de ese sitio las envían.

En un proyecto personal, esto significa que debe incluir la clave pública del servidor en algún lugar, para verificar el certificado que recibe.

    
respondido por el Shelvacu 02.10.2014 - 07:52
fuente
0

Este ataque no funciona porque el cliente valida el certificado del servidor. Si un hombre en el medio (el pirata informático, en su escenario) reemplaza la clave pública del servidor con la suya, entonces el certificado no se validará, el cliente sabe que algo está mal y cancela la transacción. El cliente no utilizará la clave pública incorrecta para cifrar la clave de sesión, por lo tanto, esto no es una amenaza.

    
respondido por el Xander 02.10.2014 - 07:39
fuente

Lea otras preguntas en las etiquetas

¿Es correcto considerar las auditorías como de carácter exclusivamente "detective"? Vigenere Cipher - ayuda con el descifrado (a mano)