Estos días me han preguntado por Twitter, a colación del anuncio, por parte de Google (EN), mis impresiones al respecto de que Chrome ya tenga planificado un timing para acabar «matando» el HTTP tradicional.
Es, de facto, un tema del que llevo hablando muchos años, y que pese a que plantea serios retos (y algunos puntos negativos), dibujará un escenario digital más seguro del que venimos.
La cruzada de Google contra las conexiones en texto plano
Por si no sabe de qué hablo, lo resumo rápidamente.
Cuando nosotros nos conectamos a una página o servicio bajo conexiones HTTP convencionales, toda la comunicación que hacemos con ese servidor se realiza en texto plano, es decir, sin cifrado de ningún tipo.
Lo cual permite que cualquier agente entre el emisor (nosotros) y el receptor (el servidor de esa página o servicio) pueda leer, e incluso modificar o eliminar parte de esos paquetes, viéndose comprometida nuestra privacidad y por supuesto, también la del receptor.
De ahí que frente a este protocolo, que ha sido base de lo que entendemos por Internet estas últimas décadas, surge el HTTPs, que no deja de ser un protocolo HTTP con una capa de cifrado, de tal manera que cualquier comunicación que hagamos bajo éste irá cifrada bajo una seguridad específica (dependiendo del SSL que competa a cada conexión).
Hasta ahí todo genial.
La mayoría de grandes servicios de Internet, y sobre todo, aquellos que requieren compartir datos críticos (como puede ser un servicio de pago, una red social, un ecommerce, una aplicación de contactos…) han ido paulatinamente adoptando el HTTPs como protocolo de comunicación por defecto.
Pero… ¿Tiene sentido que un blog, o en definitiva, cualquier servicio digital cuyo único cometido es servir la misma información a cada usuario, implemente HTTPs?
Sí y no. Me explico.
Junto al HTTPs actual, la mayoría de servidores implementan el llamado HTTP/2, que es la evolución del HTTP, un protocolo que recuerdo tiene casi 20 años de antigüedad. Y como ya expliqué en su momento, HTTP/2 ofrece una serie de mejoras en cuanto a la velocidad de carga que como cabría pensar son muy interesantes para cualquier servicio digital (mientras menos latencia, mejor).
Además, es raro ya que una página, por sencilla que parezca, no tenga algún que otro elemento que de una u otra manera compromete la privacidad del usuario. Bastaría por ejemplo tener habilitado un formulario de contacto, una sección de comentarios, el script de Analytics o publicidad (ergo, scripts de monitorización), para que en efecto esa página que a priori no trabaja con información crítica del visitante sí esté, de una u otra manera, comprometiendo la privacidad del mismo.
Bajo este prisma, considerando el abuso que durante estos últimos años se ha hecho al tráfico de datos personales, y en vista de que hoy en día resulta prácticamente imposible controlar por completo el ámbito de monitorización de un proyecto digital expuesto en la red, la salida más adecuada pasa por considerar que el protocolo de comunicación por defecto en Internet no es el HTTP, sino el HTTPs.
Cosa que además (y esto es lo que me parece más interesante) acabará por llegar también en aquellas webs con SSL cuya seguridad no esté asegurada. Es decir, aquellas webs que aún teniendo SSL puedan estar siendo usadas en campañas de phishing o fraude cibernético.
Un movimiento muy inteligente, que rema precisamente hacia esos derroteros en los que la seguridad no debe depender del usuario, sino de la tecnología. Que el usuario, como he defendido recientemente, debe dedicarse a disfrutar de ésta, y no a preocuparse de ella.
Además, en la entrevista (EN) que Wired le hizo estos días a Parisa Tabriz (directora del «Department of chromeland Security» de Google), y que recomiendo leer encarecidamente, Tabriz explica al detalle la importancia que ha tenido el estudio de la señalética utilizada hasta ahora para definir la seguridad web.
Que el uso de ese icono gris de información no ha cumplido las expectativas esperadas por la compañía (servir de alerta soft de la exposición en texto plano de todo lo que compartimos con ese servidor), y que después de hacer pruebas con decenas de iconos distintos, han encontrado en el «Not secure» la mejor manera de definir algo tan abstracto como es la privacidad.
Un cambio que entraña algunos «pero» a considerar
Pero claro, una cosa es decirlo, y otra muy distinta llevarlo a cabo.
Como bien señalan en la entrevista, implantar HTTPs en una página o servicio no es algo tan sencillo como apretar un botón y listo.
O mejor dicho, ponerlo en marcha es tan sencillo como apretar un botón (según el SSL, bueno), pero hacer que esa página o servicio funcione bajo HTTPs es otro tema. Algo que he vivido en carnes propias (ya ni hablemos a nivel de clientes :P) cuando a principios de año me decidí a dar el paso en esta humilde morada, y cuyos problemas iniciales arrastré varios meses después.
Por poner algunos ejemplos, Wired anunció en abril (EN) que iba a pasar su web a HTTPs, y solucionar todos los problemas asociados al cambio les llevó 5 meses (EN). El New York Times hizo lo propio (EN) en noviembre del 2014, y a fecha noviembre del 2016 no tiene aún una versión completa en HTTPs.
A esto hay que unirle la esperable reticencia al cambio que esgrime un sector considerable de la industria. Implementar un HTTPs es costoso, ya sea por los recursos necesarios para ponerlo en marcha, o por su propia contratación. Iniciativas como Let’s Encrypt, que por cierto es el que tengo implementado en PabloYglesias.com, han democratizado el acceso a estos certificados, pero sigue siendo algo que tiene que hacer un administrador de sistemas con conocimientos medios/altos de desarrollo.
El que durante años, aquellos que nos dedicamos a la seguridad hayamos utilizado el candadito verde de la barra de navegación como síntoma de que esa web era segura es otro impedimento más. Porque en su día, y descontando casos de hackeos como el que en su momento afectó a uno de los certificados de la propia Google (EN), acceder a un certificado estaba solo al alcance de proyectos legítimos (ninguna entidad certificadora se iba a jugar el cuello con un servicio claramente ilegal), y aunque ese candadito solo señale que la comunicación con la página se hace bajo HTTPs, también podía servir para discriminar entre páginas legítimas e ilegítimas. Algo que hoy en día no compete. Una campaña de phishing puede contar perfectamente con un certificado propio que lo mismo es tomado por válido en el navegador de la víctima.
Y para terminar, habría un último punto negativo. El que hasta cierto punto este cambio de paradigma rema en contra de todos aquellos proyectos que aún estando actualmente abandonados, siguen aportando valor a la sociedad. Con este movimiento, Google discriminará en un futuro las páginas con HTTP frente a las que hayan dado el paso a HTTPs. Un protocolo que recuerdo requiere en la práctica acudir a una serie de certificados específicos (mayor centralización), para detrimento de aquellas webs que bien sea por principios, bien sea por abandono, bien sea por falta de recursos y/o conocimiento, no implementarán HTTPs.
Un Internet un pelín más centralizado. Algo que vivimos en su día con la necesidad de validar servidores de correo (hasta entonces cualquiera podía montarse un servidor de correo en su ordenador y despachar emails sin ser marcado como spammer), con el desarrollo y distribución de productos de software lejos de los actuales markets de aplicaciones (y sin que el propio sistema operativo nos marque como potencialmente dañinos).
Un paso así conlleva hándicaps a considerar, claro está. Pero recalco: después de ese periodo de adaptación, y a sabiendas de lo que vamos a dejar atrás (tanto lo bueno como lo malo), el nuevo escenario se me antoja más seguro y privado.
También más centralizado y menos flexible, sí. Pero siempre vamos a tener que sacrificar algo.
________
Si le gustaría ver más de estos tutoriales y análisis por aquí. Si el contenido que realizo le sirve en su día a día, piense si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.
