Conjunto mínimo de funciones TLS para un dispositivo integrado

5

Estoy revisando la seguridad de un sistema integrado, específicamente cómo utiliza el protocolo TLS o DTLS para comunicarse de forma segura. El sistema implementa tan pocas características del protocolo como puede salirse con la suya. No se desvía del protocolo como tal, pero puede que no siempre cumpla estrictamente con todos los RFC aplicables. Mi objetivo es determinar si la elección de los parámetros de seguridad es segura.

Tendré que hacer esto de nuevo para otros sistemas similares, por lo tanto, mi pregunta es un tanto general en lugar de estar relacionada con un sistema específico.

Los objetivos de seguridad de usar (D) TLS son los habituales: un atacante podría interceptar el tráfico de la red (hombre activo en el medio). Queremos asegurarnos de que el cliente esté hablando con el servidor con el que cree que está hablando y que un tercero no pueda obtener o modificar los datos transmitidos (confidencialidad e integridad del tráfico en la conexión). La autenticación del cliente a veces también se desea.

Estos son sistemas integrados (IoT) con muy pocos recursos y, por lo general, interactúan en ecosistemas controlados. Al menos, controlamos a los pares legítimos, por lo que la compatibilidad con diversos clientes y servidores antiguos no es un problema, las preocupaciones son muy diferentes de usar TLS en la web. Un cliente de punto final típico solo habla uno o dos conjuntos de cifrado (autenticación de servidor basada en firmas "clásica", clave precompartida o uno de cada uno). Dependiendo del escenario, la PKI puede o no ser un sistema cerrado: algunos dispositivos viven en un mundo donde podemos confiar en que las CA solo entreguen certificados de cierta forma, mientras que otros pueden confiar en una CA "pública".

Estos son dispositivos con restricciones estrictas en el poder de cómputo disponible, el tamaño de RAM y el tamaño del código. Por lo tanto, generalmente están ejecutando bibliotecas TLS simplificadas con la menor cantidad de funciones posibles. Estoy hablando de un microcontrolador con 128–512kB de RAM, no de dispositivos de gama alta que ejecutan Linux.

¿Hay extensiones (D) TLS o X.509 que son importantes ? No me preocupa la elección de conjuntos de cifrado (nadie usa DES, RC4 o MD5 en mi mundo, o conjuntos de cifrado sin autenticación del servidor) o con tamaños de clave. Lo que me preocupa es, por ejemplo, una implementación que omite las comprobaciones de certificados (por ejemplo, restricción de uso de clave) que permitiría un mal uso de un certificado. O un cheque faltante durante el protocolo de enlace que permita algún tipo de ataque de degradación (un dispositivo de punto final generalmente solo habla una versión de protocolo, pero los servidores con los que habla pueden admitir varias versiones). O una extensión faltante que permite a un MitM activo convencer a las dos partes para que se ajusten a los parámetros de seguridad que no coinciden, o renegociar de manera insegura.

¿Qué debo buscar al revisar la configuración de TLS en un dispositivo integrado pequeño?

    
pregunta Gilles 10.08.2017 - 00:21
fuente

1 respuesta

6

No está claro si solo está mirando al cliente TLS, o si está revisando la implementación del cliente y del servidor. Asumiré ambos.

Recientemente completé una revisión de seguridad de WolfSSL (que viene con una recomendación por cierto), y varias cosas propietarias de TLS, por lo que es fresco en mi mente Aquí hay una lista completamente incompleta de cosas que busco:

X.509 cosas

  • Asegúrese de que el cliente esté comprobando que el CN del DN coincide con el dominio de la URL que solicitó.
  • Use su criterio de que la validación de certificados tiene sentido en el contexto de sistema cerrado. Es posible que deba hacer algunas listas de los posibles casos de uso, dado el entorno restringido, y asegurarse de que se cumplen. Además, evite que la ausencia de controles para los casos de uso que está dejando fuera no se pueda abusar.
  • ¿Se pueden revocar los certificados en este entorno? Si es así, ¿qué mecanismo? CRL? ¿OCSP? Podría haber extensiones adicionales que necesites soportar aquí.
    • ¿Cómo se comporta el cliente si no puede recuperar los datos de revocación? ¿Es razonable dado el caso de uso?
  • ¿Existen CA intermedias o todos los certificados emitidos directamente por la raíz anclada?
    • ¿Se está realizando la gestión de confianza / anclaje de certificados raíz de forma inteligente?
    • Si son intermedios, ¿esperan que obtengas datos de la extensión AIA ? (Si hay "CAs públicas web" involucradas, entonces esto es casi seguro que sí).
    • Si son intermedios, es probable que tenga que aplicar basicConstraints para la longitud de la ruta y cA para asegurarse de que los comodines no emitan certificados de un certificado de entidad final.

TLS Stuff

  • Máquina de estados: todas las vulnerabilidades relacionadas con SMACK-TLS (SKIP, FREAK) se deben a que el atacante abusa del motor TLS Estado de la máquina, así que asegúrese de hacer cumplir desde cada estado, cuáles son los próximos estados válidos posibles. Más control en el servidor, pero relevante para ambos.
  • Cipher Suites: verifique la configuración del cliente y verifique que el servidor combine el orden de preferencia del cliente con el suyo de alguna manera inteligente. (Por cierto, TLS 1.3 tiene algunos cambios aquí, así que si necesita admitirlo, tenga cuidado)
  • La matriz habitual de manejo de tamaño de búfer, nulidad de puntero y verificaciones de administración de memoria. Las cosas malas suelen aparecer cerca de las llamadas de grabación de socket.

Podría continuar, pero es posible que deba solicitar una compensación: P

    
respondido por el Mike Ounsworth 10.08.2017 - 01:57
fuente

Lea otras preguntas en las etiquetas