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?