Soy un probador de penetración empresarial para mi empresa y lo que hago día tras día es entrar en sistemas. Compartiré algunas de las técnicas que utilizo para realizar ataques de hombre en el medio, para darte una idea de qué buscar (así como de qué manera defender). Si ninguno de estos escenarios suena como algo que encontraste, entonces hay una gran mayoría de posibilidades de que tu comunicación encriptada no haya sido comprometida.
HTTPS es tan seguro como las dependencias en las que se construyó. En circunstancias típicas, HTTPS hace su trabajo bien. Sin embargo, cuando uno de los requisitos fundamentales no se cumple, es vulnerable. Romper solo uno de los enlaces en la cadena puede comprometer la comunicación que se cree que está cifrada.
El ataque con herramientas como BESTIA, CRIMEN y / o BREACH nos dice que el hecho de conocer un texto simple en el mensaje que se está protegiendo permite que el túnel cifrado se invierta o se rompa.
Los ataques que involucran la vulnerabilidad Heartbleed son otro ejemplo de una falla en el protocolo SSL que permite a los atacantes recuperar datos que deberían estar encriptados.
Los ataques que usan un punto de acceso inalámbrico no autorizado y una herramienta como SSLStrip nos muestran que solo porque escribimos "HTTPS" no significa que estará allí la próxima vez que miremos. Este es un escenario de ataque muy simple de implementar, que arroja un grado de éxito significativamente alto (por lo general, veo un 90% de tasa de éxito de las pruebas de penetración que me piden).
Otra forma sería que un pirata informático (leído: no un probador de penetración respetuoso de la ley) incurra en una autoridad de certificación y genere certificados de trabajo para los sitios para los que desea interceptar las comunicaciones. Un pirata informático hace unos años que se llamaba a sí mismo "Comodohacker" comprometió múltiples autoridades de certificación, que son las empresas / organizaciones que emiten certificados SSL para los sitios web a los que nos conectamos a través de HTTPS.
Finalmente, un ataque simple pero increíblemente efectivo sería generar un certificado autofirmado. El certificado será "técnicamente" bueno, pero la CA no será confiable. Desde la perspectiva de un usuario de computadora, todo lo que verá es un mensaje que dice que el Certificado es bueno y que la CA es desconocida, con un cuadro de sí / no que pregunta "¿Desea continuar?". En un escenario de ataque, después de que el usuario haga clic en sí, verían que el canal de comunicación es HTTPS, pero no sabrán que están conectados a un proxy de Internet no autorizado que está interceptando y descifrando el tráfico. (Nota: esta técnica se usa comúnmente también con fines legítimos, como un proxy SSL corporativo que analiza todas las comunicaciones salientes en busca de la IP de la empresa y los secretos comerciales. La diferencia es que la organización generalmente agregará la autoridad de firma a una lista de autoridades de confianza en las computadoras de la empresa para evitar que aparezca el cuadro de mensaje.)
De los escenarios anteriores, el compromiso de CA es el peor de esta lista debido a que no se puede detectar directamente. Por esa razón, y también como no es muy común de todos modos, no me preocupo por eso. Los otros son lo que hay que tener en cuenta.
BESTIA y los sucesores ahora son ataques del lado del cliente. La mayoría de las vulnerabilidades que explotan pueden mitigarse manteniendo su sistema operativo, navegador de Internet y otro software actualizado. Esto debe hacerse de forma regular.
La vulnerabilidad de Heartbleed era algo más que el lado del cliente. Los despliegues de servidores de OpenSSL en todos los sitios web populares fueron igualmente vulnerables. Si estás parcheando regularmente, tampoco me preocuparía mucho por esto. La mayoría de los ataques exitosos contra esta vulnerabilidad se realizaron contra servidores de sitios web (es decir, no podemos hacer nada más que cambiar las contraseñas).
El último escenario (el certificado autofirmado) suele ser la amenaza más peligrosa a tener en cuenta en esta lista. Si bien hay usos legítimos de la técnica en sí, personalmente no me importa. Nunca hago clic en "Sí" cuando se me pide que confíe en una autoridad de certificación desconocida, y recomiendo que alguien más haga lo mismo.
Una nota al margen en caso de que sea relevante: yo personalmente no usaría el navegador de Internet Safari. Apple finalmente parchó su navegador en noviembre del año pasado para las hazañas de BEAST, pero tardaron más de 2 años desde que se lanzaron las hazañas de BEAST para hacerlo. A pesar de que Safari está parcheado en la actualidad, me preocupa su falta de enfoque en la seguridad de TI.