alerta cifrada de protocolo de enlace TLS en el certificado del cliente

Question

alerta cifrada de protocolo de enlace TLS en el certificado del cliente

#1 de Tom Leek (4 votos)

2

Estoy intentando depurar un protocolo de enlace TLS entre un cliente y un servidor

Client sends Hello

Server sends Hello, Certificate, Certificate request, Server hello done.

client sends Encrypted alert - content tpe Alert(21)
client sends Client key exchange
client sends Change cipher spec

server sends Change cipher spec

client sends Finished
server sends Finished

client sends Application data

Después de esto, la conexión se interrumpe y en los registros del servidor parece que el cliente no envió un certificado (donde ocurre la alerta cifrada).

Descomponiéndolo, no puedo pegar los datos de Wirehark ya que estoy trabajando en una red cerrada.

¡Cualquier ayuda sería muy apreciada!

tls

pregunta David Limkys 05.08.2015 - 00:15

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls

¿Por qué los archivos temporales con sufijo PID son una vulnerabilidad Averigüe la identidad de la persona que lo llamó

score 4 · Answer 1

En TLS no puede haber un registro encriptado antes de que se complete el primer saludo; el primer registro cifrado enviado por el cliente o el servidor es un mensaje Finished . Si el mensaje está encriptado, entonces está destinado a ser descifrado en el otro lado; dado que las claves de cifrado simétricas se derivan del "secreto maestro" que, en sí mismo, proviene del mecanismo de intercambio de claves acordado, el extremo receptor (aquí, el servidor) no puede descifrar un registro lógicamente antes de completar el intercambio de llaves Por lo tanto, desde el cliente, no tendría sentido enviar una alerta cifrada antes del ClientKeyExchange (es decir, no solo hacer el cifrado antes de que los mensajes Finished infrinjan el estándar, sino que hacerlo antes del ClientKeyExchange también romper las leyes de la naturaleza).

Esto conduce a dos teorías:

Quizás el mensaje de alerta "encriptado" no esté encriptado. Un registro de alerta consiste en una secuencia de "alertas", cada una de ellas consiste en un par de bytes: el primer byte especifica el nivel de alerta (1 = advertencia, 2 = fatal), el segundo byte documenta la naturaleza de la alerta. Consulte el estándar para obtener más información.
Tal vez su rastreo de red combine el tráfico de varias conexiones TLS, y la "alerta cifrada" pertenezca a otro protocolo de enlace anterior (podría ser la alerta close_notify que marca el final de la conexión anterior).

En cualquier caso, si el servidor solicita un certificado de cliente (con un mensaje CertificateRequest ), y el cliente no tiene un certificado adecuado, entonces el comportamiento del cliente debe ser enviar un mensaje Certificate vacío ( antes su ClientKeyExchange ). Esto es lo que se supone que sucede con TLS-1.0 y versiones posteriores; en SSL-3.0, un cliente sin certificado adecuado omitiría el mensaje Certificate , y en su lugar enviaría un mensaje de alerta de nivel "advertencia" y escribiría "no_certificate" (valor numérico: 41). Si su seguimiento no muestra un mensaje Certificate del cliente, esto significaría que está usando SSL-3.0, lo cual, a partir de agosto de 2015, es extraño (los clientes y servidores ya deben saber TLS-1.0). Esto debe verificarse observando el contenido de los mensajes ClientHello y ServerHello . Un protocolo de enlace SSL-3.0 explicaría el mensaje de "alerta", pero ciertamente no estaría cifrado.

(SSL-3.0 y TLS-1.0 son muy similares, pero tienen algunas diferencias, una de ellas es el comportamiento del cliente cuando se solicita un certificado pero no se puede proporcionar uno).

Si realmente está usando SSL-3.0, entonces, primero, no debería, porque SSL-3.0 tiene una debilidad irremediable (llamada POODLE ). Sin embargo, incluso si actualiza a una versión mejor (una de las versiones TLS), probablemente tenga el mismo problema, que es que el cliente no envía un certificado.

Las causas comunes de esto son:

El cliente no tiene, de hecho, tal certificado. Tal vez el certificado está ahí pero ha caducado (o el cliente puede creerlo así, debido a un reloj interno mal configurado). Tal vez el cliente tenga el certificado pero carezca de la clave secreta (por ejemplo, en un mundo Windows, los derechos de acceso en la clave privada están desactivados).
El cliente tiene un certificado pero no es apropiado para el servidor. El CertificateRequest del servidor incluye la lista de nombres de CA raíz que el servidor utilizará para validar el certificado del cliente. El cliente enviará su certificado solo si esos certificados pueden validarse en relación con uno de estos CA. Si la lista de CA raíz está mal configurada en el servidor, el cliente simplemente puede abstenerse de enviar un certificado.
Del mismo modo, el cliente puede creer que su certificado no es apropiado para el servidor. Este es un caso raro, pero ocurre en algunos escenarios que involucran migraciones a una nueva CA raíz: dada una PKI con una CA raíz y una CA intermedia, se puede crear una nueva CA raíz (nuevo nombre, nueva clave) que emita un nuevo certificado para la CA intermedia (pero la CA intermedia mantiene su nombre y clave). Este tipo de migración permite validar los certificados existentes tanto en la raíz anterior como en la nueva, lo que es bueno para una transición sin problemas. Sin embargo, algunos programas cliente (sí, Windows, te estoy mirando) operan bajo la creencia de que un certificado dado se relaciona con una única CA raíz, siempre. Por lo tanto, en tal escenario, si el servidor desea usar la nueva raíz pero el cliente cree que su certificado proviene de la raíz anterior, el cliente no lo enviará, aunque hubiera funcionado bien en el lado del servidor.