Muchos de los problemas de seguridad que nos aquejan en la red están fuera de nuestro control. En mi [último artículo](https://eldiabloenlosdetalles.net/2014/01/22/la-seguridad-de-los-sitios-financieros-y-publicos-en-chile/), mostré como varias instituciones del sector público y la banca en Chile tienen sitios webs cuya seguridad o implementación es deficiente.

Una de esas malas prácticas es no ofrecer el sitio web servido por HTTPS por defecto, o, como discutía en el artículo mencionado más arriba, incluir un formulario de identificación que envía los datos con una conexión segura pero inserto en una página que no lo es. Esto última es una práctica particularmente irresponsable por parte de, por ejemplo, el [Servicio de Impuestos Internos](http://www.sii.cl), [NIC.cl](http://www.nic.cl «NIC Chile, somos el punto CL – NIC Chile») o bancos como el [Santander](http://www.santander.cl/ «Personas – Banco Santander Chile»), que se esperaría deberían tener un profundo interés en educar a sus usuarios a utilizar buenas prácticas de seguridad. Y una de las más básicas es enseñarle a sus usuarios es que deben esperar encontrar una pista visual estándar de que la conexión (o el formulario de identificación) es segura. En el caso de Wikipedia, por ejemplo, la presencia del candado en la barra de dirección de Firefox indica una conexión encriptada:

En vez, nos encontramos con esto:

o:

Donde la única pista visual de la seguridad de la conexión es el candado o llave en el formulario de identificación. De más está decir que la presencia de ese elemento visual no significa nada: un ataque malicioso podría interceptar la conexión de un usuario a una página que se podría ver exactamente igual a la del Sanyander. La página verdadera del Banco Santander transmite la información del formulario vía una conexión segura, pero un usuario no tiene una forma fácil de verificar esto

Afortunadamente, existe una solución relativamente fácil para resolver esto por parte de los usuarios de estos sitios: utilizar [HTTPSEverywhere](https://www.eff.org/https-everywhere «HTTPS Everywhere | Electronic Frontier Foundation»), una extensión para Firefox (con una versión beta para Chrome y Ópera) que permite utilizar por defecto la versión segura de un sitio web. Es decir, si el usuario intenta visitar http://www.santander.cl, esta extensión automáticamente dirige la conexión a https://www.santander.cl.

Agregar nuevos sitios (o *reglas*, en la nomenclatura utilizada por sus desarrolladores) no es tan fácil como podría ser, pero acá va una breve guía (copiada y pegada de [aquí](https://github.com/moffat/HTTPSEverywhereUserRules «moffat/HTTPSEverywhereUserRules · GitHub»)):

1. Instalar [HTTPS Everywhere](https://www.eff.org/https-everywhere).

2. Crear una *regla*, que es un archivo .xml bastante simple. La siguiente es la que escribí para el Banco Santander:

3. Las reglas escritas por el usuario deben ser copiadas al directorio HTTPSEverywhereUserRules, que se encuentra en el directorio del perfil del usuario de Firefox:

* Linux: ~/.mozilla/firefox/
* OS X:
* ~/Library/Application Support/Firefox/Profiles/
* ~/Library/Mozilla/Firefox/Profiles/
* Windows: %APPDATA%\Mozilla\Firefox\Profiles

Una vez reiniciado Firefox, la visita al sitio del Banco Santander resulta en:

y que muestra que la conexión, finalmente, es segura ((Pero revela otro pecadillo: El sitio *seguro* del Banco Santander incluye contenido que no está servido por HTTPS. Afortunadamente, Firefox bloquea por defecto este contenido, asegurando una conexión de mayor seguridad)).

Es de esperar que estas instituciones (te estoy mirando a ti, SII) comiencen a tomarse más en serio tanto la seguridad como la educación de sus usuarios. Por lo pronto, he publicado en GitHub [algunas reglas](https://github.com/moffat/HTTPSEverywhereUserRules «moffat/HTTPSEverywhereUserRules · GitHub») para algunos sitios de interés en Chile. ¿Disfrute?

Si hay una lección importante que aprender de todo lo sucedido el año 2013 es que nuestra privacidad y la seguridad de nuestros datos en la red están siendo atacados en forma incesante por razones tanto [políticas](http://www.theguardian.com/world/the-nsa-files «The NSA files | World news | The Guardian») como [económicas](http://krebsonsecurity.com/2013/10/adobe-breach-impacted-at-least-38-million-users/). Estas historias han puesto en evidencia la importancia de que instituciones públicas y privadas redoblen sus esfuerzos para utilizar los más altos estándares de seguridad cuando se trata de interactuar con ciudadanos o clientes en la red.

Esto es lo que tenía en mente cuando me enteré de que [SSL Labs](https://www.ssllabs.com/ «Qualys SSL Labs») había actualizado sus herramientas para medir la seguridad de la configuración utilizada por servidores web, y que utiliza el sistema norteamericano de letras de A (Excelente) a F (Reprobado) para darle una «nota» al sitio. Armado con mi navegador, el [SSL Server Test](https://www.ssllabs.com/ssltest/index.html), y [las recomendaciones](https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet «Transport Layer Protection Cheat Sheet – OWASP») de los expertos, probé la seguridad de los sitios de bancos y otras instituciones críticas de nuestra infraestructura digital.

Los resultados, que publico a continuación, muestran que hay varias instituciones que requieren un llamado de sus usuarios para que solucionen lo que podrían ser serios problemas de seguridad:

## Los mateos:

En este grupo están los que se sacan una «A-» por una buena implementación de estándares modernos y seguros para una conexión segura: [ServiPag](https://www.ssllabs.com/ssltest/analyze.html?d=servipag.com) y [TransBank](https://www.ssllabs.com/ssltest/analyze.html?d=transbank.cl), y los Bancos de [Chile](https://www.ssllabs.com/ssltest/analyze.html?d=bancochile.cl), [Itau](https://www.ssllabs.com/ssltest/analyze.html?d=banco.itau.cl) y [BBVA](https://www.ssllabs.com/ssltest/analyze.html?d=bbvanet.cl).

## Los alumnos promedio:

El [Banco Corpbanca](https://www.corpbanca.cl) saca una «B» por no incluir soporte para los protocolos más modernos de encripción.

El [Registro Civil](https://www.registrocivil.cl) y la [Tesorería General de la República](https://www.ssllabs.com/ssltest/analyze.html?d=tesoreria.cl) tienen sitios que mezclan elementos encriptados y otros que no. [Mala idea](https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Do_Not_Mix_TLS_and_Non-TLS_Content), aunque no es el [único problema](https://www.ssllabs.com/ssltest/analyze.html?d=www.registrocivil.cl&s=163.247.64.131 «Qualys SSL Labs – Projects / SSL Server Test / registrocivil.cl»).

Pero los hay peores. Mucho peores.

## Los reprobados:

Y aquí llegamos a esas instituciones que han creado sus sitios web utilizando tecnologías obsoletas, inseguras o con problemas de implementación que ponen en riesgo la seguridad de sus usuarios.

En esta categoría caben realmente dos grupos. En el primero están algunos sitios que, de hecho, obtuvieron una buena nota en el test de SSL Labs, pero cuya implementación le resta un tremendo grado de seguridad a sus sitios. Aquí caben los Bancos [Santander](https://www.ssllabs.com/ssltest/analyze.html?d=santander.cl) y [Falabella ](https://www.ssllabs.com/ssltest/analyze.html?d=www.bancofalabella.cl&s=200.10.172.121), que tienen un sitio seguro (pruébelo usted mismo cambiando http:// por https:// en su navegador) pero que *por defecto* ofrecen la página de acceso que se transmite sin encripción alguna (aunque la información del formulario si se transmite así). Como dicen los expertos de la [OWASP](https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet#Rule_-_Use_TLS_for_All_Login_Pages_and_All_Authenticated_Pages
«Transport Layer Protection Cheat Sheet – OWASP»), esto es una mala práctica:

> La página de autenticación y todas las páginas autentificadas subsecuentes deben tener acceso exclusivo a través de TLS. La página inicial de autenticación, denominada «página de llegada de autenticación» («page landing page»), debe estar servida vía TLS. **El no utilizar TLS para la página de llegada le permite a un atacante modificar el formulario de autenticación, causando que las credenciales de un usuario sean enviadas a un lugar arbitrario**. El no utilizar TLS para paginas autentificadas después del *login* permite a un atacante ver el ID de sesión sin encriptar y comprometer así la sesión autenticada del usuario.

En este grupo merece atención especial el [Banco Bci](https://www.ssllabs.com/ssltest/analyze.html?d=bciimg.bci.cl), que tiene un [sitio seguro](https://www.bci.cl/personas/) que responde con un error, cuyo formulario de autenticación es una [ventana emergente](http://es.wikipedia.org/wiki/Ventana_emergente «Ventana emergente – Wikipedia, la enciclopedia libre») que no le permite verificar al usuario la seguridad de la conexión (¿Aló, 2001?). De esto también es culpable el [muy popular](http://www.alexa.com/topsites/countries/CL «Alexa – Top Sites in Chile») [Mercado Libre](http://www.mercadolibre.cl).

El segundo grupo son instituciones que, a pesar de ofrecer la aparente tranquilidad de una conexión segura, utilizan una configuración que recibe una «F» (¡Reprobado!) en el test de seguridad de SSL Labs. Este hall de la desgracia no es ni pequeño ni poco importante, e incluye nada menos que a los Bancos [Internacional](https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fwww.bancointernacional.cl%2Findex.html), [Consorcio](https://www.ssllabs.com/ssltest/analyze.html?d=bancoconsorcio.cl), [Estado](https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fwww.bancoestado.cl%2Fimagenes%2Fcomun2008%2Fnuevo_paglg_pers2.html), [Bice](https://www.ssllabs.com/ssltest/analyze.html?d=bice.cl), [Paris](https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fwww.bancoparis.cl%2F), [Security (!!!)](https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fwww.bancosecurity.cl%2Fwidgets%2FwPersonasLogin%2Findex.asp),[Penta](https://www.ssllabs.com/ssltest/analyze.html?d=https%3A%2F%2Fwww.bancopenta.cl%2FfrmLogin.aspx%3FReturnUrl%3D%252f), [Rabobank](https://www.ssllabs.com/ssltest/analyze.html?d=secure.rabobank.cl «Qualys SSL Labs – Projects / SSL Server Test / secure.rabobank.cl») y [ScotiaBank](https://www.ssllabs.com/ssltest/analyze.html?d=www.scotiabank.cl&s=200.55.208.28). Es decir, de los 17 bancos que son parte de la [ABIF](http://www.abif.cl) más el Banco del Estado, solo cuatro (24%) han implementado sus sitios en una forma que pasa estos estándares de seguridad y ofrecen ese acceso con una página via [TLS](https://es.wikipedia.org/wiki/Transport_Layer_Security «Transport Layer Security – Wikipedia, la enciclopedia libre»).

Y como guinda de la torta, tenemos al [Servicio de Impuestos Internos](http://www.sii.cl) ((El SII tuvo que cambiar, hace unos años, el certificado que usaba para encriptar sus sesiones web después de que el periodista Christian Leal publicara en su blog que el la longitud de la llave del certificado – 128 bit – era claramente insuficiente para estos tiempos.)). El SII comete el mismo pecado de implementación de varios de los bancos que mencionaba arriba, insertando un formulario de autenticación «seguro» en una página insegura (es decir, sin utilizar https/TLS). Como apunta la OWASP, alguien podría atacar a un usuario o grupo de ellos falsificando la página del SII con ese mismo formulario (el usuario normal no tiene forma de saber si ese formulario envía la información en forma segura). Aún peor, el SII [obtiene una «F»](https://www.ssllabs.com/ssltest/analyze.html?d=zeus.sii.cl «Qualys SSL Labs – Projects / SSL Server Test / zeus.sii.cl») con SSL Labs por varias fallas serias de seguridad, incluyendo aceptar conexiones usando protocolos inseguros, no incluir protocolos más modernos y seguros, y ser susceptibles a ataques que se conocen [desde al menos el año 2009](https://community.qualys.com/blogs/securitylabs/2009/11/05/ssl-and-tls-authentication-gap-vulnerability-discovered «SSL and TLS Authentication Gap vulnerability discovered | Security Labs | Qualys Community»).

Hace años, cerré mi cuenta en ScotiaBank en parte porque los problemas de seguridad que noté en su sitio web ((en ese tiempo aún tenían el formulario de autenticación inserto en una página insegura)) me hizo desconfiar de la capacidad del banco de resguardar mis datos. Este simple ejercicio con SSL Labs (y que está lejos de ser una auditoría de seguridad completa) demuestra que los problemas son mucho más generalizados en la internet criolla. Dada las amenazas comprobadas que han sido reveladas en los últimos meses, parece que el mejor momento para asegurar que la información de millones de chilenos está segura era ayer.

**Actualización 27-Enero**: la versión original del artículo decía que el Banco París había obtenido una buena *nota* en el test de SSL Labs, lo que es incorrecto. A esta fecha, obtienen una F.

Hoy, la revista Foreign Policy [reveló](http://thecable.foreignpolicy.com/posts/2013/10/24/exclusive_germany_brazil_turn_to_un_to_restrain_american_spies «Exclusive: Germany, Brazil Turn to U.N. to Restrain American Spies | The Cable») que un grupo países liderados por Brasil y Alemania están trabajando juntos para que la Asamblea General de las Naciones Unidas adopte una resolución reafirmando la importancia de la privacidad en internet. El [documento](http://www.scribd.com/doc/179039226/UN-Draft-on-Privacy «UN Draft on Privacy») no menciona ni a Estados Unidos ni a la NSA, pero el objetivo de la resolución es evidente: generar presión internacional para que EEUU tome pasos serios para controlar la vasta red de espionaje que ha sido montada por la NSA.

Además de Alemania y Brasil, la lista de los países trabajando en este esfuerzo son:

> **Argentina**, Austria, **Bolivia**, **Cuba**, Francia, **Ecuador**, **Guyana**, Hungría, India, Indonesia, Liechtenstein, **México**, Noruega, **Paraguay**, Sudafrica, Suecia, Suiza, **Uruguay** y **Venezuela**.

Dos cosas notables en esta lista: primero, refuerza la idea de que más que Europa vs. EEUU, la disputa por los programas de espionaje enfrenta por un lado a un eje de países en su mayoría angloparlantes – como Australia, Gran Bretaña, Nueva Zelanda e Israel – con, por el otro lado, países en el resto del mundo que se se ven en tremendo peligro de perder su soberanía de sus instituciones y ciudadanos a través de la [erosión masiva de la privacidad](http://eldiabloenlosdetalles.net/2013/10/23/el-silencio-de-chile-ante-las-revelaciones-de-la-nsa/ «El Diablo en los Detalles » El silencio de Chile ante las revelaciones de la NSA») que es el producto de estos programas de espionaje.

Y lo segundo, y quizás más evidente, es la fuerte presencia Latinoamericana en este esfuerzo. Fuerte, pero no unánime, gracias en parte a la ausencia de [Chile](http://eldiabloenlosdetalles.net/2013/10/23/el-silencio-de-chile-ante-las-revelaciones-de-la-nsa/ «El Diablo en los Detalles » El silencio de Chile ante las revelaciones de la NSA»), que a diferencia de muchos de los países de la lista más arriba, ha sido nombrado [específicamente](http://www.latercera.com/noticia/mundo/2013/07/678-532146-9-prensa-brasilena-revela-que-red-de-espionaje-de-eeuu-se-extendio-por-toda.shtml «Chile figura entre los paÌses espiados por EEUU seg˙n archivos filtrados por Snowden | Mundo | LA TERCERA») como uno de los países víctimas del espionaje de la NSA. Una omisión lamentable del Gobierno de Chile, y que no hace más que contribuir a la impresión de que después de los primeros [anuncios rimbombantes](http://www.elmostrador.cl/pais/2013/07/10/chile-intentara-verificar-si-ha-sido-espiado-por-ee-uu-y-pedira-explicaciones/ «Chile intentará verificar si ha sido espiado por EE.UU. y pedirá explicaciones – El Mostrador»), parece haber abandonado sus esfuerzos de investigar las acciones de la NSA, y de tomar un rol de liderazgo en contrarrestarlas vía esfuerzos como el que están en marcha en Naciones Unidas.