¿Qué pasa con SSL que lo hace resistente a los ataques de intermediarios? [duplicar]

0

Así es como entiendo lo que realmente hacen los certificados SSL, en términos de niños de 4 años. Tiene que haber tres partes involucradas. Dos partes son solo mi cliente y el servidor con el que me estoy comunicando, mientras que el tercero es el emisor del certificado. Mi cliente le preguntará al emisor del certificado si el servidor con el que contacté es realmente el servidor que dice que es, el emisor del certificado propondrá un desafío al servidor y me responderá si salió bien.

Aquí está la cosa sin embargo. Cuando busqué a otras personas que preguntaban sobre los ataques del hombre en el medio, las respuestas decían que solo sería posible si el tercero (el emisor del certificado) fuera robado su clave privada, que el hombre del medio podría usar para falsificar su identidad al completar el desafío, o algo así ...

Sin embargo, sin robar la clave privada y sin robar nada, si el hombre del medio puede imponerse como el servidor del sitio al que estoy tratando de llegar (simplemente redirigiendo su nombre de dominio a su propia IP), entonces, ¿qué le impide hacer lo mismo con el servidor del emisor del certificado? Así, por ejemplo, podría redireccionar la dirección IP de Facebook a su propio servidor para intentar que ingrese las credenciales de mi cuenta, y cuando mi navegador intente preguntarle a Digicert (el titular del certificado para facebook.com) si me estoy comunicando con el auténtico En el servidor de Facebook, el intermediario también podría redireccionar la dirección IP de Digicert a sí mismo nuevamente y confirmarme erróneamente que Facebook realmente es Facebook.

    
pregunta Digital Ninja 15.03.2017 - 02:47
fuente

3 respuestas

1
  

Mi cliente le preguntará al emisor del certificado si el servidor con el que contacté es realmente el servidor que dice que es, el emisor del certificado propondrá un desafío al servidor y me responderá si salió bien.

No, no tiene que ponerse en contacto con el emisor por separado para verificar un certificado. De lo contrario, solo estarías cambiando el problema de la confianza. En su lugar, tiene que haber un ancla de confianza local.

Es por eso que su navegador (y finalmente su sistema operativo) ya viene con certificados preinstalados para las autoridades de certificación que se consideraron confiables. De la Política de certificados de Mozilla CA :

  

Al distribuir versiones de código fuente y binario de Firefox, Thunderbird y otros productos de software relacionados con Mozilla, Mozilla puede incluir con dicho software un conjunto predeterminado de certificados X.509v3 para varias Autoridades de Certificación (CA). Los certificados incluidos de forma predeterminada tienen sus "bits de confianza" establecidos para diversos fines, de modo que el software en cuestión puede utilizar los certificados de CA para verificar los certificados de los servidores SSL y los usuarios de correo electrónico S / MIME sin tener que pedirles más permisos o información.

Cuando su navegador establece una conexión SSL con facebook.com , el servidor presenta el certificado junto con una firma para demostrar que este certificado fue emitido por DigiCert para el dominio facebook.com . El navegador comprueba esto verificando que el certificado esté firmado de forma transitoria por el certificado raíz de DigiCert que vino con el navegador. Si el certificado raíz correspondiente no se puede encontrar o no es de confianza, no hay una cadena de certificados válida y la verificación falla.

Como mecanismo de seguridad adicional, Facebook utiliza Fijación de clave pública HTTP (HPKP) característica que detiene a un atacante de tipo intermediario, incluso si lograban comprometer una CA y generar certificados aparentemente válidos:

  

La función une un conjunto de claves públicas de hashes a un nombre de dominio, de modo que cuando se conecta a un sitio utilizando TLS, el navegador asegura que existe una intersección entre las claves públicas en la cadena de confianza calculada y el conjunto de huellas digitales asociadas con eso. dominio. Esta comprobación se realiza durante la fase de verificación del certificado de la conexión, antes de que el navegador envíe o procese cualquier información.

(Source)

Si bien cualquier sitio web puede anunciar sus propios pines a través de un encabezado Public-Key-Pins que se activará después de la primera visita de su navegador ( modelo TOFU ), Facebook y algunos otros sitios de alto perfil tienen sus pines integrados en Firefox y Chrome, lo que significa que estos navegadores confían en los certificados de Facebook directamente y no necesitan consultar con la raíz de DigiCert en absoluto.

También tenga en cuenta que existen mecanismos independientes donde los clientes realmente se contactan directamente con una CA. Por ejemplo, su navegador puede usar OCSP para verificar el estado de revocación de un certificado en particular.

También vea:

respondido por el Arminius 15.03.2017 - 04:46
fuente
0

Hay algo de información errónea incrustada en su pregunta, por lo que le recomiendo que lea detenidamente un artículo general sobre cómo funciona SSL / TLS. La respuesta corta es que la CA proporciona un secreto (el certificado) que está alojado en Facebook u otro servidor de destino. Sin ese certificado, firmado por la CA, la CA sabe que el atacante no es quien dice ser. Un ataque MITM que realmente tenga el certificado (y la información apropiada para usarlo) es indistinguible del objetivo. Por lo tanto, es importante que los propietarios / operadores de servidores protejan sus certificados.

PKI también proporciona un mecanismo para la revocación de certificados en el caso de que un certificado se vea comprometido, para que un certificado pueda ser invalidado y emitido nuevamente.

    
respondido por el Jesse Keilson 15.03.2017 - 03:18
fuente
0
  

Mi cliente le preguntará al emisor del certificado si el servidor con el que contacté es realmente el servidor que dice que es, el emisor del certificado propondrá un desafío al servidor y me responderá si salió bien.

No es así como funciona TLS / SSL. En TLS / SSL, el cliente no necesita preguntarle al emisor del certificado si el servidor es o no lo que realmente es. En su lugar, lo que está sucediendo es que el cliente envía un número aleatorio al servidor (un desafío) y le pide al servidor que firme criptográficamente ese número utilizando el certificado emitido por el emisor del certificado (Cliente Hola). El servidor luego firma el número aleatorio con su clave privada y devuelve la firma y el certificado al cliente (Servidor Hola). El cliente puede verificar que 1) la firma es válida para el desafío que envía y el certificado devuelto por el servidor, 2) el certificado es para el servidor correcto y sigue siendo válido, 3) el certificado está firmado criptográficamente por un emisor de confianza el cliente.

El número aleatorio firmado en ClientHello también se usa para derivar la clave de cifrado, usando un proceso llamado Intercambio de claves Diffie-Hellman . El resultado final es que tanto el servidor como el cliente obtienen una clave de sesión que q MITM no puede conocer, incluso cuando todos los intercambios hasta ese punto se realizan sobre MITMed y en texto plano.

La única vez que el emisor del certificado necesita ponerse en contacto con el servidor para validar el servidor es antes de que se emita el certificado, durante la validación del dominio cuando el emisor del certificado mismo verifica la identidad del servidor. Posteriormente, el emisor del certificado no necesita ponerse en contacto con el servidor nuevamente.

    
respondido por el Lie Ryan 15.03.2017 - 03:52
fuente

Lea otras preguntas en las etiquetas