Meta : la política de SE generalmente es contra múltiples preguntas en una publicación. Pero aquí, su segunda pregunta es un duplicado de Ataque de apretón de manos triple contra TLS que ya respondí, dejando una pregunta abierta.
La redacción en el glosario de rfc 5246 (y sus predecesores) puede ser un poco perezosa, porque se espera que prestes atención a todo el documento. El punto real es que una conexión (TCP) está asociada con una sesión TLS a la vez . La secuencia de tiempo es:
-
Para iniciar TLS / SSL, usted crea (o a veces ya tiene) una conexión TCP y o bien toma un apretón de manos completo para crear una nueva sesión o hace un apretón de manos abreviado para reanudar una sesión existente (si hay una disponible ). Después de esa negociación inicial , todos los datos transmitidos y recibidos se cifran (a menos que eNULL) y se autentiquen utilizando claves derivadas del master_secret para esa sesión (más los datos actuales), y ambos lados deben considerar que tienen los parámetros de seguridad (y otros) de esa sesión: master_secret, algoritmos, autenticación de servidor generalmente, autenticación de cliente si se usa y compresión de nivel TLS si se usó, lo que nunca fue muy popular y después de CRIME a menudo está completamente prohibido.
-
En cualquier momento posterior durante la misma conexión, si ambos puntos finales están de acuerdo, puede hacer otro protocolo de enlace llamado renegociación en la misma conexión. Esta renegociación nuevamente puede ser un saludo completo que crea una nueva sesión o un saludo breve que reanuda una sesión existente. En el caso de reanudación, puede reanudar la misma sesión que estaba en uso antes de la renegociación, o puede ser una sesión guardada diferente. Una vez que se realiza la renegociación, los datos subsiguientes utilizan las claves y los parámetros de la sesión seleccionada por la renegociación, por lo general, aunque no necesariamente diferentes de la sesión del saludo inicial.
-
Aún más tarde, podría hacer una segunda renegociación, nuevamente con las mismas características. Después de eso, los datos utilizan las claves y los parámetros de la sesión seleccionada por la segunda renegociación, probablemente diferente de la (s) sesión (es) de la primera renegociación y el protocolo inicial.
-
Et cetera, etcétera, etcétera.
Después de terminar una conexión, puede hacer otra conexión que nuevamente pueda crear una nueva sesión o reanudar una existente, si está disponible; a menudo, los puntos finales abandonan una sesión después de un límite de tiempo como 5 minutos o 1 hora, o si se quedan sin espacio, o tienen un error. Y otra vez, y otra vez. También puede hacer varias conexiones al mismo tiempo, cada una de las cuales puede crear una nueva sesión o reanudar una existente. Y después de terminarlos, puedes hacer más, ídem.
Hoy en día, la renegociación generalmente se realiza cuando una parte, generalmente el servidor, quiere cambiar los parámetros de seguridad , como hacer la autenticación del cliente que no se realizó en el protocolo inicial (o la renegociación previa). Para cambiar los parámetros de seguridad, la renegociación debe ser un saludo completo .
Pero el protocolo permite que la renegociación sea un saludo abreviado que reanude una sesión. La única razón válida y obvia para esto es que si ha cifrado suficientes datos en un conjunto de claves de trabajo que desea generar nuevas claves de trabajo, tradicionalmente llamadas rekey [ing] . Con el modo CBC es una buena práctica no exceder el "límite de cumpleaños" de los bloques sqrt (2 ^ blocksize) bajo una tecla, y para 3DES (y DES en los años anteriores a su caducidad) esto es 2 ^ 35 octetos o 512GiB. Con las redes modernas bajo carga sostenida, es posible que alcance este volumen y desee cambiar la clave en aproximadamente una hora o quizás menos, e incluso con una carga menor, esto podría ocurrir fácilmente en días o semanas.