El futuro Chrome ide­n­ti­fi­ca­rá a las páginas sin ce­r­ti­fi­ca­do de seguridad

En un artículo de su blog sobre seguridad Google ha co­m­pa­r­ti­do sus planes futuros de ide­n­ti­fi­car de forma explícita a las páginas en HTTP en su navegador. Con este objetivo, la versión 56 de Chrome, prevista para enero de 2017, verá su barra de di­re­c­cio­nes levemente mo­di­fi­ca­da con el aviso “Not secure” (no segura), que ide­n­ti­fi­ca­rá a di­re­c­cio­nes URL de páginas sin ce­r­ti­fi­ca­do de seguridad. Está previsto que las primeras webs afectadas sean aquellas que tra­n­s­fie­ren datos bancarios y de registro con el protocolo HTTP (sin cifrado). A co­n­ti­nua­ción exa­mi­na­mos los si­guie­n­tes pasos previstos hasta su completa im­pla­n­ta­ción y evaluamos sus co­n­se­cue­n­cias para pro­pie­ta­rios de páginas web y usuarios.

Si Chrome 56 aparece a pri­n­ci­pios de 2017 tal y como está planeado, el sello “Not secure” afectará al principio a las di­re­c­cio­nes de aquellas páginas que utilizan el protocolo de tra­n­s­fe­re­n­cia HTTP para trasmitir datos de pago y co­n­tra­se­ñas. Hasta ahora, el navegador no ide­n­ti­fi­ca­ba de forma explícita a las páginas que no protegían las tra­n­s­fe­re­n­cias de datos con un ce­r­ti­fi­ca­do TLS y SSL. Lo único que las ide­n­ti­fi­ca hasta ahora es la falta del símbolo verde que, en cambio, sí aparece a la izquierda de la barra de di­re­c­cio­nes en el caso de páginas pro­te­gi­das. Este indicador tan neutral pasa des­ape­r­ci­bi­do para la mayoría de usuarios de Internet, como ha de­mo­s­tra­do un estudio llevado a cabo en conjunto por Google y por la Uni­ve­r­si­dad de Ca­li­fo­r­nia. Las futuras versiones de Chrome traerán consigo una am­plia­ción co­n­ti­nua­da de los tipos de avisos de seguridad. En una posible segunda etapa, el sello “Not secure” ide­n­ti­fi­ca­ría a las páginas HTTP en el modo privado (incógnito), modo usado sobre todo por aquellos usuarios con grandes preo­cu­pa­cio­nes en torno a la seguridad en la web. Según la in­fo­r­ma­ción di­s­po­ni­ble en su blog, Google también estaría pensando, no obstante, en una ide­n­ti­fi­ca­ción general de todas las páginas sin ce­r­ti­fi­ca­do, también en el modo estándar. Con toda pro­ba­bi­li­dad, se uti­li­za­ría para ello el triángulo rojo que ya sirve para marcar las páginas HTTPS mal co­n­fi­gu­ra­das.

Ya en agosto de 2014, Google anunció que el cifrado de la tra­n­s­mi­sión de datos con SSL o TLS también sería relevante a la hora de evaluar las páginas en el marco de la seguridad general de la web. De esta manera se quería motivar a los pro­pie­ta­rios de páginas web para que se ocuparan de la ce­r­ti­fi­ca­ción de su proyecto. Teniendo en cuenta que hoy el cambio a HTTPS es mucho más económico y sencillo, es fácil de entender por qué en los dos últimos años ha aumentado el número de webs pro­te­gi­das con ce­r­ti­fi­ca­do. Ahora, la nueva ofensiva de Google supone poner en marcha la fase decisiva, difícil de esquivar hasta para los ad­mi­ni­s­tra­do­res de las páginas más am­bi­cio­sas y es que alrededor de dos tercios de los usuarios a nivel mundial utilizan Chrome para navegar, una tendencia en aumento según datos es­ta­dí­s­ti­cos de w3schools.

Cuando los usuarios visitan una página web, por lo general no se limitan a leer un artículo. La de­no­mi­na­da huella digital no es solamente el resultado del rastreo mediante cookies y he­rra­mie­n­tas de se­gui­mie­n­to. Cada vez con más fre­cue­n­cia, el usuario pro­po­r­cio­na sus datos de forma to­ta­l­me­n­te co­n­s­cie­n­te en sus apo­r­ta­cio­nes en las redes sociales y en foros o cuando el uso de una página requiere re­gi­s­trar­se, ya sea para recibir un boletín o porque está vinculado a una cuenta de usuario. En muchos casos se requiere in­tro­du­cir la dirección de correo ele­c­tró­ni­co, pero en otros se revela in­fo­r­ma­ción más sensible.

Por defecto, el navegador entrega esta in­fo­r­ma­ción (co­n­tra­se­ñas, datos de usuario, bancarios o postales) a la base de datos en el servidor uti­li­za­n­do el protocolo de tra­n­s­fe­re­n­cia de hi­pe­r­te­x­to o HTTP, un protocolo que ha sido de gran utilidad hasta ahora desde los inicios de la web, pero que no permite cifrar la in­fo­r­ma­ción que tra­n­s­po­r­ta. Esto significa que todos los paquetes de datos que se envían desde el navegador al servidor web con una conexión HTTP y que, en este camino, son su­s­ce­p­ti­bles de ser “espiados”, figuran en texto plano. Los ci­be­r­cri­mi­na­les pueden de esta manera acceder sin problemas a datos de registro de una cuenta de correo, a una cuenta de banca online o a la dirección privada del usuario. Aplicando un ce­r­ti­fi­ca­do SSL/TLS, los pro­pie­ta­rios de páginas web ga­ra­n­ti­zan el trasporte cifrado de la in­fo­r­ma­ción y su pro­te­c­ción ante terceros.

Como la gran mayoría de la comunidad de usuarios de Internet no parece haber re­co­no­ci­do aún el si­g­ni­fi­ca­do de la ce­r­ti­fi­ca­ción SSL/TLS para proyectos en la web, Google se propone, con Chrome 56, entrar en la siguiente ronda de ex­pli­ca­cio­nes. Con la re­no­va­ción completa de su sistema de ide­n­ti­fi­ca­ción, Google quiere se­n­si­bi­li­zar a más usuarios en relación con la tra­n­s­fe­re­n­cia cifrada de datos y obligar a actuar a ad­mi­ni­s­tra­do­res y pro­pie­ta­rios web con una laxa co­n­cie­n­cia en cuanto a seguridad hasta ahora. Los cambios pro­gra­ma­dos dejan intuir que se logrará el objetivo, haciendo que los usuarios dejen de acceder a páginas marcadas con este ide­n­ti­fi­ca­dor.

Google podría también tener más en cuenta en el futuro el factor de ranking HTTPS en la eva­lua­ción de las páginas. Mientras que los usuarios de Chrome obtienen un elemento adicional de seguridad, los pro­pie­ta­rios de páginas web ya no tendrán que evaluar si el ce­r­ti­fi­ca­do de seguridad es necesario o no. Los ad­mi­ni­s­tra­do­res web no deberían esperar a la ac­tua­li­za­ción de comienzos de 2017 para cambiar a HTTPS, sino que, como pasa a menudo, cuanto antes, mejor.