¿Funciona este TLS correctamente?
Usando facebook como por ejemplo aquí - fb.com
- La CA tiene su propio pub y clave pvt.
- CA le da a fb un pub y una clave pvt
- Todos los navegadores ya tienen la clave de publicación de CA: el certificado raíz.
- Cuando te conectas a fb.com. Fb me envía su clave de publicación cifrada con la clave pvt de CA
- Mi navegador descifra esto con la clave de publicación de CA que ya tiene.
- Ahora tengo la clave de pub de fb y mi navegador genera la clave de sesión que se envía a fb cifrada con la clave de pub de fb
- Y luego, fb.com y mi navegador tienen sesión para comenzar a usar un cifrado simétrico como AES.
No entiendo la parte acerca de que fb puede cifrar su propia clave de pub con la clave pvt de CA.
¿Cómo puede tener acceso a la clave pvt de CA? ¿O ya está firmado por la AC la primera vez que se entrega a fb?
Ahora obteniendo la clave de sesión
Aquí encontrará una de las 2 respuestas mejor calificadas de ¿Cómo es posible que las personas que observan el establecimiento de una conexión HTTPS no puedan descifrarlo?
Es la magia de la 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 Encriptación asimétrica con RSA. Aquí hay una descripción simplificada:
Sea n un entero grande (digamos 300 dígitos); n es elegido de tal manera que es una producto de dos números primos de tamaños similares (llamémoslos p y q). Luego computaremos las cosas "módulo n": esto significa que siempre que sumamos o multiplicamos dos enteros, dividimos el resultado por n y mantenemos el resto (que está entre 0 y n-1, necesariamente).
Dado x, computar x3 módulo n es fácil: multiplicas x con x y luego otra vez con x, y luego divides por n y mantienes el resto. Todo el mundo puede hacer eso. Por otro lado, dado x3 modulo n, recuperar x parece demasiado difícil (los métodos más conocidos están lejos demasiado caro para la tecnología existente) - a menos que sepa p y q, en en cuyo caso se vuelve fácil de nuevo. Pero computar p y q a partir de n parece difícil, también (es el problema conocido como factorización de enteros).
Entonces, esto es lo que hacen el servidor y el cliente:
- El servidor tiene una n y conoce la p y la q correspondientes (las generó). El servidor envía n al cliente.
- El cliente elige una x aleatoria y calcula x3 módulo n.
- El cliente envía x3 módulo n al servidor.
- El servidor utiliza su conocimiento de pyq para recuperar x.
En ese punto, tanto el cliente como el servidor saben x. Pero una sierra para espiar solo n y x3 modulo n; no puede volver a calcular p, q y / o x de eso información. Entonces x es un secreto compartido entre el cliente y el servidor. Después de eso, esto es bastante sencillo simétrico cifrado, utilizando x como clave.
Digamos x^3 mod n = Z
Las dudas aquí son que si el Z puede intercambiarse, ¿cuándo se utiliza el mecanismo en la siguiente cita, de cifrar la clave de sesión con la clave pública del servidor?
También, ¿por qué el atacante no puede descifrar x de la fórmula x^3 mod n = Z , ya que el atacante tiene n cuando el servidor lo envió al cliente y también tiene Z cuando el cliente lo devolvió?
Y la segunda respuesta desde allí:
Aquí hay una versión realmente simplificada:
- Cuando un cliente y un servidor negocian HTTPS, el servidor envía su Clave pública al cliente.
- El cliente encripta la clave de encriptación de sesión que quiere usar con la clave pública del servidor y envía los datos encriptados al servidor.
- El servidor descifra la clave de cifrado de la sesión con su clave privada y comienza a usarla.
- 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à, cualquiera puede ver la clave pública, pero eso no les permite descifrar el paquete "hey-vamos-cifrar-usar-esto-desde-ahora-en" que está Encriptado con esa clave pública. Sólo 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 se establece hasta la sesión con eso, el verdadero cliente no lo hablará porque no es la clave que establece el verdadero cliente.