parches iterativos

Leía el otro día el artículo publicado por Chema sobre HKPK (ES/HTTPs Public Key Pinning por sus siglas).

En él profundizaba, por supuesto, en este protocolo, y en las razones de por qué los principales navegadores de la actualidad han decidido dejar de soportarlo.

Los parches que han dado sentido al sistema de comunicación de Internet

Básicamente la historia de los protocolos de comunicación en entornos digitales ha sido la siguiente:

  • HTTP: El protocolo base (por simplificarlo mucho) que nos está permitiendo que ahora mismo tú puedas estar leyendo este artículo publicado desde España, y alojado 24/7 en un servidor europeo.
  • HTTPs: Puesto que HTTP se concibió en un principio como un protocolo para comunicarse entre iguales (en principio académicos de varias universidades estadounidenses), todo lo que se compartía se hacía en texto plano, es decir, abierto a que cualquier otro interesado pudiera verlo. Algo que parece perfecto para un entorno cerrado como el inicial de Internet, pero que ha demostrado ser profundamente inseguro para el Internet de la actualidad, en el que conviven tanto usuarios «buenos» como cibercriminales. Así que se le incluyó al HTTP un túnel SSL para que las comunicaciones, al menos mientras estuvieran en tránsito (desde que salen del dispositivo emisor y hasta que llegan al servidor o dispositivo receptor), estuvieran cifradas.
  • HSTS: El mundo parecía muy bonito con el HTTPs, pero entonces nos dimos cuenta de que el HTTP sigue funcionando, y que de hecho es posible forzar la comunicación por HTTP pese a que la comunicación, a priori, se haga mediante el HTTPs. ¿La solución? Otro nuevo parche, llamado esta vez HTTP Strict Transport Protocol o HSTS, que como su propio nombre indica fuerza a que sí o sí la comunicación se haga por HTTPs… o de no ser posible, no se haga.
  • HPKP: Otro momento dulce… hasta que nos dimos cuenta de que una comunicación con HSTS o HTTPs puede hacerse tanto hacia un servidor legítimo, como ilegítimo. Que, de hecho, el SSL solo asegura la privacidad de la comunicación, no su legitimidad. Y para solventarlo, otro parche, basado esta vez en el Certificate Pinning y el HTTP Public Key Pinning o HPKP por sus siglas, en el que ya no solo forzamos a que la comunicación se haga mediante HTTPs (HSTS, ya sabes), sino que además esa «carta» se tiene que enviar única y exclusivamente a este servidor. El mismo que tiene este certificado en particular.

¿Todo perfecto, verdad? Pues no. Tanto por potenciales errores en tiempos de ejecución (por algo la informática no es una ingeniería…), como por las posibles tergiversaciones que puedan realizar terceros a las cabeceras HTTP, es posible comprometer el HPKP.

Y lo peor de todo es que si comprometemos el HPKP, podemos dejar perfectamente y durante horas o días (hasta que caduque el certificado, vaya) un servicio inaccesible. No porque en efecto no lo esté, sino porque esos parches de seguridad que en su día implementamos están bloqueando por defecto cualquier intento de comunicación.

Es decir, Que gracias a esta medida de seguridad… se compromete la seguridad e integridad ofrecida por otras capas de la comunicación. Que en el afán de segurizar mejor las comunicaciones con parches iterativos, HKPK anula en según qué escenarios parte del camino conseguido anteriormente, añadiendo de paso mayor complejidad.

La iteracción informática frente a la robustez de los sistemas

Lo estaba leyendo y el tema me recordó muchísimo a esos «efectos secundarios» de un sistema tan aparentemente perfecto (a nivel de seguridad) como es el doble factor de autenticación.

El principal problema que tenemos actualmente con la identidad digital del usuario es lo fácil que resulta «robar» las credenciales de acceso. Basta con que se comprometa la seguridad de un servicio para que se vuelque su base de datos, y esos pares usuario/contraseña se prueben en diferentes servicios, cayendo de paso muchísimas más cuentas.

