¿La conexión TLS con el servidor no confiable - la reacción del cliente para cancelar la conexión está estandarizada?

5

Jugué con una herramienta de proxy hombre-en-el-medio y conecté diferentes teléfonos inteligentes. Como el proxy utiliza un certificado autofirmado, las aplicaciones de teléfonos inteligentes probadas no aceptaron el certificado de servidor presentado.

La parte interesante (desde mi perspectiva) fue que las diferentes plataformas de teléfonos inteligentes utilizaron mensajes y estrategias totalmente diferentes para asegurarse de que la conexión TLS no se pueda establecer.

Algunos acaban de enviar un mensaje de ALERTA con la descripción bad_certificate (42) o certificate_unknown (46). Otros teléfonos simplemente continuaron con el apretón de manos, pero luego el intercambio de teclas falló de manera determinista.

Me pareció especialmente interesante el último caso, ya que no está claro cómo el cliente obliga a que falle la fase de negociación y si un servidor / proxy adaptado aún puede "guardar" la fase de negociación y establecer la conexión ...

¿Las acciones que un cliente debe realizar en algún lugar están escritas en un RFC para interrumpir la conexión en caso de que se detecte un certificado no confiable?

Si no, ¿alguien sabe qué mecanismo se usa normalmente para sabotear voluntariamente la fase de reconocimiento de TLS?

    
pregunta Robert 31.03.2015 - 09:31
fuente

1 respuesta

-1

La validación del certificado X509 está cubierta en RFC 5280.

Consulte la sección 6 ( enlace )

  

No se requieren implementaciones conformes de esta especificación   para implementar este algoritmo, pero DEBE proporcionar funcionalidad
  equivalente al comportamiento externo resultante de este procedimiento.

    
respondido por el Daisetsu 24.04.2016 - 03:53
fuente

Lea otras preguntas en las etiquetas