Vulnerabilidade en TLS que permite a determinación de claves para conexións baseadas en cifrados DH

Revelado información sobre o novo vulnerabilidades (CVE-2020-1968) no protocolo TLS, con nome en clave
Mapache e permite, en raras circunstancias, determinar unha clave primaria preliminar (pre-mestra), que se pode usar para descifrar conexións TLS, incluído HTTPS, ao interceptar o tráfico de tránsito (MITM). Nótase que o ataque é moi difícil de implementar na práctica e é máis de natureza teórica. Para levar a cabo un ataque requírese unha configuración específica do servidor TLS e a capacidade de medir con moita precisión o tempo de procesamento do servidor.

O problema está presente directamente na especificación TLS e só afecta ás conexións que utilizan cifrados baseados no protocolo de intercambio de claves DH (Diffie-Hellman, TLS_DH_*"). Cos cifrados ECDH o problema non se produce e seguen sendo seguros. Só os protocolos TLS ata a versión 1.2 son vulnerables; TLS 1.3 non se ve afectado polo problema. A vulnerabilidade prodúcese nas implementacións de TLS que reutilizan a clave secreta DH en diferentes conexións TLS (este comportamento prodúcese en aproximadamente o 4.4 % dos servidores Alexa Top 1M).

En OpenSSL 1.0.2e e versións anteriores, a chave principal DH reutilízase en todas as conexións do servidor a menos que se estableza explícitamente a opción SSL_OP_SINGLE_DH_USE. Desde OpenSSL 1.0.2f, a clave principal DH só se reutiliza cando se usan cifrados DH estáticos ("DH-*", por exemplo, "DH-RSA-AES256-SHA"). A vulnerabilidade non aparece en OpenSSL 1.1.1, xa que esta rama non usa unha chave primaria DH e non usa cifrados DH estáticos.

Cando se utiliza o método de intercambio de claves DH, ambos os dous lados da conexión xeran claves privadas aleatorias (en diante chave "a" e chave "b"), en función das cales se calculan e envían as claves públicas (ga mod p e gb mod p). Despois de que cada parte recibe as claves públicas, calcúlase unha chave primaria común (mod gab p), que se usa para xerar claves de sesión. O ataque Raccoon permítelle determinar a clave primaria mediante a análise de canles laterales, baseándose no feito de que as especificacións TLS ata a versión 1.2 requiren que todos os bytes nulos principais da clave primaria se descarten antes de realizar cálculos que a impliquen.

A inclusión da clave primaria truncada pásase á función de xeración de claves de sesión, que se basea en funcións hash con diferentes atrasos ao procesar datos diferentes. Medir con precisión o tempo das operacións clave realizadas polo servidor permítelle ao atacante determinar pistas (oráculo) que permiten xulgar se a chave primaria comeza de cero ou non. Por exemplo, un atacante podería interceptar a chave pública (ga) enviada polo cliente, retransmitila ao servidor e determinar
se a chave primaria resultante comeza de cero.

Por si só, definir un byte da clave non dá nada, pero ao interceptar o valor "ga" transmitido polo cliente durante a negociación da conexión, o atacante pode xerar un conxunto doutros valores asociados con "ga" e envialos a o servidor en sesións de negociación de conexión separadas. Ao xerar e enviar valores "gri*ga", un atacante pode, mediante a análise dos cambios nos atrasos na resposta do servidor, determinar os valores que levan a recibir claves primarias a partir de cero. Tras determinar tales valores, o atacante pode crear un conxunto de ecuacións para solucións problemas de números ocultos e calcula a clave primaria orixinal.

Vulnerabilidades de OpenSSL asignado baixo nivel de perigo, e a corrección reduciuse a mover os cifrados problemáticos "TLS_DH_*" na versión 1.0.2w á categoría de cifrados cun nivel de protección insuficiente ("cifrados-ssl débiles"), que está desactivado por defecto . Os desenvolvedores de Mozilla fixeron o mesmo, apagado na biblioteca NSS utilizada en Firefox, as suites de cifrado DH e DHE. A partir de Firefox 78, os cifrados problemáticos están desactivados. A compatibilidade de Chrome para DH deixou de funcionar en 2016. As bibliotecas BearSSL, BoringSSL, Botan, Mbed TLS e s2n non se ven afectadas polo problema porque non admiten cifrados DH nin variantes estáticas de cifrados DH.

Os problemas adicionais anótanse por separado (CVE-2020-5929) na pila TLS de dispositivos F5 BIG-IP, facendo que o ataque sexa máis realista. En particular, identificáronse desviacións no comportamento dos dispositivos ante a presenza dun byte cero ao comezo da clave primaria, que se poden utilizar en lugar de medir a latencia exacta dos cálculos.

Fonte: opennet.ru