A metade dos sitios , e o seu número vai aumentando constantemente. O protocolo reduce o risco de interceptación do tráfico, pero non elimina os intentos de ataque como tal. Falaremos dalgúns deles - POODLE, BEAST, DROWN e outros- e métodos de protección no noso material.
/flickr/ / CC BY-SA
CANICHE
Por primeira vez sobre o ataque deuse a coñecer en 2014. O especialista en seguridade da información Bodo Möller e os seus compañeiros de Google descubriron unha vulnerabilidade no protocolo SSL 3.0.
A súa esencia é a seguinte: o hacker obriga ao cliente a conectarse mediante SSL 3.0, emulando interrupcións de conexión. Despois busca no cifrado -Mensaxes de etiquetas especiais do modo de tráfico. Mediante unha serie de solicitudes falsificadas, un atacante é capaz de reconstruír o contido dos datos de interese, como as cookies.
SSL 3.0 é un protocolo obsoleto. Pero a cuestión da súa seguridade segue sendo relevante. Os clientes úsano para evitar problemas de compatibilidade cos servidores. Segundo algúns datos, case o 7% dos 100 mil sitios máis populares . Tamén modificacións a POODLE destinadas aos máis modernos TLS 1.0 e TLS 1.1. Este ano novos ataques Zombie POODLE e GOLDENDOODLE que evitan a protección TLS 1.2 (aínda están asociados co cifrado CBC).
Como defenderse. No caso do POODLE orixinal, cómpre desactivar a compatibilidade con SSL 3.0. Non obstante, neste caso existe o risco de problemas de compatibilidade. Unha solución alternativa podería ser o mecanismo TLS_FALLBACK_SCSV: garante que o intercambio de datos a través de SSL 3.0 só se realizará con sistemas máis antigos. Os atacantes xa non poderán iniciar baixas de protocolo. Unha forma de protexerse contra Zombie POODLE e GOLDENDOODLE é desactivar a compatibilidade con CBC nas aplicacións baseadas en TLS 1.2. A solución radical será a transición a TLS 1.3: a nova versión do protocolo non usa o cifrado CBC. En cambio, utilízanse AES e ChaCha20 máis duradeiros.
Beast
Un dos primeiros ataques a SSL e TLS 1.0, descuberto en 2011. Como POODLE, BEAST características do cifrado CBC. Os atacantes instalan un axente de JavaScript ou unha miniaplicación Java na máquina cliente, que substitúe as mensaxes ao transmitir datos a través de TLS ou SSL. Dado que os atacantes coñecen o contido dos paquetes "dummy", poden utilizalos para descifrar o vector de inicialización e ler outras mensaxes ao servidor, como as cookies de autenticación.
A día de hoxe, as vulnerabilidades de BEAST permanecen : Servidores proxy e aplicacións para protexer pasarelas de Internet locais.
Como defenderse. O atacante ten que enviar solicitudes regulares para descifrar os datos. En VMware reduce a duración de SSLSessionCacheTimeout de cinco minutos (recomendación predeterminada) a 30 segundos. Este enfoque dificultará aos atacantes a implementación dos seus plans, aínda que terá algún impacto negativo no rendemento. Ademais, cómpre entender que a vulnerabilidade BEAST pode converterse pronto nunha cousa do pasado por si mesma; desde 2020, os navegadores máis grandes soporte para TLS 1.0 e 1.1. En calquera caso, menos do 1,5% de todos os usuarios de navegadores traballan con estes protocolos.
AFOGAR
Este é un ataque de protocolos cruzados que explota erros na implementación de SSLv2 con claves RSA de 40 bits. O atacante escoita centos de conexións TLS do destino e envía paquetes especiais a un servidor SSLv2 usando a mesma clave privada. Usando , un hacker pode descifrar unha das mil sesións TLS de clientes.
DROWN fíxose coñecido por primeira vez en 2016 e despois resultou ser no mundo. Hoxe non perdeu a súa relevancia. Dos 150 mil sitios máis populares, o 2% aínda o son SSLv2 e mecanismos de cifrado vulnerables.
Como defenderse. É necesario instalar parches propostos polos desenvolvedores de bibliotecas criptográficas que desactiven o soporte SSLv2. Por exemplo, presentáronse dous parches deste tipo para OpenSSL (en 2016 1.0.1s e 1.0.2g). Así mesmo, publicáronse actualizacións e instrucións para desactivar o protocolo vulnerable en , , .
"Un recurso pode ser vulnerable a DROWN se as súas claves son usadas por un servidor de terceiros con SSLv2, como un servidor de correo", sinala o xefe do departamento de desenvolvemento. Sergei Belkin. — Esta situación ocorre se varios servidores usan un certificado SSL común. Neste caso, cómpre desactivar o soporte SSLv2 en todas as máquinas".
Podes comprobar se o teu sistema necesita ser actualizado usando un especial — foi desenvolvido por especialistas en seguridade da información que descubriron DROWN. Podes ler máis sobre recomendacións relacionadas coa protección contra este tipo de ataques en .
Corazón
Unha das maiores vulnerabilidades do software é . Foi descuberto en 2014 na biblioteca OpenSSL. No momento do anuncio do erro, o número de sitios web vulnerables - é aproximadamente o 17% dos recursos protexidos da rede.
O ataque realízase a través do pequeno módulo de extensión Heartbeat TLS. O protocolo TLS require que os datos se transmitan continuamente. En caso de inactividade prolongada, prodúcese unha interrupción e hai que restablecer a conexión. Para facer fronte ao problema, os servidores e os clientes "facen ruído" artificialmente á canle (), transmitindo un paquete de lonxitude aleatoria. Se era maior que o paquete enteiro, entón as versións vulnerables de OpenSSL len memoria máis aló do búfer asignado. Esta área pode conter calquera dato, incluídas claves de cifrado privadas e información sobre outras conexións.
A vulnerabilidade estivo presente en todas as versións da biblioteca entre 1.0.1 e 1.0.1f inclusive, así como nunha serie de sistemas operativos: Ubuntu ata 12.04.4, CentOS máis antigo que 6.5, OpenBSD 5.3 e outros. Hai unha lista completa . Aínda que os parches contra esta vulnerabilidade foron liberados case inmediatamente despois do seu descubrimento, o problema segue sendo relevante ata hoxe. Alá polo 2017 , susceptible a Heartbleed.
Como defenderse. É necesario ata a versión 1.0.1g ou superior. Tamén podes desactivar manualmente as solicitudes de pulsación mediante a opción DOPENSSL_NO_HEARTBEATS. Despois da actualización, especialistas en seguridade da información reemitir certificados SSL. Precísase un substituto no caso de que os datos das claves de cifrado acaben en mans de hackers.
Substitución de certificados
Instálase un nodo xestionado cun certificado SSL lexítimo entre o usuario e o servidor, interceptando activamente o tráfico. Este nodo suplanta a identidade dun servidor lexítimo presentando un certificado válido e faise posible levar a cabo un ataque MITM.
Conforme equipos de Mozilla, Google e varias universidades, aproximadamente o 11% das conexións seguras da rede son escoitadas. Este é o resultado da instalación de certificados raíz sospeitosos nos ordenadores dos usuarios.
Como defenderse. Use os servizos de confianza . Podes comprobar a "calidade" dos certificados usando o servizo (CT). Os provedores de nube tamén poden axudar a detectar as escoitas; algunhas grandes empresas xa ofrecen ferramentas especializadas para supervisar as conexións TLS.
Outro método de protección será un novo ACME, que automatiza a recepción de certificados SSL. Ao mesmo tempo, engadirá mecanismos adicionais para verificar o propietario do sitio. Máis sobre iso .
/flickr/ / CC BY
Perspectivas para HTTPS
A pesar dunha serie de vulnerabilidades, os xigantes das TI e os expertos en seguridade da información confían no futuro do protocolo. Para a implementación activa de HTTPS O creador da WWW Tim Berners-Lee. Segundo el, co paso do tempo TLS volverase máis seguro, o que mellorará significativamente a seguridade das conexións. Berners-Lee incluso suxeriu iso certificados de cliente para a autenticación de identidade. Axudarán a mellorar a protección do servidor contra atacantes.
Tamén está previsto desenvolver tecnoloxía SSL/TLS mediante a aprendizaxe automática: os algoritmos intelixentes serán os encargados de filtrar o tráfico malicioso. Coas conexións HTTPS, os administradores non teñen forma de descubrir o contido das mensaxes cifradas, incluída a detección de solicitudes de malware. Xa hoxe en día, as redes neuronais son capaces de filtrar paquetes potencialmente perigosos cun 90 % de precisión. ().
Descubrimentos
A maioría dos ataques a HTTPS non están relacionados con problemas co propio protocolo, senón co soporte de mecanismos de cifrado obsoletos. A industria das TI comeza a abandonar gradualmente os protocolos da xeración anterior e ofrece novas ferramentas para buscar vulnerabilidades. No futuro, estas ferramentas serán cada vez máis intelixentes.
Ligazóns adicionais sobre o tema:
Fonte: www.habr.com