¿Protege HTTPS contra atacantes activos?

TLS (el protocolo de red seguro subyacente de HTTPS) especifica un gran número de "conjuntos de cifrado" (combinaciones de primitivas criptográficas, como cifrados asimétricos y simétricos, funciones hash, etc.). Todas las suites de cifrado ampliamente utilizadas, las únicas que deberían ser permitidas por clientes como los navegadores web o los servidores, proporcionan lo siguiente:

1. Autenticación del servidor (por lo que un atacante no puede presentar su propia clave pública y hacer que el cliente la acepte como válida).
2. El cifrado de los datos transferidos en ambas direcciones (lo que proporciona confidencialidad, como usted anotó).
3. Integridad del texto del mensaje (por ejemplo, para evitar ataques de volcado de bits en el texto cifrado).
4. Protección de reproducción (capturar el tráfico cifrado de una parte de la conversación e inyectarlo en una parte posterior no funcionará).
5. Protección de secuencia (un atacante no puede tomar múltiples paquetes de mensajes, reorganizarlos y transmitir el mensaje reensamblado; se rechazará)

Algunas suites de cifrado proporcionan protección adicional:

• Perfect Forward Secrecy (PFS), de manera que incluso si un atacante graba una conversación y luego obtiene acceso a la clave privada del servidor, la conversación nunca puede ser desencriptada (salvo por fuerza bruta o rompiendo las primitivas criptográficas).

TLS (incluido HTTPS) puede configurarse opcionalmente para proporcionar la siguiente protección:

• Autenticación del cliente (normalmente, el servidor proporciona al cliente un certificado que muestra la autenticidad del servidor; es posible que el cliente también proporcione al servidor un certificado de este tipo, que puede reemplazar la necesidad de otras formas de autenticación, tales como como transmitir una contraseña).
• Protección de versiones anteriores, evitando el retroceso a versiones anteriores de protocolos con vulnerabilidades conocidas o supuestas.

TLS no proporciona las siguientes protecciones:

• Enmascaramiento de longitud, más allá del grado limitado proporcionado por algunas primitivas (si el atacante conoce las longitudes de los posibles mensajes en cualquier dirección, y cada mensaje posible tiene una longitud diferente, el atacante probablemente pueda reconstruir el tráfico de mensajes observando las longitudes de los mensajes ).
• Enmascaramiento de tiempo, más allá de agregar cierta sobrecarga (si el atacante sabe cuánto tardan ciertas operaciones, el atacante puede adivinar cuándo se solicitaron / realizaron esas operaciones al monitorear los tiempos entre mensajes en cada dirección).
• Disponibilidad (un hombre en el medio siempre puede simplemente decidir no pasar el tráfico de la red, lo que resulta en una denegación de servicio).
• El anonimato del cliente o del servidor (la dirección IP del cliente y la dirección IP y el nombre del host del servidor se exponen en texto sin formato a cualquier persona que supervise el tráfico).

En general, sí, HTTPS está seguro contra la mayoría de los ataques activos , aparte de la denegación de servicio. Sin embargo, hay limitaciones. TLS no protege contra la explotación de las debilidades en las primitivas criptográficas que utiliza (por ejemplo, esta es la razón por la que las suites de cifrado que utilizan el cifrado simétrico RC4 ahora están en desuso). Su cifrado pierde canales laterales, como la duración y la sincronización, que en algunas aplicaciones pueden permitir que un atacante rompa la confidencialidad (aunque una aplicación preocupada por la seguridad podría normalizar las longitudes / temporizaciones del tráfico de la red para cerrar este canal lateral). p>

Además, es posible utilizar TLS de forma insegura si lo configura incorrectamente. Por ejemplo, las verificaciones de validación de autenticidad de los certificados se pueden desactivar o reemplazar con verificaciones personalizadas incorrectas, invalidando la verificación de autenticación y permitiendo que un atacante activo use un certificado fraudulento. Si tanto el cliente como el servidor permiten conjuntos de cifrado inseguros ("NULL"), es posible configurar TLS para que no utilice autenticaciones, cifrado o controles de integridad. Finalmente, las implementaciones TLS en sí mismas pueden tener vulnerabilidades de seguridad. La vulnerabilidad "Heartbleed" de 2014 se debió a un error de seguridad extremadamente grave en una biblioteca TLS muy común (OpenSSL); Si se usan implementaciones inseguras / no parcheadas, las protecciones de TLS pueden omitirse y / o pueden introducirse otras debilidades.

Diría que depende del tipo de active attack y del intent del atacante ... si este es un ataque de denegación de servicio, entonces HTTPS no lo protegerá realmente aquí ... pero si la intención es obtener acceso a datos privados, entonces HTTPS es una buena PRIMERA línea de defensa:

Por ejemplo, si desea iniciar sesión en un sitio web de un banco, el sitio le solicita su nombre de usuario y contraseña. Al enviar estos datos, no desea que se transfieran correctamente en texto claro, por lo que una forma en que la aplicación lo protege es usar la tecnología HTTPS para "ocultar" estos datos a simple vista (encriptación) a medida que se envían al banco para su verificación. Y una vez que el banco lo recibe, sabe cómo "volver a esconderlo" a sus credenciales e iniciar sesión. Luego, el servidor del banco emitirá un identifier/session para ayudarlo a rastrearlo a medida que se mueve entre las páginas web en el la aplicación El banco necesita una forma de compartir / enviarle este session/identifier . Y no queremos que un intruso escuche este identificador / sesión o lo adivine, por lo que el cifrado se usa para ocultarlo nuevamente a la vista del avión y enviarlo a usted. Estoy simplificando aquí, por supuesto, pero esa es la idea. Y esa es una forma en que HTTPS puede protegerlo de un atacante.

HTTPS no es de ninguna manera la única defensa que debes tener contra los atacantes. Necesita más que eso, por ejemplo, necesita proteger su sistema contra usuarios autorizados, XSS, inyección SQL, etc.

Esto también depende de lo que está tratando de proteger. Esta es una buena pregunta, pero puede responderse de muchas maneras ya que "depende" de varias cosas.