Apretón de conexión Tov de Dovecot ChangeCipherSpec

1

Hoy agregué un dominio virtual a nuestro servidor de correo y luego verifiqué la seguridad de la conexión Dovecot TLS. La prueba se realizó desde un host remoto utilizando Thunderbird. Capturé la conexión con tcpdump y luego se la pasé a ssldump . También utilicé nmap para verificar los cifrados permitidos. Que todo se puede encontrar en un pastebin aquí .

No entiendo el servidor - > cliente ChangeCipherSpec (donde dice que usa TLS_RSA_WITH_RC4_128_MD51 10 0.5695 ) Es posible que esté confundido acerca de cómo está configurada la conexión TLS pero no tengo cifrados de tipo RC4 así que ¿cómo (o por qué) ) ¿Está sucediendo esto?

    
pregunta TrustNoOne 24.10.2015 - 00:28
fuente

2 respuestas

2

Me encontré con este problema recientemente. Ejecutaríamos ssldump y openssl s_client al mismo tiempo. openssl mostraría que el cifrado activo es AES256-SHA , pero ssldump todavía imprimiría TLS_RSA_WITH_RC4_128_MD5 en su salida.

Creo que encontré un error en ssldump . Mirando a través del código fuente encontré lo siguiente:

  • Los paquetes de intercambio de SSL se descodifican en la función decode_ContentType_handshake() en ssl/ssl_enum.c:20
  • Esta función llama a ssl_decode_switch(ssl,HandshakeType_decoder,t,dir,seg,data) , donde HandshakeType_decoder es una matriz de decoder structs \
  • ssl_decode_switch(ssl,dtable,value,dir,seg,data) ( ssl/ssl_print.c:204 ) itera a través de la matriz dtable hasta que encuentra la entrada decoder con type == value o type == -1 ("no encontrado")
  • Sin embargo, al observar la definición de HandshakeType_decoder en ssl/ssl_enum.c:212 , la matriz no termina con una estructura decoder con type == -1 ; hay un 0 al final
  • Además, inmediatamente después de la definición HandshakeType_decoder está la definición de cipher_suite_decoder ( ssl/ssl_enum.c:266 ) que es una matriz de la misma estructura decoder . Esta matriz contiene una lista de cifrados.
  • Esto significa que si el tipo de protocolo de enlace SSL no se encuentra en HandshakeType_decoder , ssl_decode_switch() continuará buscando en cipher_suite_decoder ya que (probablemente) estará en la memoria directamente después de los datos de HandshakeType_decoder
  • Y esto está sucediendo en mi caso. Por alguna razón, decode_ContentType_handshake() decodificó el paquete de intercambio para ser del tipo 4 que ssl_decode_switch() no pudo encontrar en el HandshakeType_decoder . Sin embargo, por coincidencia 4 es el valor type de la entrada cipher_suite_decoder con name == TLS_RSA_WITH_RC4_128_MD5

Se me acaba el tiempo para investigar este problema, así que no sé por qué ssldump está tratando de descodificar un paquete de intercambio de manos con un tipo no válido. Sin embargo, estoy convencido de que la matriz HandshakeType_decoder debe terminarse con un -1 para evitar el desbordamiento.

    
respondido por el piit79 14.12.2015 - 17:50
fuente
0

No tengo idea de lo que SSLDump está haciendo allí.

Pero el cliente solo señala el soporte para dos conjuntos de cifrado y luego el servidor elige el etiquetado

cipherSuite         Unknown value 0xc014

Y este valor hexadecimal decodifica a :

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

Así que no hay RC4 allí.

    
respondido por el StackzOfZtuff 24.10.2015 - 00:47
fuente

Lea otras preguntas en las etiquetas