Debilidades HTTPS. Parte 2

Cualquier sistema tiene sus propias fortalezas y debilidades. La primera parte sobre las debilidades de HTTPS provocó una reacción ambigua de que "no se trata de debilidades, se pretendía que así fuera". La primera parte decía:

1. Sobre la imposibilidad de proporcionar total confidencialidad y privacidad a los usuarios (aún puede rastrear y prohibir los recursos que visita una persona)
2. El hecho de que los certificados se transmiten a través de un canal abierto y a menudo contienen más información que el recurso actual (por ejemplo, el certificado bing.com contiene información sobre 72 recursos adicionales, incluidos virgo, prueba, entorno beta)

Seguiré llamándolo "debilidades" del diseño. En este artículo, hablaremos sobre otra debilidad: la centralización .

HTTPS se basa en protocolos SSL y TLS (por simplicidad simplemente llamaremos SSL, aunque SSL y TLS funcionan en diferentes niveles de la pila OSI). Por lo tanto, hablando de debilidades, tendremos en cuenta la centralización del protocolo SSL.

Teoría

Comience con la teoría de los protocolos de cifrado. El problema con la criptografía moderna no es el cifrado en sí, sino qué hacer con las claves: cómo almacenarlas, transferirlas, crearlas y destruirlas de forma segura.

La base de SSL es el cifrado asimétrico , que está determinado por la presencia de dos claves: si una se cifra, solo la segunda puede descifrar, y viceversa.

La función principal del cifrado asimétrico es la autenticación , no el cifrado en absoluto: es una operación bastante costosa y que requiere muchos recursos para este algoritmo. El cifrado rápido y eficiente es prerrogativa de los algoritmos simétricos que usan la misma clave para el cifrado y el descifrado.

Una de las claves siempre permanece en un lado para confirmar su identificación, se llama privada . La clave pública está disponible para todos.

Imagina que hay un pueblo del futuro en el que viven Boris y Anya. En el futuro, las teclas de un tamaño diferente ya son más estrictas, y las habilidades del cerebro son desproporcionadas con respecto a las modernas, pero supongamos que el enfoque sigue siendo el mismo.

Boris y Anya quieren la privacidad de su correspondencia amorosa, por lo que lo principal para ellos es un intercambio seguro de información.

En el caso más simple, Boris le envía a Anna un mensaje: "hablemos". Anya genera dos pares de claves de cifrado asimétricas: Pr1 privado y P1 público. "Vamos", dice Anya, "Soy Anya, aquí está mi clave pública, aquí está el algoritmo de cifrado simétrico que conozco". Boris genera una clave simétrica S1, la cifra con la clave pública Ani P1 (S1). Ahora, incluso el propio Boris no podrá descifrar S1, porque solo Anya puede descifrar el mensaje con su clave privada. Al final, Boris y Ani tienen una clave de sesión simétrica para "garantizar" la transmisión confiable de cartas entre ellos y evitar que los padres lean su correspondencia.



Específicamente, no reduje fuertemente este mensaje, de hecho, describimos SSL Handshake con autenticación unidireccional [1]. Sobre una base de dos vías, Boris genera su propio par de claves y transfiere la clave pública a Anya.

Una conclusión importante que ya podemos hacer. De las tres funciones principales del protocolo SSL (autenticación, cifrado, integridad), la más importante es la autenticación.

Todo está bien hasta que aparece un cartero, ofendido por la vida, que es codicioso por leer las cartas de otras personas, y además es inteligente. Entre Boris y Anya, surge la pregunta de cómo garantizar ahora que el cartero no podrá leer sus mensajes. La respuesta es de ninguna manera. El cartero puede generar su propio par de claves, exponer a Boris su clave "supuestamente" de Ani, organizar dos canales cifrados y leer cartas con calma.



