¿Cómo es posible que las personas que observan que se está estableciendo una conexión HTTPS no sabrían cómo descifrarla?

Es la magia de criptografía de clave pública . Las matemáticas están involucradas.

El esquema de intercambio de claves asimétricas que es más fácil de entender es el cifrado asimétrico con RSA. Aquí hay una descripción simplificada:

Sea n un entero grande (digamos 300 dígitos); n se elige de modo que sea un producto de dos números primos de tamaños similares (llamémoslos p y q ). Luego, calcularemos las cosas "módulo n ": esto significa que cada vez que sumamos o multiplicamos dos enteros, dividimos el resultado por n y mantenemos el resto (que es entre 0 y n-1 , necesariamente).

Dado x , computar x³ módulo n es fácil: multiplicas x con x y luego nuevamente con x , luego se divide por n y se mantiene el resto. Todo el mundo puede hacer eso. Por otro lado, dado x³ módulo n , recuperar x parece demasiado difícil (los métodos más conocidos son demasiado caro para la tecnología existente) - a menos que sepa p y q , en cuyo caso se vuelve más fácil. Pero también es difícil calcular p y q de n (es el problema conocido como factorización de Ineger ).

Entonces, esto es lo que hacen el servidor y el cliente:

• El servidor tiene un n y conoce los correspondientes p y q (los generó). El servidor envía n al cliente.
• El cliente elige un x aleatorio y calcula x³ módulo n .
• El cliente envía x³ módulo n al servidor.
• El servidor utiliza su conocimiento de p y q para recuperar x .

En ese momento, tanto el cliente como el servidor conocen x . Pero un intruso vio solo n y x³ módulo n ; no puede volver a calcular p , q y / o x a partir de esa información. Así que x es un secreto compartido entre el cliente y el servidor. Después de eso, este es un cifrado simétrico bastante sencillo, utilizando x como clave.

El certificado es un barco para la clave pública del servidor ( n ). Se utiliza para frustrar a los atacantes activos que querrían hacerse pasar por el servidor: dicho atacante intercepta la comunicación y envía su valor n en lugar de n del servidor. El certificado está firmado por una autoridad de certificación, para que el cliente sepa que un n dado es realmente el n genuino del servidor con el que quiere hablar. Las firmas digitales también utilizan criptografía asimétrica, aunque de una manera distinta (por ejemplo, también hay una variante de RSA para firmas digitales).

Aquí hay una versión realmente simplificada:

1. Cuando un cliente y un servidor negocian HTTPS, el servidor envía su Clave pública al cliente.
2. El cliente encripta la clave de encriptación de sesión que quiere usar usando el la clave pública del servidor y envía los datos cifrados al servidor.
3. El servidor descifra la clave de cifrado de la sesión con su clave privada y comienza a usarla.
4. La sesión está protegida ahora, porque solo el cliente y el servidor pueden conocer la clave de cifrado de la sesión. Nunca se transmitió de forma clara, ni de ninguna manera un atacante podría descifrar, por lo que solo ellos lo saben.

Voilà , cualquier persona puede ver la clave pública, pero eso no les permite descifrar el paquete "hey-let-encrypt-using-this-from-now-on" que está cifrado con Esa clave pública. Solo el servidor puede descifrar eso, porque solo el servidor tiene esa clave privada. Los atacantes podrían intentar falsificar la respuesta que contiene una clave cifrada, pero si el servidor configura la sesión con eso, el verdadero cliente no la hablará porque no es la clave que el verdadero cliente estableció.

Es toda la magia del cifrado de clave asimétrica. Cosas fascinantes.

P.S. "realmente simplificado" significa "detalles destrozados para que sea más fácil de entender". Wikipedia "Seguridad de la capa de transporte" ofrece una respuesta más correcta en los detalles técnicos, pero mi objetivo era "fácil de asimilar".

Las otras respuestas son buenas, pero aquí hay una analogía física que puede ser más fácil de entender:

Imagina una caja de seguridad, del tipo con una solapa de metal en la que colocas un candado para asegurar. Imagina que el bucle donde pones el candado es lo suficientemente grande como para caber dos candados. Para intercambiar de forma segura enviar algo a otra persona sin compartir las claves de un candado, deberías

1. ponga la "Cosa" en la caja y ciérrela con su candado.
2. enviar la casilla bloqueada a la otra parte.
3. también ponen su candado en el bucle (para que haya dos bloqueos en él), y te devuelven la casilla con doble bloqueo
4. Quitaste tu candado y les devuelves la caja ahora bloqueada individualmente
5. quitan su propio candado y abren la caja.

