Parafraseando el título del artículo que escribimos en agosto de este mismo año, en el que hablábamos de aquella foto en la que las comunicaciones a servicios web (primero páginas, después cualquier conexión a internet) se hicieran todas mediante protocolo seguro, volvemos hoy al ataque con lo que sería el segundo gran movimiento en favor de una red más privada.
Recapitulemos un poco. Hace algo más de dos meses, Google anunciaba que próximamente empezaría a considerar que un servicio ofreciera a sus usuarios conexiones SSL/TLS como una variable más de cara al posicionamiento del mismo en su buscador. En aquel momento, generamos un intenso debate, tanto por esta página como por Google+, sobre la importancia del movimiento y qué papel (qué porcentaje, más bien) jugaría esta nueva variable en el peso global para el SEO de un blog, un servicio que por lo general (quitando grandes medios de comunicación) se hace de forma asimétrica y sin apenas exposición de datos por parte de los lectores (a lo sumo los metadatos de comunicación que un lector entrega junto al envío de un comentario).
El movimiento, al menos para un servidor, era el acertado. Si alguien podía forzar comunicaciones seguras con un llamamiento mundial ese sin duda era Google. Y lo hacía de una forma magistral: No es algo obligatorio, pero que sepáis que empezaremos a priorizar en nuestro algoritmo las webs con HTTPs frente a las que mantengan el HTTP.
Ahora, un grupo de grandes empresas de internet, entre las que figuran la EFF y Mozilla, lanzan Let’s Encrypt (EN), una iniciativa con la que se plantea ofrecer certificación TLS open source (EN/enlace roto) de forma gratuita a cualquiera que tenga un dominio propio a partir del segundo cuatrimestre del 2015.
La noticia es terriblemente importante, y de ahí que haya preferido levantarme un poco antes esta mañana (por cierto, que vaya semanita llevo entre viajes y reuniones) para escribirla antes de ponerme en camino.
Hablamos de que por primera vez en la historia, un nuevo organismo ofrecerá la logística necesaria para habilitar conexiones seguras a cualquier demandante, y de forma gratuita. Y aquí empiezan las dudas.
Como sabrá, SSL y su evolución TLS son dos protocolos encargados de cifrar las comunicaciones que se hacen por un canal tan diverso e inseguro como HTTP. Como explicaba en el artículo Los tres grandes problemas de seguridad de la WWW, HTTP nació en su día como un canal de comunicación “privado”, en tanto en cuanto se utilizaba para comunicaciones conocidas: “Yo llamo a este porque lo conozco”. Con la expansión de internet, se hizo cada vez más habitual hacer peticiones de comunicación a nodos desconocidos, y pasamos de una red que utilizaban unas pocas universidades a una red que es pilar fundamental de todo el sistema socio-económico del planeta.
Como HTTP no ofrecía garantías, se superpusieron protocolos seguros. Primero SSL, y después TLS, que son protocolos que corren por encima, como si de un parche se tratara.
Con las filtraciones de Wikileaks y sobre todo, después de lo que se ha llegado a denominar la era Post-Snowden, nos adentramos en un entorno en el que esa internet insegura y pública ha dejado de ser algo hasta cierto punto aceptable. El cliente ahora demanda privacidad en sus comunicaciones, y la privacidad tiene varios costes:
- Por un lado, enviar paquetes cifrados reduce la velocidad y aumenta el gasto de procesado en las comunicaciones. Para que una comunicación viaje cifrada, el emisor tiene que ponerse de acuerdo con el receptor de antemano sobre qué método van a usar (conexiones extras igual a más gasto de ancho de banda igual a más demora en el envío), debe cifrar el contenido (gasto de recursos de computación) y enviarlo al receptor (mayor peso por paquete), que tendrá que hacer el proceso contrario. Todo esto puede llegar a engordar unos milisegundos el tiempo de espera, algo crítico para entornos que requieren o bien inmediatez (imaginemos sistemas SCADA que controlan el flujo de una centrifugadora nuclear) o bien no cuentan con recursos de sobra (se me viene a la mente algunos wearables en forma de anillo, pendiente o pin que podrían encontrarse con un problema debido a su escasa capacidad de procesamiento).
- Por otro lado, la manera que a todos se nos viene a la mente de aplicar cifrado a las comunicaciones sería mediante un cambio en HTTP, de manera que este mantuviera la retrocompatibilidad y de paso fuera él quien gestionara las comunicaciones seguras. Esto es muy complicado (y lento) de aplicar. Hablamos de una estandarización que revolvería toda la estructura de la red hacia algo sin lugar a duda diferente. Existe también un punto medio, que viene de la mano de ese HSTS, un protocolo seguro que está en la mesa de la WWW desde hace ya un tiempo, pero en todo caso, no llegará ni mañana ni dentro de tres años. Por último, tenemos TLS, y SSL, protocolos que se basan en la confianza de un certificado emitido por una figura de autoridad para todos (una empresa certificadora). Esto son trámites (se supone que esa entidad certificadora velará y auditará que toda web con su certificado en verdad es legítima) y por tanto, hasta ahora, era un servicio de pago periódico (igual que comprarse un dominio o pagar un hosting, aunque bastante más caro).
Así es como llegamos al motivo de mis dudas ¿Cómo gestionar de forma gratuita la certificación TLS para todos los administradores de servidores que así lo requieran? Se habla de patrocinios, y ya veremos de qué tipo de patrocinios estamos hablando (espero que no intenten meternos publicidad en la parte visible del certificado, esa que aparece justo al lado de la URL en la caja de búsqueda del navegador).
¿Cómo van a simplificar la implantación de un certificado TLS? Porque para quien no lo sepa, implantarlo no es algo tan sencillo como darle a instalar y listo. Requiere que alguien con conocimientos técnicos evalúe la compatibilidad del servidor y de las herramientas que utilizas. Requiere seguramente instalar módulos extras, cambiar la configuración de los dominios para que apunten de forma correcta utilizando SSL y un par de pasos extras para según qué servidor.
Y todo ello teniendo en mente que el protocolo seguro no es la panacea, que SSL en este año ha sido vulnerado mínimo tres veces (Heartbleed, POODLE y la reciente en servidores Windows), y que si ya de por sí existe fraude de entidades certificadoras, ni me quiero imaginar cómo van a gestionar esto sin que se les vaya de las manos.
Un paso necesario, sí. Un paso muy pero que muy acertado. Pero que en todo caso impone contramedidas a problemas específicos (posibles escuchas en conexiones a WIFIs públicas, MITM,…), no al problema raíz. Porque lamentablemente para solucionar este no vale con instalar un certificado. Se precisa del compromiso de toda la cadena arquitectónica que forma la WWW (desde los usuarios, por cierto). Y eso es algo muy complicado de conseguir.
En todo caso, se agradece, y seguiremos la evolución de Let’s Encrypt con interés.