El dilema solo se puede resolver con la presencia de un tercero que pueda garantizar que la clave P1 le pertenece a Ana. Imagine que aparece un consejo de la aldea en la aldea, que mantiene un registro de claves públicas para los residentes. Anya puede tomar su pasaporte, su clave pública P1, ir allí y solicitar registrarse. Boris, cuando recibe P1 de Ani, puede ir al mismo consejo de la aldea y verificar el registro. Si la clave no coincide, puede comenzar a pecar en el cartero y culparlo por todo lo serio, aunque puede negarlo. Pero el problema aún se está resolviendo.



No era un camilpho, por supuesto, Boris se arrastraba al consejo del pueblo cada vez. Por lo tanto, la misma autenticación se puede hacer con el propio consejo de la aldea. El Village Council ahora se llama a sí mismo Autoridad de Certificación (CA) y tiene su propio par de claves, P10 y Pr10. Cuando Anya llega con un pasaporte y su clave pública, CA emite algo como una tarjeta que dice que se trata de Anya, posee la clave pública P1, alguna otra información, hasta el número de pasaporte, y agrega otro campo para ella. firmas: toma toda la información de la tarjeta, le quita el hash, la cifra con su clave privada y la llama firma digital. Sería posible prescindir de un hash, pero la firma era demasiado grande. Y la CA ahora llama a esta tarjeta un certificado.

Ahora, por intercambiar mensajes de amor con Anya, Anya le da no solo su nombre y clave pública, sino también su certificado. Boris solo tendrá que ir al consejo de la aldea una vez y pedirles su clave pública. Cualquier información que esta clave pueda descifrar será considerada a priori información cifrada por el consejo de la aldea. El cartero no sabe qué hacer en absoluto, está cubierto por un vacío existencial, solo le queda una cosa: tratar de recoger la clave privada del consejo del pueblo para que la vida vuelva al punto de partida.



Pero la vida no se detiene. Boris tiene otra novia en un pueblo vecino, luego otro. Tiene que agregar las claves de otros consejos de la aldea a los de su confianza, comienza a mantener su registro con las claves públicas de las autoridades de certificación. Luego gana una escala nacional y supranacional. Hay tantas organizaciones que firman certificados que comienzan a fusionarse en una jerarquía. Aparece la Autoridad de certificación raíz, que no firma los certificados de simples mortales, sino que firma los certificados de los centros intermedios (Autoridad de certificación intermedia) después de verificarlos. Ahora es suficiente que Boris almacene solo las claves públicas de los certificados raíz. Y de Ani recibe no solo uno de sus certificados, sino también certificados de centros intermedios, con el fin de verificarlos hasta el centro raíz.

Campo problema

El sistema se vuelve más complejo y centralizado , y desde ese momento el cartero nuevamente tiene una oportunidad.

Por un lado, Boris inicialmente tiene una pequeña lista de autoridades de certificación raíz (Windows prescribe unas 50 autoridades de certificación raíz durante la instalación). Por otro lado, es difícil para él seguir cada vez que toda la cadena de centros de certificación. Lo más probable es que ya no verifique que el certificado de Ani de su propia aldea, por alguna razón, indique el centro de certificación de otro país. Confía en su lista de centros de raíz en 99.9 por ciento. Un cartero puede tomar el camino más brutal, y de alguna manera (ingeniería social, piratería de penetración) registrar su autoridad de certificación de raíz falsa en el registro de Boris.



PS. Este método de agregar un certificado de centro raíz falso es utilizado activamente por los pentesters (como yo) y los atacantes. Para realizar pruebas de penetración y utilizar este enfoque, mi herramienta favorita es ZapProxy (de código abierto y gratuito), que generará un certificado de centro raíz (deberá instalarse manualmente) y luego sobre la marcha reemplazar este certificado por uno "similar". Esto le permite no solo ver el tráfico, sino también detenerlo, cambiarlo y enviarlo más. Por lo tanto, si la validación en su sistema no está duplicada en el servidor, entonces definitivamente tiene problemas.