Con el cifrado, los bloqueos y las claves son matemáticas, pero el concepto general es vagamente así.

Muchas de las respuestas ya proporcionadas pasan por alto la capacidad de interceptación del ISP o NSA. Eche un vistazo a Room 641A en el centro de datos de AT & T. Se estima que hay entre 10 y 20 instalaciones de este tipo que se han instalado en todo Estados Unidos. También eche un vistazo a la One Wilshire en el que las conexiones de 260 ISP convergen en un solo edificio. Esa ubicación es una ubicación privilegiada para una instalación de intercepción.

El hecho es que un ISP (o el equipo instalado por la NSA en el ISP) puede interceptar y MITM atacar una conexión SSL y pueden hacerlo con bastante facilidad en realidad.

• Su navegador web o sistema operativo tiene más de 500 de confianza. Certificados instalados en el mismo. Esto significa que usted confía implícitamente en cualquier sitio web cuyo certificado haya sido firmado por este certificado.
• La NSA a través de una orden judicial secreta de FISA puede obligar a a cualquier Autoridad de Certificación que opere en los Estados Unidos a otorgarles su certificado raíz. La orden judicial incluye una cláusula especial de no divulgación que obliga a la AC a mantener la boca cerrada bajo pena de prisión si se pronuncian al respecto. Sin embargo, es posible que ni siquiera necesiten hacer esto, solo tienen que convencer a los proveedores del navegador para que acepten uno certificado de propiedad de la NSA como confiable en el navegador.
• A medida que su tráfico pasa a través del ISP, intercambian la verdadera clave pública del sitio web con la propia clave pública de la NSA firmada por la autoridad de certificación comprometida que realiza el ataque MITM.
• Su navegador web acepta este certificado falso como de confianza y usted comunica la clave de cifrado simétrica para el intercambio de nuevo con el NSA / ISP que guarda una copia del mismo y también pasa la misma clave al sitio web.
• Su sesión con el sitio web se descifra en tiempo real con la clave simétrica comprometida.
• Los datos descifrados se envían a través de la línea de fibra óptica a la sede y centro de datos de la NSA en el sótano de Fort Meade. Esto escanea los datos en busca de cientos o miles de palabras clave que pueden indicar varios tipos de amenazas. Todas las palabras clave están marcadas en rojo para que un analista vea y priorice acciones adicionales, si las hay. Los datos finales se envían a una de las instalaciones de almacenamiento de datos de la NSA en los Estados Unidos. La nueva instalación de almacenamiento es el centro de datos de Utah que probablemente ya esté en línea, ya que estaba programado para estar en línea a fines del mes pasado .

Aquí hay un diagrama de nsawatch.org:

En palabras sencillas: hay dos encriptaciones diferentes que tienen lugar:

• Primero está el cifrado de clave pública / privada . El cliente utiliza la clave pública del servidor (que se incluye en el certificado) para cifrar cierta información que solo el servidor puede descifrar con su clave privada.

• Basándose en esta información, se deriva una clave de sesión , que solo conocen el servidor y el cliente. Esta clave de sesión se utiliza para cifrar esos datos.

Este es un resumen muy aproximado.

Hay mucho más en marcha para prevenir varios tipos de ataques:

• Por ejemplo, el cliente intenta validar el certificado del servidor para asegurarse de que no está hablando con un hombre en el medio.
• Hay diferentes algoritmos y longitudes de clave para las claves de sesión que deben negociarse
• Los números aleatorios que solo se usan una vez se usan para evitar ataques de repetición .
• El protocolo de intercambio de claves Diffie-Hellman se puede usar para generar una clave de sesión que no pueda ser reconstruido por alguien que grabó la transmisión de datos cifrados y obtiene acceso a la clave privada del servidor más tarde ( Secreto de avance perfecto ).
• ...

Pienso en las seis respuestas que ya están arriba, gowenfawr lo explica mejor. Lea eso primero, ya que esto es simplemente un apéndice.

En Diffie-Hellman

Varias respuestas mencionan los intercambios de Diffie-Helman. Estos se implementan en una minoría de intercambios. La clave del servidor firma un intercambio DH para evitar un ataque MITM . Debido a que la clave no está encriptada a una clave pública, no se puede recuperar utilizando una clave privada capturada contra el tráfico capturado de un intercambio de claves. Esta es la idea de Perfect Foward Secrecy . OpenSSL proporciona intercambios de claves "regulares" y DH según la configuración.

