OpenSSL Secure Renegotiation

5

¿Alguien ha intentado hacer una renegociación segura en OpenSSL y verificarlo con WireShark? Parece que no puedo hacer una renegociación segura en lo que respecta a RFC 5746 .

Intenté emitir el comando de conexión " R " como se sugiere aquí . Sin embargo, cuando miro el paquete capturado por wireshark, muestra que el mensaje está encriptado. En RFC 5746, dice que la renegociación debe estar en el mensaje ClientHello en lugar de encriptado.

También probé la opción " reconnect " en el cliente y tanto sess_out como sess_in. Después del apretón de manos, inspecciono todo el paquete capturado, simplemente no parece tener ningún dato de verificación en el campo Información de renegociación.

  • Entiendo que, de forma predeterminada, OpenSSL deshabilitará la renegociación heredada.

  • Esto sucede cuando se usa el conjunto de cifrado ECDHE-RSA-AES128-SHA pero no AES256-SHA

pregunta Ryu 30.12.2013 - 09:13
fuente

1 respuesta

8

El problema de "renegociación segura" es sobre lo que sucede cuando se hace un segundo saludo de mano dentro del contexto del primero . Eso es lo que haces con R en el comando openssl s_client ; pero implica que el segundo protocolo de enlace está cifrado, por lo que se espera y es normal que vea solo los mensajes de "saludo cifrado". Si desea ver el contenido del mensaje, use la opción de línea de comando -msg en OpenSSL; imprimirá un volcado hexadecimal del mensaje de intercambio de manos antes del cifrado . Por ejemplo:

$ openssl s_client -connect nameofsomeSSLserver:443 -msg
(...)
    Start Time: 1388406589
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
R
RENEGOTIATING
>>> TLS 1.1 Handshake [length 00eb], ClientHello
    01 00 00 e7 03 02 52 c1 67 3f 99 89 75 92 fa e6
    97 f3 c3 8a f5 2c 30 ba bd 0c 20 e9 1e 3c eb 4b
    3c 2f 85 ec cd 24 00 00 64 c0 14 c0 0a c0 22 c0
    21 00 39 00 38 00 88 00 87 c0 0f c0 05 00 35 00
    84 c0 12 c0 08 c0 1c c0 1b 00 16 00 13 c0 0d c0
    03 00 0a c0 13 c0 09 c0 1f c0 1e 00 33 00 32 00
    9a 00 99 00 45 00 44 c0 0e c0 04 00 2f 00 96 00
    41 c0 11 c0 07 c0 0c c0 02 00 05 00 04 00 15 00
    12 00 09 00 14 00 11 00 08 00 06 00 03 01 00 00
    5a ff 01 00 0d 0c 63 74 19 13 be ac 02 22 04 ed
    81 61 00 0b 00 04 03 00 01 02 00 0a 00 34 00 32
    00 0e 00 0d 00 19 00 0b 00 0c 00 18 00 09 00 0a
    00 16 00 17 00 08 00 06 00 07 00 14 00 15 00 04
    00 05 00 12 00 13 00 01 00 02 00 03 00 0f 00 10
    00 11 00 23 00 00 00 0f 00 01 01

En ese ClientHello , podemos ver las diferentes partes:

  • 01 00 00 e7 : a ClientHello de tamaño 231 bytes (0xE7).
  • 03 02 : versión del protocolo (TLS 1.1 en este caso).
  • 52 c1 ... cd 24 : el "cliente aleatorio" (32 bytes).
  • 00 : ID de sesión vacía (el cliente desea negociar una nueva sesión, no un protocolo de enlace abreviado).
  • 00 64 : longitud de la lista de conjuntos de cifrado (100 bytes, para 50 conjuntos de cifrado).
  • c0 14 ... 00 03 : los conjuntos de cifrado admitidos por el cliente (100 bytes).
  • 01 00 : un método de compresión compatible: la compresión nula (es decir, sin compresión).
  • 00 5a : longitud de la lista de extensiones (90 bytes).
  • ff 01 : tipo de extensión renegotiation_info , como se especifica en RFC 5746 .
  • 00 0d : el contenido de la extensión tiene una longitud de 13 bytes.
  • 0c : los datos renegotiated_connection tienen una longitud de 12 bytes.
  • 63 74 19 13 be ac 02 22 04 ed 81 61 : es una copia del contenido de 12 bytes del mensaje Finished del cliente durante el protocolo de enlace anterior.
  • luego vienen algunas otras extensiones.

Por lo tanto, este mensaje indica una "renegociación segura" según RFC 5746.

La opción de línea de comando -reconnect hace algo completamente diferente: se conecta, hace el protocolo de enlace, luego cierra la conexión y luego se vuelve a conectar con una nueva conexión, e intenta reanudar la sesión . La reanudación de la sesión es todo lo contrario a la renegociación segura : la reanudación de la sesión se trata de reutilizar el secreto maestro de una conexión anterior sobre una nueva, mientras que la renegociación segura se trata de hacer un nuevo maestro secreto manteniendo la misma conexión.

    
respondido por el Thomas Pornin 30.12.2013 - 13:58
fuente

Lea otras preguntas en las etiquetas