Manuel (nombre ficticio para mantener su anonimato), un miembro de la Comunidad, me escribía hace ya unos días para hacerme llegar la siguiente pregunta:
Tengo una preocupación acá y quería ver cuál es tu opinión.
Yo vivo en Ecuador y, este año, a mi país se le ocurrió hacer un censo nacional por primera vez totalmente en línea.
Yo soy servidor público y, obviamente, para nosotros es especialmente obligatorio registrarnos en el censo desde el 1 de octubre que pasó.
Con ese contexto, hoy quise entrar a la página de la entidad y resulta que la página no tiene certificado https que, según entiendo, es lo mínimo que cualquier página debe tener para el seguro manejo de datos de los usuarios… mil veces más en el caso de una página en la que te preguntan hasta cuántos baños tiene tu casa
Quería saber cuál es tu opinión. Debería expresar mi preocupación en el área de sistemas para que de alguna forma se exija mayor seguridad en la pagina antes de obligarnos a ingresar datos; o, sólo es algo de paranoia de mi parte y puedo ingresar mis datos sin problema?
Generalmente este tipo de preguntas las respondo simplemente en privado, pero esta en particular, con diferentes formas, veo que se repite bastante, y viene dada por ese esperable desconocimiento del usuario medio de lo que supone, y lo que no supone, que una comunicación digital esté protegida con una conexión HTTPs. Que tenga TLS o SSL activo, vamos.
Por ello, aunque a «Manuel» ya le respondí en su momento, me ha parecido interesante dedicar la pieza de hoy a explicar todo esto.
¿Qué es una conexión HTTPs?
Empecemos por el principio.
Como ya expliqué en más de una ocasión por esta Santa Casa, una conexión HTTPs no es más que una conexión HTTP que utiliza un protocolo de comunicación TLS o SSL.
¿Y qué es entonces el HTTP?
Pues el HTTP son prácticamente todas las conexiones que haces tú y yo cuando nos conectamos a Internet. Sin ir más lejos, para entrar a ver cualquier artículo de mi página, has clicado o escrito el nombre de mi página en un navegador, y por tanto, tu dispositivo ha realizado una conexión HTTP (con un SSL además activo) a mi servidor, y este le ha devuelto la respuesta, con el contenido de este artículo en particular, también mediante una conexión HTTP (y con la coletilla del «s» al final).
Es decir, HTTP es un conjunto de protocolos estándares que nos permiten comunicarnos por Internet indistintamente del sistema operativo, dispositivo, navegador y tecnología que utilicemos.
Pues bien, el HTTP se creó ya hace mucho tiempo (en los inicios de Internet) como un protocolo de comunicación entre universidades, por ser ahí donde nació el proyecto que más adelante sería Internet. Y por esa misma razón, cuando se diseñó, no se diseñó con la idea de que un tercero quisiera manipular las conexiones. Sencilla y llanamente, por aquel entonces, los cuatro gatos que lo iban a utilizar eran todos conocidos, y no parecía que tuviera sentido esperar que un agente fuera malicioso.
Pero claro, Internet acabó siendo lo que es hoy en día, y esos cuatro gatos ahora son prácticamente seis mil millones de usuarios. Entre todos ellos, un buen puñado (cibercriminales) que no tienen objetivos legítimos.
Con esto en mente se diseñaron las conexiones SSL o TLS, que es un añadido al HTTP convencional que, además, y aquí viene lo importante, se asegura que la conexión desde el origen hasta la fuente se haga mediante un cifrado de punto a punto.
Es decir, lo que se asegura con un SSL o TLS activo es que lo que enviemos y recibamos está cifrado (es privado). Pero ya está. Podemos estar enviando de forma privada información a una base de datos insegura. Y por el mismo motivo, podemos estar enviando de forma privada información a una página de phishing, como de hecho está ocurriendo bastante a día de hoy (los cibercriminales firman sus páginas de fraude con SSLs).
¿El HTTPs es entonces seguro o privado?
Aquí es donde viene la guinda del pastel, porque a los expertos de seguridad no se nos ocurrió otra cosa en su día que llamar al protocolo SSL «secure», que en español hemos traducido como seguridad, pero que en inglés no es exactamente lo mismo (para eso tienen «security»).
Para colmo, es cierto que antiguamente tener un SSL requería pasar, sí o sí, por un agente certificador mundial, que tenían el objetivo de validar la legitimidad de esa plataforma digital antes de concederles el SSL. Pero desde que el HTTPs pasó a ser el protocolo de comunicación por defecto de Internet, nacieron proyectos como Let’s Encrypt que te permiten autofirmar tu propio certificado con su clave, lo que quiere decir que por un lado es mucho más fácil tener un SSL, y por otro, pues que ya no cuenta con esa legitimidad de antaño.
De esta manera, durante años considerábamos «seguro» las conexiones mediante HTTPs, y así se ha traducido en prácticamente todos los navegadores, que si pinchas en ese candadito cerrado que tienes al lado de la dirección (por ejemplo cuando visitas PabloYglesias.com), te dirá que esta página es segura.
¿El problema? Pues que como decía anteriormente, el SSL no es un protocolo de seguridad. Lo es de privacidad. Y aquí vuelvo a entroncar con el tema inicial.
- Una web donde metas datos personales, como es, en este caso, la web del censo de Ecuador, si no tiene, o tiene mal implementado el SSL (como parece que está pasando) lo que nos informa es que cualquier ciudadano que entre en la web y meta sus datos, los estará enviando en texto plano, por lo que cualquier otro agente malicioso que pueda interferir en las comunicaciones (por ejemplo, si está utilizando una WiFi pública como la de un hotel, o simplemente porque le han hecho un ataque de man in the middle), podrá leer lo que está enviando y también modificarlo.
- Ahora bien, esa misma web con un SSL bien implementado lo único que asegura es que la comunicación se hace cifrada de punto a punto, de forma que si ese mismo agente malicioso está escuchando, solo verá caracteres raros que se envían de una IP a otra, y no podrá modificarlos sin que salten las alarmas.
Pero fíjate que en ambos casos, no he dicho nada de la seguridad con la que se almacenan los datos.
Incluso teniendo un SSL, puede (o no) que no se hayan tomado las medidas de seguridad oportunas, y esa base de datos, ahora o en el futuro exponga parcial o totalmente la información de todos o parte de los ciudadanos.
Es decir, que el SSL solo afecta a la privacidad de las transacciones informacionales, no a cómo estas se almacenan en el servidor.
Ahora bien, también te digo que si el SSL no lo han habilitado bien… pues habría que ver qué han hecho a nivel de seguridad. Porque ya te digo que un SSL hoy en día se instala muy fácilmente. Otra cosa es parametrizar correctamente el servidor y la base de datos para que esta sea robusta frente a potenciales agentes maliciosos.
Más aún tratándose, como se trata en este caso, de datos tan sensibles como los del censo de un país.
Que cuando hablo de estas cosas en algunas de mis charlas o formaciones siempre recuerdo lo que pasó en Holanda en los años cuarenta, y cómo debido a ese censo en el que decidieron muy lícitamente meter datos de interés religioso (para poder destinar de forma más exacta recursos presupuestarios a según qué religiones), cuando llegaron los nazis ya tenían el trabajo hecho.
El 90% de los judíos holandeses murieron en el Holocausto.
Es un caso extremo, lo sé. Pero el tema de los censos debería, a mi modo de ver, estar fuertemente segurizado. Y el que la web no tenga un SSL activo ya da mala espina.
Así que «Manuel», respondiendo a tu pregunta, sí. Lo recomendable es que ya que quizás tengas mano dentro de la Administración, comentes la importancia de que se revise la seguridad y privacidad de los datos almacenados. Para minimizar problemas hoy, pero sobre todo para minimizarlos el día de mañana.
Qué menos que, siendo un servicio público, y por tanto con el dinero del contribuyente, se gestione de forma correcta…
Una VPN minimiza el riesgo
Y mientras tanto, para evitar los problemas de privacidad, tienes la opción de utilizar una VPN, que básicamente te fuerza a que al menos la información que sale de tu dispositivo hasta el servidor VPN va sí o sí cifrada.
Es cierto que luego, esa misma información, desde el servidor VPN al servidor de la web, pues ya irá cifrada si esa web tiene un SSL bien implementado, o en texto plano si no lo tiene o lo tiene mal implementado. Pero oye, al menos los ataques de tu lado te los eliminas de un plumazo.
Imagínate recibir en tu correo semanalmente historias como esta
Suscríbete ahora a «Las 7 de la Semana», la newsletter sobre Nuevas Tecnologías y Seguridad de la Información. Cada lunes a las 7AM horario español un resumen con todo lo importante de estos últimos días.