En MITM / Signature chain

Tanto los intercambios de clave pública como de DH impiden que alguien observe la conexión y obtenga la clave. Esto se basa en una gran cantidad de problemas matemáticos que puede investigar / ver en la respuesta de Thomas para comprender. El problema con cualquiera de ellos es el ataque MITM. Para la criptografía de clave pública, esto se soluciona ya sea conociendo la clave pública de antemano (incluso si se observa el intercambio) o por medio de una cadena de certificados. Ejemplos: Confío en Alice, y Alice firmó la llave de Bob certificando que realmente es suya. También conocido como Google está certificado por ... err, Google. Parece que están en Firefox como su propia CA. Por lo tanto, random_bank's_ssl está firmado por Verisign y mi navegador confía en Verisign para emitir solo certificados legítimos.

Existen problemas con este modelo cuando te topas con cosas como una autoridad de certificación comprometida . En ese caso, un ataque MITM es posible.

SSL se basa en la criptografía de clave pública. Un servidor que participa en SSL tiene un keypair , que tiene componentes públicos y privados.

Imagina que tienes una caja de seguridad especial con dos teclas: una tecla puede bloquear la caja, y otra puede desbloquear la caja. Si su amigo quiere enviarle un mensaje secreto, solo necesita la tecla bloqueando , y puede mantener la clave de desbloqueo privada .

De hecho, puede dar su clave de bloqueo a todos. Decide dejar de lado las copias de sus cajas de seguridad especiales y las teclas de bloqueo en su porche delantero para que cualquiera pueda tener una copia. Pronto, todos en tu ciudad pueden enviarte mensajes secretos por correo. Has hecho que tu bloqueo sea pública .

Si su amiga Alice quiere enviarle un mensaje secreto, pone su mensaje dentro de una caja de seguridad y lo bloquea con una copia de su llave de bloqueo pública. El administrador de correo de tu ciudad sospecha de ti y de Alice, pero, aunque él también tiene acceso a tu clave pública, no puede abrir la caja de seguridad. Solo tú, el único propietario de la clave de desbloqueo privado, puedes abrir la casilla que Alicia bloqueó.

Por lo tanto, su ISP (aquí, el administrador de correo) tiene acceso a su clave pública , pero eso no les ayuda a descifrar los mensajes cifrados con su clave pública. Su clave pública solo se encripta, y solo su clave privada se desencripta. Por lo tanto, su clave privada nunca deja su posesión, por lo que nadie tiene acceso a ella, excepto usted, y por lo tanto, nadie puede escuchar sus mensajes.

Hay un poco más de protección que le brinda SSL (por ejemplo, supongamos que el administrador de correo tira la caja de Alice y le envía un mensaje nuevo que simula ser Alice), pero esto debería aclarar por qué su ISP no puede simplemente descifrar sus mensajes.

Mire a Diffie Hellman: enlace

Por motivos de rendimiento, la conexión se cifra con una clave simétrica. Pero la clave simétrica se genera durante el establecimiento de la conexión y nunca se intercambia de forma clara, sino mediante el uso de criptografía asimétrica.

La criptografía asimétrica es una técnica donde se necesitan dos claves: una pública y una privada. Lo que está encriptado con la clave pública tiene que ser descifrado con la clave privada y al revés. Por lo tanto, ambas computadoras pueden intercambiar datos en función de otras claves públicas. Pero solo el propietario de la clave privada correspondiente puede descifrarla. La clave privada nunca se intercambia, por lo que, incluso si ha olfateado todo, no puede descifrar nada. Esas técnicas son expansivas, por lo que se utilizan para intercambiar la clave por la clave de criptografía simétrica y no los datos en sí mismos.

La seguridad de la capa de transporte (que es lo que se llama ahora Secure Sockets Layer) implica métodos para intercambiar de forma segura las claves criptográficas a través de un canal de comunicaciones inseguras (como Internet).

Sí, esto significa que el ISP puede ver la información del intercambio de claves a medida que pasa de un lado a otro, y aún así no tiene suficiente información para leer el flujo de mensajes una vez que se ha establecido una conexión segura. / p>

Un concepto muy extraño, y es un trabajo bastante nuevo. El ejemplo más común de esto se llama Diffie-Hellman Key Exchange , y solo se inventó en el 1970's.

