Diferencias

Muestra las diferencias entre dos versiones de la página.

--- master_cs:secom:tm1_v2 [2026/05/22 23:03] – thejuanvisu
+++ master_cs:secom:tm1_v2 [2026/05/22 23:43] (actual) – thejuanvisu
@@ Línea 21: / Línea 21: @@
 ==== Protocolo TSL (1.2 y 1.3) ====
-Transporta y, opcionalmente, cifra cada mensaje TLS entre 2 aplicaciones.
+Transporta y, opcionalmente, cifra cada mensaje TLS entre 2 aplicaciones. Un registro TLS tiene la siguiente estructura:
 {{drawio>master_cs:secom:diagtls2.png}}
+  * Trasnsporte de mensaje: Se transportan buffers opacos enviados por subcapas del protocolo superarioes. Puede fragmentar mensajes mayores de 16384 bytes y combinar varios mensajes pequeños en un solo regisotr.
+  * Cifrado y validación de integridad: Los primeros mensajes se transmiten en claro, una vez finaliza el handshake, se cifra y valida de acuerdo a los parámetros negociados
+  * Compresión: Ya no se usa, sujetoa a ataques de compresión de canal lateral.
+  * Extensibilidad: El protocolo de registro solo trata con el transporte y el cifrado, las demás tareas son llevadas a cabo por un subprotocolo. Hay 4 subprotocolos principales:
+    * Handshake
+    * Change cipher spec
+    * Datos de aplicación
+    * Alert.
+=== Protocolo de Handshake ===
+Responsable de la negociación de los parámetros de conexión y realizar la autenticación. Intercambia entre 6 y 10 mensajes, dependiendo de las características. Suelen haber 3 flujos comunes:
+  * Handshake completo con autenticación de servidor
+  * Handshake abreviado continuando una sesión anterior
+  * Handshake completo con autenticación mutua.
+<code c especificación_del_mensaje>
+struct {
+  HandshakeType msg_type; //1 Byte
+  uint24 length;
+  HandshakeMessage message; //Depende del tipo de mensaje
+} Handshake;
+</code>
+El funcionamiento de un handshake con autenticación de servidor sería el siguiente:
+  - Intercambio de capacidades y negociación de parámetros
+  - Autenticación, se validan los certificados presentados
+  - Se establece una clave secreta maestra para proteger la sesión
+  - Se verifica la integridad de los mensajes de handshake
+Siguen los siguientes pasos:
+<WRAP column half>
+{{drawio>master_cs:secom:diagflujofullhadshakeserver.png}}
+</WRAP>
+<WRAP column half>
+  - [Cliente] solicita sesión TLS y se envían las capabilities
+    - Client Hello: Compueto por los siguientes campos
+      - Random: Previene ataques de replay y asegura la integridad
+      - Session ID: Vacío para la primera conexión
+      - Cipher Suites: Ordenadas por preferencia.
+  - [Server] selecciona los parámetros de conexión
+    - Server Hello: La versión puede ser inferior a la del cliente. Contiene solo una opción por campo.
+  - [Server] envía la cadena de certificados si es necesaria autenticación
+    - Certificate Message: Sirve un certificado X.509
+      - Primero viene el certificado principal y luego los intermedios. No se debe enviar el certificado raid
+      - El certificadod epende de la cipher suite
+      - Un server puede ser configurado con múltiples certificados
+  - [Server] envía información adicional para generar la clave maestra
+    - Key Exchange: Los contenidos dependen de la cipher suite.
+      - El ClientKeyExchange es obligatorio y el SeverKeyExchange es opcional.
+  - [Server] Indica la finalización de la negociación
+  - [Cliente] Envía información adicional para generar la clave maestra
+  - [Cliente] Cambia el cifrado e informa al servidor
+  - [Cliente] Envía un MAC (Message Authentication Code) para todos los mensajes intercambiados
+  - [Server] Cambia el cifrado e informa al cliente
+  - [Server] Envía un MAC para todos los mensajes intercambiados
+</WRAP>

Knoppia

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página