¿Y a qué se debe esta debilidad? A que el sistema de verificación de identidad que históricamente hemos utilizado en entornos digitales es uno basado en el conocimiento (yo puedo loguearme en esta cuenta porque SÉ mi usuario, que puede ser público, pero también mi contraseña, que es privada). Un conocimiento que, por su propia ideosincrasia, supone de facto un tipo de riesgo global (ya no es necesario que alguien nos ate de pies y manos y nos torture para obtener la contraseña, sino que simplemente se vulnere el servicio que la almacena y de ahí obtenerla).

Conocido el problema, por tanto, ¿qué podemos hacer?

Pues creamos el segundo factor de autenticación, o lo que es lo mismo:

Que además de tener que SABER mi usuario/contraseña, si me conecto desde un dispositivo distinto, me pida confirmación de que soy yo a otro dispositivo que TENGO.

Añadimos de esta manera a esa verificación basada en el conocimiento, una segunda verificación basada en la posesión (yo demuestro que soy yo porque TENGO acceso a un dispositivo al que le va a llegar un código), como explico en profundidad en el Curso sobre Seguridad y Privacidad Digital.

¿Te preocupa tu Seguridad y Privacidad Online?

He diseñado este curso online en 8 módulos en el que cubriremos todos los fundamentos de la ciberseguridad, ayudándote paso por paso a configurar la seguridad y privacidad de tus cuentas digitales y de tus dispositivos.

Un nuevo parche, y otra vez vuelta a empezar. Porque ese segundo factor de autenticación funciona a las mil maravillas…, siempre y cuando las tripas de ese sistema estén bien segurizadas. Cosa que ya te adelanto que no es así.

De esta manera, descubrimos que un tercero puede usurpar nuestra identidad frente al operador de telecomunicaciones, haciéndose con el control de la SIM de nuestro dispositivo de segundo factor de autenticación, y transformando ese segundo factor de un riesgo local (tenían que robarnos el móvil además de saber nuestra contraseña para hacerse con el control de nuestras cuentas) a uno nuevamente global (no hace falta que nos roben físicamente, sino que cualquier persona en cualquier parte del mundo con información suficiente puede jodernos).

Así que toca sacar otro parche, y esta vez ha sido el del doble factor de autenticación basado en token. Ya no es un SMS que depende de la operadora, sino un código que se nos envía por una aplicación que sí o sí tiene que estar instalada de antemano en nuestro smartphone.

Una sucesión de parches y parches para mejorar la seguridad de nuestra identidad digital que, de pronto, somos conscientes de que en algunos escenarios específicos deja totalmente bloqueado el acceso a nuestra identidad. Algo tan sencillo como que extraviémos nuestro smartphone y tengamos que utilizar otro dispositivo para encontrar nuestro smartphone nos deja, en el caso de iOS/MacOS y como contaba no hace mucho, totalmente vendidos.

Da igual que en efecto seamos nosotros (y podamos demostrarlo tanto por conocimiento como a nivel fiscal), que puesto que ese entorno digital va cifrado de punto a punto y está creado para operar estrictamente de una manera en base a los sucesivos parches de seguridad que le hemos ido metiendo, hemos sido expulsados de nuestra identidad digital.

Y el corolario de todo esto es que bajo estas situaciones las medidas de seguridad pasan a ser un lastre que desincentiva su uso. Justo lo que de hecho tendríamos que evitar.

Así de complejo es el sistema informático de nuestro mundo. Una sucesión de parches tras parches que añaden complejidad al sistema, en base, lamentablemente, a sacrificar algunas veces la propia usabilidad y funcionalidad del mismo.

Actualización: Dos días más tarde he publicado un artículo en el que explico cómo podríamos mejorar la manera de mostrar de forma más segura una URL, que viene precisamente a colación de lo comentado por aquí.

________

¿Quieres conocer cuáles son mis dispositivos de trabajo y juego preferidos?

Revisa mi setup de trabajo, viaje y juego (ES).

Y si te gustaría ver más de estos análisis por aquí. Si el contenido que realizo te sirve en tu día a día, piénsate si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.