PPS El segundo problema que se planteó en este caso se refiere a Ani y la indicación de un centro incomprensible en su certificado. Anya pagó el dinero y le gustaría que Boris la reconociera de todos modos. Este problema se resuelve mediante el anclaje SSL [3], cuando la aplicación solo se puede confiar en un determinado certificado y ciertas autoridades de certificación. Esto es especialmente útil para aplicaciones de alto riesgo. Con los navegadores, esto es más complicado, para aplicaciones móviles que funcionan con uno o dos servicios, más fácil. En aras de la experimentación, puse un certificado falso en mi Android, indiqué que el tráfico debería pasar por ZapProxy, que sobresale en la red de mi máquina, y analicé cuántas aplicaciones usan este mecanismo. Casi nadie, pude ver y jugar con la sustitución del tráfico con casi todas las aplicaciones populares.

Entonces, de vuelta a nuestro cartero. El gobierno no pudo sino apreciar su celo y le otorgó el estatus de agente secreto con poderes superiores. Aunque las claves privadas de las autoridades de certificación raíz se almacenan bajo siete cerraduras, discos autograbantes, protección multinivel, incluso la autoridad del cartero puede no ser suficiente para negociar con ellos para proporcionarle su clave privada para generar certificados válidos falsos sobre la marcha (aunque todo es posible). Encontró una manera más fácil. Acude a su propio consejo de la aldea, que se encuentra en la jerarquía de los centros de certificación en el nivel más bajo, y presiona o soborna al consejo de la aldea para firmar su certificado como certificado de un centro de certificación intermedio. Ahora puede escuchar el tráfico no solo de Boris, sino en principio de cualquier tema. Lo más probable es que la persona ni siquiera note nada, el navegador no emitirá ninguna advertencia.



Este es un problema conocido, y la humanidad también está tratando de combatirlo. Si encuentra dichos certificados falsos, centros intermedios y raíz comprometidos, estos certificados deben marcarse como revocados y comprometidos (Certificados revocados). Esto significa que, además de almacenar certificados raíz, Boris aún necesita sincronizarlos con la lista en línea de certificados revocados; este mecanismo se implementa a través de CRL (lista de revocación de certificados) y protocolos de Protocolo de estado de certificado en línea (OCSP) [4], que, por cierto, funcionan de acuerdo con canal desprotegido. Cuando comenzamos a trabajar activamente en el control del tráfico de SALIDA utilizando Dhound [5], notamos solicitudes periódicas en el puerto 80. Si prohíbe tales solicitudes en el nivel de firewall, algunas funciones dejan de funcionar, por ejemplo, el envío de correo. El problema con los certificados revocados es que ya hay una gran cantidad de ellos: en 2013, hubo alrededor de 3 millones de certificados revocados [6], 23,000 certificados Symantec revocados solo en 2018 [7]. Chrome desactivó la función predeterminada de verificación completa de certificados revocados hace unos años [8] para aumentar la velocidad de carga de la página. Resulta que si se descubre nuestro cartero, el proceso de prevención adicional de sus acciones será largo y no siempre será exitoso.

Conclusiones

El sistema SSL moderno está parcialmente cerrado y centralizado , lo que definitivamente es una de sus debilidades. Mientras sea así, siempre habrá una tentación para que las "personas poderosas de este mundo" obtengan sus beneficios, sin dar prioridad a la privacidad personal. Aún así, sus propios algoritmos de cifrado se crearán a nivel nacional, en un intento de aislar a otros países de sus propios ciudadanos y hacerlo nosotros mismos. El compromiso de los nodos clave puede derribar todo el sistema en su conjunto. La creciente entropía y complejidad del sistema conducirá cada vez más a su estado inestable y, en última instancia, a la muerte del sistema.

¿Qué salida? La transición de un sistema SSL cerrado y centralizado a uno más transparente y distribuido, que por su naturaleza no podrá dar ventajas a ninguna de las partes. Quizás esta sea una solución algo similar a la que implementa una cadena de bloques abierta.

PS. El protocolo SSL tiene matices más complejos que no se mencionaron en el artículo. Pero el nivel de información fue suficiente para revelar una de sus debilidades. ¿Hay alguna otra debilidad? En los siguientes artículos lo veremos.


Publicado por Denis Koloshko, CISSP