HTTPS es realmente HTTP sobre SSL / TLS, por lo que abordaré problemas en SSL / TLS y la combinación de ambos, pero no problemas de seguridad solo en HTML. TLS es solo el nuevo nombre para SSL, pero como la mayoría de las personas conoce el nombre SSL, lo usaré en esta respuesta. SSL se usa para evitar que un atacante pueda interceptar y, opcionalmente, modificar los paquetes enviados entre dos computadoras, conocidos como man-in-the-middle o MITM, y dicho atacante se mencionará repetidamente. SSL funciona encriptando la información enviada entre dos computadoras y es el método fundamental utilizado para asegurar las comunicaciones en Internet. Si bien SSL y HTTPS generalmente son protocolos muy seguros, han tenido algunos problemas a lo largo de los años.
Uno de los más básicos es el método de verificación de identidad. Cuando un cliente y un servidor hablan a través de HTTPS, el servidor generalmente presenta un certificado digital que el cliente puede usar para verificar que están conectados al servidor correcto. Sin embargo, el cliente no puede conocer el certificado adecuado para cada servidor del planeta. En cambio, está preprogramado con un conjunto de certificados de “autoridad de certificación raíz (CA)”. Las CA raíz son organizaciones que verifican las identidades de otras organizaciones y luego les emiten sus propios certificados que están “encadenados” al certificado raíz, de modo que es matemáticamente posible verificar que la CA raíz emitió el certificado. Dado que confiamos en las CA raíz, podemos confiar en el certificado que emitieron al sitio web.
Excepto que realmente no podemos confiar en las CA raíz. Hay cientos de ellos, por lo que las probabilidades son buenas de que cometerán errores, y de hecho, muchos de ellos han sido comprometidos (Comodo, DigiNotar), y varios otros han emitido certificados que no deberían tener, debido a ingeniería social o “accidentes”. “. Además, algunas CA raíz son parte de gobiernos conocidos por participar en operaciones ofensivas de seguridad cibernética, y algunas de esas CA han emitido certificados “accidentalmente” que podrían usarse para espiar. Este problema no se ha resuelto por completo, pero existen dos mitigaciones principales:
- ¿Cuál es la forma más segura de escribir y almacenar contraseñas?
- ¿Cuáles son las contraseñas o contraseñas de varias palabras más seguras hechas con una combinación de letras, números y símbolos?
- ¿Cuáles son los mejores programas antivirus?
- ¿Debo obtener un antivirus en Ubuntu?
- ¿Alguien puede descargar archivos de mi computadora si solo tienen mi dirección IP?
- Certificate Transparency es un proyecto iniciado por Google para publicar todos los certificados emitidos por una CA, de modo que una organización pueda ver si un certificado se ha emitido de manera fraudulenta para uno de sus dominios. Esto no detiene el ataque, pero alerta a las personas de que está sucediendo.
- La fijación de clave pública HTTP, comúnmente conocida como fijación de certificado, codifica los certificados de sitios importantes en el navegador. Para sitios importantes como Microsoft, Facebook y Google, se ignora la CA raíz y el navegador busca un certificado específico que sea propiedad de ese sitio. Esto requiere la acción de todos los sitios, pero en general ha sido eficaz tanto para proteger a los usuarios como para descubrir ataques, y hemos visto menos ataques desde que se extendió la fijación.
Este es un problema para todos los usos de SSL, no solo HTTPS.
Otro problema de diseño con la identificación es que los sitios a menudo cometen errores en la forma en que usan los certificados, de modo que el navegador advierte al usuario que el sitio es inseguro. Sin embargo, estas falsas alarmas son indistinguibles para la mayoría de los usuarios de las alarmas reales, por lo que los usuarios se acostumbran a ignorar las advertencias.
Otra vulnerabilidad: SSL 3 es vulnerable al ataque POODLE. Este ataque combina tres técnicas:
- Cuando dos computadoras hablan usando SSL, la primera parte de la comunicación es un “apretón de manos” en el que las computadoras deciden qué cifrado y versión de SSL usar, en función de lo que cada uno admite. Esto ocurre sin cifrar, ya que los algoritmos de cifrado aún no se han decidido. Debido a esto, un atacante puede falsificar respuestas para forzar el cifrado y la versión SSL al estándar más bajo admitido por ambas computadoras.
- La mayoría de los navegadores web que tienen una sesión HTTPS en una pestaña también tienen HTTP sin cifrar en alguna otra pestaña. Como no está encriptado, el atacante puede inyectar lo que quiera en esta página. En particular, en el ataque POODLE, el atacante inyecta solicitudes a una página SSL que desea atacar.
- Un ataque de oráculo de relleno, en el que el atacante puede adivinar el carácter de un mensaje cifrado y saber si tienen razón. SSL 3 tenía una vulnerabilidad de este tipo. Al adivinar repetidamente los caracteres, el atacante puede descifrar el mensaje completo.
En el ataque POODLE, el atacante usó # 1 para forzar una rebaja a SSL 3 incluso si ambas computadoras usaban versiones más nuevas. Luego usaron el n. ° 2 para emitir repetidamente consultas que atacaban la vulnerabilidad en el n. ° 3. Esto permitió el descifrado de la sesión segura, con ciertas limitaciones.
Otro ataque divertido fue el DELITO. Este ataque utilizó la técnica # 2 de arriba para emitir consultas contra una página HTTPS que usa compresión HTTP y que refleja alguna parte de la URL en la página. El atacante modifica esa parte de la URL para adivinar el texto que podría estar en la respuesta HTTP, como un token de sesión (equivalente a una contraseña). Si el atacante adivina correctamente, la respuesta se comprimirá y, por lo tanto, será un poco más pequeña que si la suposición es incorrecta, y el atacante sabrá que adivinó correctamente. La solución es desactivar la compresión en las páginas afectadas.
Otro ataque más se llama BESTIA. Este ataque explota una debilidad criptográfica en algunos algoritmos de cifrado utilizados en TLS 1.0, incluidos los valores predeterminados en Windows y Mac OS. Este error se descubrió con bastante rapidez y se emitió TLS 1.1 para solucionarlo, pero se creía que no era explotable porque requeriría que el atacante interceptara muchos paquetes similares, lo que se creía que era difícil. Sin embargo, los investigadores demostraron que la técnica # 2 anterior podría usarse para generar suficiente tráfico para explotar el error. Esto forzó una actualización rápida al último estándar, TLS 1.2.
El investigador de Google Thai Duong participó en el descubrimiento de todos los exploits con acrónimos, junto con varios colaboradores. Todo esto afecta solo a HTTPS y no a otros usos de SSL (con algunas excepciones menores).
También ha habido muchos errores específicos de implementación, como Heartbleed. Estos no eran defectos en el protocolo en sí, sino errores de programación en implementaciones específicas. Sin embargo, solo hay unas pocas implementaciones de SSL en uso amplio, por lo que los errores de implementación aún tienen un gran impacto en la práctica.
A pesar de todo esto, la comunicación en Internet es muy, muy segura. Los ataques reales contra SSL son muy raros. ¡Pero es muy divertido para los investigadores de seguridad!
