Fail Decrypt Botan construyó TLS usando Wireshark

Question

Fail Decrypt Botan construyó TLS usando Wireshark

#1 de dave_thompson_085 (1 votos)

1

Cuando uso Wireshark para descifrar un ejemplo de Openssl (al importar la clave RSA privada del servidor) enlace funciona perfectamente.

Y quiero hacer lo mismo con las herramientas de CLI de Botan (otra biblioteca de cifrado) mediante el certificado y la clave autofirmados (RSA_2048bits). Configuré el servidor usando los siguientes comandos

botan tls_server selfsignedCer.cer serverPrivate.pem --port=9999

cliente

botan tls_client localhost --port=9999

resultando

Alert:unrecognized name
Certificate validation status: Cannot establish trust
Handshake complete ,TLS v1.2 using RSA_WITH_AES_256_CBC_SHA256
Session ID : (long hex there)

Desde que se completó el protocolo de enlace, busco en wireshark, pero no hay una sección de 'Datos descifrados SSL' como se muestra a continuación (por lo que significa que wireshark no puede descifrar eso):

AcontinuaciónsemuestramiejemplodeéxitousandolamuestradeOpenssl,puedoverlasección'descifradodedatosSSL'

¿wiresharksolopuededescifrarTLSimplementadoporopenssl?(perocreoquelaimplementaciónnotieneefectoenTLS)¿Ohicealgomal?ArchivodecapturadeOringinalyclaveacontinuación. enlace los primeros 30 son los de botan, luego detengo la comunicación y empiezo otra muestra de openssl alrededor de los 40, todos con la misma clave

tls decryption

pregunta TTZ 15.08.2017 - 14:06

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls decryption

¿Son sensibles las medidas de seguridad de Amazon AWS? PTH y contraseñas con sal

score 1 · Answer 1

La primera conexión en su captura, los marcos 1-28, probablemente botan, usa la extensión Encrypt-then-MAC de RFC 7366 ; Es decir, el cliente lo ofrece / lo solicita y el servidor acepta. Basándose en el registro de depuración de SSL Wireshark aparentemente no implementa esto, al menos a través de 2.0 (aún no estoy en la versión 2.2), ya que aparentemente intenta descifrar todo el mensaje, incluido el MAC y luego unpad que es completamente incorrecto para EtM. Definitivamente no descodifica la extensión en los mensajes de saludo (dejándola como "Unknown 22"), lo cual esperaría si se implementara la funcionalidad relacionada.

La segunda conexión, los marcos 29-48, es aparentemente OpenSSL, que no implementa EtM y, por lo tanto, no lo ofrece en ClientHello; su servidor (botan) aparentemente está dispuesto a negociar una sesión sin él, aunque use un conjunto de cifrado AEAD (TLS_RSA_WITH_AES_256_GCM_SHA384 0x9C) que resuelve la debilidad que EtM pretendía solucionar.

Curiosamente, su cliente botan también ofrece la extensión de ticket RFC 5077 , pero el servidor no envió un ticket para ese apretón de manos, mientras que lo hizo por la misma oferta de OpenSSL. No veo ninguna razón obvia para la diferencia, lo que para ser claro está permitido a elección del servidor.

PS: puede ver si puede hacer que su cliente prefiera, o incluso requiera, conjuntos de cifrado AEAD, en lugar de ofrecer solo AES (256) CBC como lo hizo en esta captura. Si el protocolo de enlace selecciona una suite AEAD, EtM no tiene ningún efecto en el cifrado, por lo que Wireshark debería manejarlo.