¿De dónde vienen mis claves para las solicitudes de SSL? [duplicar]

1

Por lo que entiendo, cuando envía información a un sitio web a través de SSL, cifra la información que envía con su clave pública.

Sin embargo, si quieres poder descifrar la información con la que responden, necesitarás una combinación de clave pública / privada. Nunca recuerdo haber recibido una solicitud de una clave RSA por mi navegador, o que se me haya requerido que genere una; ¿De dónde viene esta clave?

Si su navegador crea uno para usted, ¿se genera una vez y luego se almacena en su computadora para siempre, o se genera una nueva clave para cada sesión o sitio?

    
pregunta IQAndreas 28.05.2014 - 21:11
fuente

3 respuestas

2

Durante el protocolo de enlace TLS, el cliente usará la clave pública del servidor, que se pasó después del mensaje de ServerHello, para cifrar un secreto maestro previo. Es no la clave de sesión completa. En el mensaje de ClientHello y en el de ServerHello, las dos partes intercambian valores aleatorios. El servidor y el cliente ahora usan el secreto pre-maestro y los valores aleatorios para generar el mismo secreto maestro, que se puede usar como clave de sesión.

La clave pública del servidor se utiliza porque en la criptografía asimétrica la única persona que podrá descifrar el mensaje será el titular de la clave privada.

Consulte la página de wikipedia para obtener más detalles sobre el protocolo de enlace TLS .

    
respondido por el NRCocker 29.05.2014 - 06:22
fuente
0

Hay algunas maneras en que esto puede funcionar. Pero esta idea es que sus claves asimétricas se usan más para la validación de la identidad en lugar del cifrado. Aunque normalmente solo el servidor necesita verificar su identidad, a veces el servidor puede solicitar que la identidad del navegador vuelva a usar un certificado de cliente. Pruébelo aquí si lo desea .

†: Startcom es una autoridad de certificados famosa por proporcionar certificados gratuitos, pero también por tener un sitio web totalmente inutilizable que la gente paga los certificados de todos modos, solo para que no tengan que usar el sitio de startcom.

Una vez que las identidades están cuadradas, el cliente y el servidor se ocupan de establecer una clave de sesión para el cifrado real. Entonces, mientras que la identidad del certificado usa RSA, el cifrado de la sesión real generalmente usa AES o RC4, o Blowfish - cifrados simétricos donde se usa la misma clave para cifrar y descifrar. Estos son dramáticamente más rápidos.

Hay un par de maneras de generar una clave de sesión. La forma en que se realiza depende de las funciones que admiten el servidor y el navegador. El enfoque más ingenuo y antiguo es simplemente generar un número aleatorio y enviarlo encriptado usando la clave pública. El problema es que si la sesión es capturada por un atacante que luego adquiere la clave privada, podrá descifrar las sesiones pasadas.

Una solución mejor que está ganando terreno utiliza la negociación de claves Diffie-Helman para generar un secreto compartido que nunca se comunica. La negociación todavía utiliza las claves asimétricas para garantizar que la clave negociada no esté corrompida por un intermediario, pero el punto importante es que la clave nunca transita el cable, no puede derivarse de nada que se comunique. . Esto significa que cuando la conexión se cierra y tanto el cliente como el servidor olvidan la clave, los datos, si se capturan, nunca podrán ser descifrados nuevamente. Este tema recibe mucha atención aquí en este sitio bajo el nombre Perfect Forward Secrecy .

    
respondido por el tylerl 29.05.2014 - 09:21
fuente
-1

Su clave pública se usa para permitir que su navegador les envíe una clave de sesión. Una vez que se haya logrado esto, su navegador y su servidor conocen la clave de la sesión y la utilizan para cifrar en ambas direcciones.

La clave de la sesión está activada al vuelo por su navegador, una nueva para cada sesión, sin interacción.

    
respondido por el gowenfawr 28.05.2014 - 21:40
fuente

Lea otras preguntas en las etiquetas