Como no hacer una página login: Ejemplo con Twitter

Cuando Moxie publicaba en 2008 sslstrip expuso varios trucos para engañar a un usuario que iban desde poner favicons con candados hasta quitar todos los enlaces https. Entre los trucos que presentó, uno de ellos era bastante sencillo basado en la mezcla de contenido.

Imaginemos una página que se entrega por Https, por ejemplo la página de login. En uno de los enlaces se va a generar el envío de credenciales a una aplicación y este puede ser https o http. Lo que el usuario espera es que sea https, pero... ¿qué pasa si se dejan todos los links con https menos justo ese utilizando sslstrip en un ataque mitm? Pues lo que pasa es que el usuario vería un candado y el link a https en la barra de tareas, pero no todo el contenido ha sido entregado cifrado.

Los navegadores, cuando esto sucede, a día de hoy, intentan generar un mensaje de alerta, para que el usuario esté informado. Sin embargo, como pasa muchas veces, si las cosas que debían estar bien hechas generan las mismas alertas, el usuario no sabrá diferenciar entre una alerta producida por un ataque o porque la página está mal construida. Es el mismo ejemplo que se mostró en La muerte social del SSL en la banca, pero ahora en mezcla de contenido.

Un ejemplo con el login de Twitter

En twitter utilizan un certificado digital de validación extendida, que además ha sido generado para evitar los ataques de TLS Renegotitation. Como se puede ver, la herramienta de Qualys de comprobación de certificados le da un 88, mejor incluso que el de Microsoft.com que obtiene un 85.


Figura 1: Evaluación del certificado de twitter.com
Sin embargo, si entramos a la página de login, se puede ver que se genera una alerta de contenido entregado de forma insegura. ¿Te habrán inyectado algo?. ¿Me habrán hecho un ssltrip a algunas partes?


Figura 2: Alerta de contenido entregado de forma insegura con IE8
Si observamos el código fuente, la mayoría de los enlaces son relativos a la URL,, así que, como estamos con https en la URL son enlaces seguros, pero, si se hace una búsqueda del protocolo http, se puede ver que hay carga de archivos inseguras.


Figura 3: carga de archivos por http
Lo curioso de esto es que si se solicita de forma manual uno de esos archivos entregados de forma insegura por https, el sistema lo entrega.


Figura 4: Acceso a fichero por https
La pregunta entonces es ¿por qué no entregar todos de forma segura? En estas lides la respuesta suele ser siempre algo en base al rendimiento. Es cierto que estos archivos no tienen ningún dato que a priori parezca sensible, pero la entrega de ellos por http se cepilla la protección de toda la página y abre un camino para que los usuarios no sean capaces de diferenciar entre una entrega segura de la página o una entrega stripeada.

Luego, cuando me preguntan en una entrevista... ¿cómo puede saber un usuario si una compra es segura? no tengo tiempo para responder todas las cosas que habría que mirar.

Saludos Malignos!