Principio de funcionamiento de HTTPS

El protocolo HTTP está construido sobre TCP. TCP garantiza que los datos serán entregados, o es imposible entregarlos (objetivo no alcanzable, etc.). Abre una conexión TCP y envía mensajes HTTP a través de ella.

Pero TCP no garantiza ningún nivel de seguridad. Por lo tanto, una capa intermedia llamada SSL se coloca entre TCP y HTTP y se obtiene el llamado HTTPS. Esta forma de trabajar se denomina tunelización: se vuelcan los datos en un extremo del túnel (SSL) y se recopilan en el otro. SSL recibe mensajes HTTP, los cifra, los envía a través de TCP y los descifra de nuevo en el otro extremo. El cifrado lo protege de escuchas ilegales y ataques MITM transparentes (alterando los mensajes).

Pero SSL no solo proporciona cifrado, sino que también proporciona autenticación. El servidor debe tener un certificado firmado por una entidad de certificación (CA) bien conocida que demuestre su identidad. Sin autenticación, el cifrado es inútil ya que el ataque MITM todavía es posible. El atacante podría engañarlo para que piense que él es el servidor al que desea conectarse. El chat privado con el demonio no es lo que quiere, usted quiere verificar que el servidor al que se está conectando realmente sea el servidor al que desea conectarse. La autenticación lo protege de MITM.

Puntos débiles

Entonces, ¿dónde están los puntos débiles?

• Puntos finales de conexión segura. La transferencia podría ser segura, pero ¿qué pasa con el propio servidor? O el cliente? Ellos no pueden.
• No está utilizando HTTPS. Se puede engañar a los usuarios para que no utilicen el esquema de varias maneras.
• CAs no confiables. Rompen la parte de autenticación, permitiendo el ataque MITM.
• Mecanismo de encriptación débil. Las tecnologías criptográficas envejecen de dos maneras: se pueden encontrar fallas graves en su diseño, lo que lleva a ataques mucho más eficientes que la fuerza bruta, o el aumento de sus parámetros y potencia de procesamiento debido a la ley de Moore podría permitir un ataque de fuerza bruta factible.
• Implementación del esquema. Bueno, si especifica A e implementa B, las propiedades de A pueden no ser válidas para B.

Respuestas directas

• Parece que dice que aseguró la transferencia (utilizando SSL). Esto no es suficiente, la seguridad de su servidor puede verse comprometida: no debe almacenar las contraseñas allí en texto sin formato, use su forma de hash, con sal agregada, ...

• SSL encripta los datos tanto al enviar como a recibir. Los ataques MITM son posibles virtualmente solo cuando el atacante tiene un certificado firmado por una autoridad en la que el cliente confía. A menos que se engañe al cliente para que no use HTTPS, nadie puede leer ni modificar los mensajes que se envían.

• GET y POST son solo dos métodos para realizar una solicitud HTTP. Hay varios otros, también. El método es solo una propiedad de la solicitud HTTP. Todos los mensajes están protegidos, tanto las solicitudes como las respuestas, independientemente del método HTTP utilizado.

SSL protege los datos en tránsito al cifrarlos. Solo garantiza, para un cliente, que los datos pasarán de su computadora a su servidor sin ser interceptados o alterados (los datos encriptados pueden ser interceptados pero no tienen significado sin descifrado). Dicho esto, es responsabilidad del cliente asegurarse de que SSL esté funcionando correctamente antes de enviar cualquier dato o salida de confianza del servidor. Hay ataques que eliminarán SSL de la conexión, pero no que interceptarán o alterarán los datos enviados a través de una conexión SSL segura.

SSL no proporciona ninguna seguridad una vez que los datos están en el servidor. Todavía es necesario utilizar hashing y cifrado del lado del servidor si desea proteger los datos en reposo de las violaciones al propio servidor.

HTTPS es HTTP enviado a través de una conexión cifrada SSL. Cubre GET y POST y cualquier otra acción HTTP, ya que toda la transmisión HTTP se produce sin alteraciones, pero se pasa a través de un túnel SSL al navegador del cliente.

SSL solo protege la conexión entre el cliente y el servidor. En teoría, lo hace bastante bien (está bien, hay algunos problemas, pero estos son menores en comparación con todos los demás problemas) siempre y cuando ninguno de los aproximadamente 150 CA en los que confía dentro de su navegador se vea comprometido o funcione junto con algunas agencias y les da CA intermedia para hacer ataques de hombre en el medio.

Y, como dije, asegura solo la conexión entre el cliente y el servidor. Por lo tanto, cualquier problema en su aplicación web como Cross-Site-Scripting, Cross-Site-Request-Forgery, SQL-Injection, identificadores de sesión inseguros, etc., aún funcionará, incluso si la conexión está encriptada. Además, el servidor puede verse comprometido, etc.

En resumen, SSL es algo necesario para proteger los datos, pero no es lo único que debe hacer para mantener los datos seguros.

Un detalle importante que las otras respuestas no mencionaron es que SSL no cifra la URL de la solicitud. Tenga en cuenta que bajo el esquema GET, los datos generalmente se codifican como parámetros en la URL. Esto significa que si envía un formulario con un campo de contraseña sobre GET, la contraseña NO se cifrará.

¿De quién intentas asegurar la comunicación? Si se trata de la NSA o de cualquier otra agencia de seguridad estatal, la respuesta es no: tienen los recursos y la tecnología para implementar con éxito los ataques del hombre en el medio contra SSL. Si se trata de redes criminales a gran escala, la respuesta sigue siendo no: no pueden comprometer a las autoridades de certificación de la forma en que NSA et al. pueden, pero pueden comprometer fácilmente las máquinas por sí mismas, y ver los datos salientes antes y los datos entrantes después del cifrado. Sin embargo, si solo está alojando un servidor, eso es menos preocupante para usted, ya que es mucho más probable que el compromiso se produzca en la máquina del usuario final y luego sea su problema. Si se trata de rastreadores aleatorios de paquetes que intentan robar y explotar datos, entonces sí, y a pesar de lo anterior, es una amenaza suficiente como para que uses SSL siempre que sea posible.