El artículo de Wikipedia tiene todos los detalles matemáticos deliciosos, pero encuentro que la imagen de abajo (de Wikimedia) ilustra perfectamente el concepto. Míralo, piénsalo, incluso pruébalo tú mismo, y descubrirás que no hay forma de que un oponente obtenga la clave privada de la información visible públicamente.

Si me pongo mi sombrero negro (no este sombrero negro ... en realidad ese sombrero también funciona):

Un ISP puede simplemente realizar un ataque de intermediario en cualquiera de sus descargas HTTP de aplicaciones o sus parches y así actualizar la cadena de confianza del navegador directamente o actualizarla indirectamente con un troyano autodestructivo.

Microsoft solo requiere que los controladores estén firmados por código; Las firmas digitales para aplicaciones y los datos ejecutables equivalentes a la aplicación no se aplican de forma predeterminada *. La mayoría de los sistemas operativos de los consumidores no son mejores si simplemente porque la firma obligatoria del código de la aplicación (y la verificación de la identidad) costaría lo suficiente para reducir drásticamente el tamaño de su software ecology .

_{* Me refiero a no vincularme a las respuestas de Microsoft a menos que tenga que hacerlo. Sus monos entrenados obviamente usan máquinas de escribir rotas.}

La clave allí es el cifrado de clave pública o asimétrico. Significa que tienes dos piezas de clave, pública y privada, y una función matemática que es fácil de calcular en una dirección pero muy, muy difícil de calcular en la otra.

Entonces, cuando los servidores envían su clave pública, podemos usar la clave pública para cifrar fácilmente nuestras cosas, pero solo con la otra clave del par, la clave privada, en este caso, puede descifrarla fácilmente.

La EcoParty Conference anunció una herramienta llamada BEAST que, según se informa, descifra el tráfico SSL3 / TLS1.0 y disminuye, presumiblemente al observarlo.

Aquí hay un enlace a la noticia informe

Estoy seguro de que en los próximos días escucharemos más sobre esto, las soluciones y limitaciones.

Esta sección a continuación se actualizará a medida que se descubra más información

Este hack asume que el atacante puede ver de alguna manera el tráfico de su red; A través de spyware o mediante una captura de red. Las máquinas mal administradas y los usuarios de Wifi son los sospechosos más habituales ... aunque no se limitan a ese caso de uso.

Hay informes de que podemos mitigar este riesgo al cambiar la lista de cifrado SSL * / TLS 1.0 a RC4, y no admitir combinaciones anteriores. Otra mitigación es aumentar la longitud del token de autenticación, lo que ralentizaría el ataque. La modificación de la configuración de la cookie de autenticación de membresía de Siteminder y ASP.net puede ayudar aquí.

Solo para que sepa que esta vulnerabilidad está expuesta por las mismas personas que anunciaron el año pasado el "Ataque de relleno en ASP.NET". Ese viejo problema pone en riesgo a todos los servidores web de IIS solo por estar encendido, lo que parece ser más serio que este ataque.

  

Comparta los enlaces que encuentre que mencionen o confirmen a estos vulnerables   Escenarios, o mitigaciones aquí. Tal como está ahora, algo de esto es   especulación y no examinados por expertos en criptología.

No, no mantendrían la clave, ya que la conexión que está haciendo es entre usted y el sitio de destino (por ejemplo, Amazon), por lo que el ISP no tendrá conocimiento de la clave.

La pregunta más general sobre cómo funciona SSL / TLS se responde aquí .

Aquí hay muchas respuestas geniales, especialmente las que hablan sobre los problemas que van más allá de la ejecución de DH o ECDH (por ejemplo, corrupción del cliente / instalación de certificados / secuestro de certificados, etc.)

Si está ignorando la máquina local y simplemente está preocupado por MITM, necesita DH / ECDH Y SSL. La fijación de SSL se está volviendo más común, pero todavía no está en todas partes hoy en día. Esto significa que su ISP puede simplemente pretender ser su servidor siempre que tenga un SSL válido en su cadena de confianza. La fijación de SSL garantiza que el certificado SSL utilizado por el servidor al que está conectado ES el certificado del servidor al que intenta acceder.

Nuevamente, si estás buscando estar a salvo del gobierno o los hackers, esto no es suficiente. Si busca evitar que su ISP revise sus datos, probablemente sea suficiente.