Se ha descubierto que algunos teléfonos Nokia, con la excusa de ganar velocidad, descifran el tráfico cifrado que generan los usuarios en servidores de la compañía. Aunque lógicamente Nokia niega que se tenga acceso a esos datos y que se hace por ganar velocidad, el problema es otro, quizás más grave.
El navegador nativo de Nokia (Ovi) en sus teléfonos con sistema operativo de la serie 40, utiliza proxies propios de la compañía para interceptar el tráfico. En principio, no es tan sorprendente por dos razones:
- Ya lo hacen otros navegadores como Opera Mini, por ejemplo, siempre en aras de la velocidad. El tráfico llega a sus servidores primero, lo envían al destino real, reciben la respuesta, la comprimen, y la devuelven al teléfono. El consumo de ancho de banda es menor y la velocidad percibida mayor.
- El tráfico HTTP no está cifrado por definición, así que tampoco supone mayor problema.
Pero, ¿y con el tráfico HTTPS (cifrado)? El tráfico SSL es, por definición, cifrado punto a punto. Esto es, solo el emisor y destinatario deben poder cifrar y descifrar el contenido. Opera no intenta cifrarlo ni se pone «en medio«, pero Nokia… se saltaba este paso. También redirigía el tráfico cifrado a sus servidores, lo descifraba, establecía una comunicación punto a punto con el destinatario desde ahí, y lo devolvía al cliente. En definitiva, no era una conexión SSL real, sino que Nokia podía «espiar» todo el tráfico y se realizaba en dos pasos «punto a punto« en el que, durante el proceso, quedaba inevitablemente descifrado.
¿Cómo es posible?
Guarang Pandya realizó unas pruebas estudiando con Wireshark el tráfico generado por su teléfono. Nokia estaba realizando un «ataque MiTM» en toda regla.Para que estos ataques tengan éxito en un entorno cifrado y sin que se note, hay que hacer dos cosas:
- Engañar a los DNS del usuario para que vayan a un dominio diferente al de destino. Este es el comportamiento «normal» del teléfono: si se visitaba un dominio, siempre se acababa en los proxies de Nokia.
- Luego hay que hacer que el navegador no se queje de que el certificado del destino es falso, así que es necesario crear otro certificado intermedio para el intermediario, que se encargará de realizar la conexión con el destino. El navegador se quejará porque ese certificado intermedio no estará validado… a menos que en el propio teléfono se incluyan las autoridades necesarias para validarlo, cosa que hace.
Cuando se realizaba una petición DNS a cualquier dominio desde el navegador Nokia, en realidad se redirigía a uno en su poder, por ejemplo cloud13.browser.ovi.com. Se establece entonces una comunicación cifrada con los certificados de Nokia entre el emisor y ese servidor. Y es ese servidor de Nokia el que establece la comunicación cifrada con el destino. Mientras, en el paso intermedio, en los servidores de Nokia, el tráfico queda descifrado. El certificado intermedio usado es válido a todas luces para el navegador del teléfono, puesto que se le han instalado las entidades certificadoras correspondientes.
Nokia responde
En realidad, la prueba realizada por el investigador no era concluyente. Nokia podía estar haciendo un «retunelizado» por HTTPS, de forma que en ningún momento se descifrara el contenido, sino que se «recifrara» haciendo de proxy con los datos cifrados como si de texto claro se tratase. Pero Nokia, con su respuesta, lo dejó claro:
«Importantly, the proxy servers do not store the content of web pages visited by our users or any information they enter into them. When temporary decryption of HTTPS connections is required on our proxy servers… it is done in a secure manner… Nokia has implemented appropriate organisational and technical measures to prevent access to private information. «
Nokia ya admitía en su página que almacenaba las URL, no los datos:
«The URLs of such sites which you access with the Nokia Browser are
stored by Nokia. However, we will not collect any personallyidentifiable information in the context of providing the service.«
Por último, en pocos días han actualizado su navegador para realizar un comportamiento diferente. Ahora, las peticiones del usuario siguen yendo a un servidor que les pertenece, pero lo realizan de otra manera. Si es HTTPS, ese servidor tuneliza por HTTP la conexión, de forma que no tiene que descifrarla, cifrarla y enviarla, sino que pasa toda cifrada en sus servidores como si de una conexión HTTP normal se tratara, solo que de datos cifrados.
El problema
Es bastante probable que Nokia no almacenara los datos de los usuarios. Pero sí suponen un problema en sí estas prácticas donde se accede a información sensible sin conocimiento del usuario, violando la definición de comunicación cifrada punto a punto, e introduciendo certificados intermedios en el equipo del usuario. Suponen un único punto de fallo para todas las comunicaciones cifradas de todos los usuarios de los teléfonos s40 de Nokia. Además, dadas las últimas circunstancias y abusos relacionados con los certificados y comunicaciones cifradas o código firmado, no es buena idea añadir dudas sobre un sistema de cifrado que, aunque imperfecto, es el más utilizado en estos momentos.
Más información:
Nokia’s MITM on HTTPS traffic from their phone
How the Nokia Browser Decrypts SSL Traffic: A “Man in the Client”
Sergio de los Santos
Twitter: @ssantosv
Hecho en falta hablar de que, aparte de la confidencialidad, se rompe totalmente el esquema de confianza PKI ya que el usuario deja de poder validar si el certificado de destino es seguro o no.
Es decir, entiendo que Nokia, para prevenir problemas de usabilidad, no validaría los certificados del servidor de destino (autofirmado, revocado, caducado?) mostrando siempre una conexión de confianza cuando el servidor de destino ha podido verse comprometido y presentar un certificado inválido