Inicio / Blog / SPDY: ¿más rápido y más seguro?

SPDY: ¿más rápido y más seguro?

Publicado el 16/07/2014, por Jesús Díaz (INCIBE)
SPDY: ¿más rápido y más seguro?

La versión actual del protocolo HTTP (HTTP/1.1), el principal mecanismo de transmisión de información en Internet, data de 1999. Por entonces, era difícil prever la evolución que iba a seguir Internet, por lo que este protocolo fue diseñado sin tener en mente el volumen y tipo de información manejado por las páginas web actuales. Esto hace que su eficiencia no sea precisamente la mejor posible para los sistemas de hoy en día.

Con la intención de promover una mayor eficiencia, y de paso mejorar la seguridad, Google anunció a mediados de 2009 que estaba trabajando en el protocolo SPDY. Al verse las ventajas que ofrecía SPDY, desde el HTTP Working Group se decidió trabajar en el sucesor de HTTP/1.1, la versión 2.0 o HTTP2 tomando como punto de partida el protocolo SPDY de entre varios candidatos.

En esta entrada haremos una breve review de SPDY, el protocolo que ha actuado como catalizador de HTTP2, con énfasis en sus implicaciones sobre la seguridad y privacidad en Internet.

Principales características

En realidad, SPDY no sustituye HTTP, sino que añade una capa adicional (como se muestra en la siguiente figura, extraída del whitepaper de Chromium sobre SPDY) para permitir enrutar múltiples flujos de comunicación a través de una misma conexión TCP.

capas_spdy

Además de hacer obligatorio el uso de TLS, SPDY aumenta la eficiencia de las comunicaciones gracias a las siguientes características:

  • Al utilizar una única conexión TCP por dominio a través de la cual se enruta toda la información intercambiada con dicho dominio, minimiza la sobrecarga introducida por el 3-way handshake de TCP.
  • Permite especificar una prioridad para las distintas peticiones de recursos, lo cual evita el problema de Head-of-Line blocking.
  • Comprime todas las cabeceras HTTP, lo cual reduce notablemente la cantidad de datos transmitidos.
  • El servidor puede mandar información al cliente (PUSH), sin que éste la haya solicitado antes. Esto permite que, si el servidor sabe que el cliente necesitará un recurso determinado, se ahorren los costes de tener que realizar la petición.
  • Las cookies sólo son retransmitidas en caso de que su valor haya cambiado con respecto a la última vez que se enviaron.

Impacto sobre la seguridad y privacidad

Para comprender cómo afecta a la seguridad y privacidad de los internautas una adopción masiva de SPDY, hay que conocer las distintas opciones de despliegue. No obstante, en resumen, la seguridad proporcionada por SPDY es prácticamente la misma que en el caso de utilizar TLS para todas las conexiones.

Para el despliegue de SPDY es necesario el soporte tanto por parte de clientes como de proveedores de servicio. En el lado de los clientes, es suficiente con implementar el protocolo SPDY en los navegadores típicos (tarea que ya han llevado a cabo Chrome, Firefox, Opera, Internet Explorer, Silk y Safari).

Por parte de los servidores, tanto si se utilizan proxies entre el cliente y el servidor (balanceo de carga, filtrado de tráfico, etc.) como si la conexión es directa entre ambos, el uso de SPDY conlleva las implicaciones derivadas de utilizar TLS en todas las comunicaciones. Es decir, la información estará cifrada en todo momento. No obstante, para facilitar el despliegue de SPDY, también es posible introducir proxies SPDY que posteriormente se encarguen de establecer las conexiones necesarias con los servidores de destino (que podrán ser SPDY o no). Pero, ¿qué implicaciones tienen estos proxies?

Proxies SPDY y proxies HTTPS

Para comprender mejor cómo se establecen conexiones a través de un proxy, mostramos el flujo de mensajes que tiene lugar en caso de utilizar proxies y servidores HTTPS frente al que tiene lugar al utilizar sus equivalentes SPDY. El caso de HTTP se ignora ya que, como es obvio, HTTP sin TLS no es comparable a SPDY en cuanto a la confidencialidad y autenticidad de la comunicación. Para simplificar los diagramas, una vez realizada una negociación TCP o TLS, dejamos implícito que los siguientes mensajes de capas superiores son encapsulados en dichas sesiones.

Proxy HTTPS

 

Proxy SPDY

Como es lógico, el proceso es similar para ambos casos. Toda la información entre cliente y proxy, y entre proxy y servidor, está protegida con TLS. Además, la segunda sesión TLS se establece punto a punto entre cliente y servidor (aunque pase por el proxy), por lo que el proxy no tendrá acceso a la información que éstos intercambien. El proxy si tendrá, en ambos casos, acceso a la metainformación de dicha conexión (IPs de ambos, certificados en caso de enviarse, etc.). Si, por el contrario, la conexión entre cliente y proxy se realizase mediante HTTP (ni HTTPS ni SPDY), los datos que estos intercambien serán visibles para cualquiera que monitorice la conexión. Igualmente, si el servidor sirve el recurso con HTTP plano, cualquiera (incluyendo al proxy) podrá leer su contenido.

Por lo tanto, es importante destacar que el uso de SPDY no ofrece ninguna distinción en cuanto a seguridad o privacidad con respecto a los casos en los que HTTPS ya está instaurado en todas las posibles conexiones. Además de que SPDY requiere que la versión de TLS utilizada sea compatible con NPN, el resto de diferencias, no apreciables en las figuras anteriores, son las derivadas de las nuevas funcionalidades proporcionadas por SPDY (multiplexación de conexiones, prioridades, compresión, etc.). No obstante, esto no tiene un impacto directo en la seguridad (al comparar con HTTPS), más allá de la que pudiera derivarse del cambio de patrón de las transmisiones.

Por último, volver a resaltar que cuando se utiliza un proxy, naturalmente, el servidor de destino verá la IP del proxy en lugar del cliente, por lo que creerá estar hablando con el primero (salvo, probablemente, cuando el cliente presente un certificado). Esto ocurre tanto para proxies HTTP, como proxies HTTPS y proxies SPDY.

Calidad de servicios y open proxies

Google ha puesto en marcha un proxy abierto (para los usuarios de Chrome en Android e iOS) para optimizar las transferencias web. Esto tiene como consecuencia, por ejemplo, que Google dispondrá de más información sobre las conexiones establecidas por los usuarios que activen dicha opción. Además, en caso de que muchos usuarios adopten esta alternativa, los patrones de comunicaciones globales también se verán afectados, creciendo notablemente el tráfico que pase por los proxies de Google. Esta funcionalidad se puede activar o desactivar (en Android 4.4.4) desde la aplicación de Chrome, en: Ajustes > Gestión del ancho de banda > Reducir uso de datos.

Proxy Google

 

Reducir uso de datos

De la misma forma, el uso de proxies puede afectar a la calidad de ciertos servicios basados en la IP del cliente, como anuncios basados en geolocalización por IP (utilizados por ejemplo por CDNs), debido a que la IP visible será la del proxy. También, las reglas de filtrado en firewalls que se basen en la información transmitida, no serán aplicables en proxies intermedios (sí en los proxies que estén bajo el control del servidor final), al estar protegida por una sesión TLS establecida punto a punto.

Pero, como hemos dicho, esto no es una consecuencia de usar SPDY, sino del uso de proxies.

Implantación

Viniendo de Google, SPDY está recibiendo bastante atención. Como ya se ha comentado, todos los navegadores principales lo soportan, y también hay varios servicios importantes compatibles con este protocolo. Según la entrada de la Wikipedia para SPDY, páginas como Twitter, Facebook y Wordpress ya lo han desplegado en sus servidores. Además, entre los principales productos compatibles con SPDY para tecnología de servidores web, están Jetty, F5 Networks, NGINX, Apache, CloudFlare o MaxCDN.

No obstante, según W3Techs, SPDY no está aún muy extendido, estando implantado aproximadamente entre el 0,3% y el 1% de los servidores web entre el 1 de julio de 2013 y el 1 de julio de 2014.

Para saber si una web tiene activo SPDY, sin necesidad de capturar y analizar tráfico, se puede usar el servicio spdycheck.org, o la extensión SPDY indicator (disponible para Chrome, Firefox y Opera), que muestra el siguiente icono en la barra de direcciones en caso de que el sitio web que se visite desde el navegador usa SPDY:

SDY Indicator

Evidentemente, para usar SPDY, también hay que tenerlo activo en el navegador. En Firefox se puede consultar si lo está entrando en about:config y buscando la clave network.http.spdy.enabled (o simplemente spdy, para además ver qué valores hay relacionados con el protocolo), que tendrá que estar activo. En Chrome, desde chrome://net-internals/#spdy se puede ver si está activo y, además, consultar información sobre las conexiones que lo utilizan o han utilizado:

 

Conexiones SPDY en Chrome.

SPDY viene activo por defecto en Chrome, y para desactivarlo, hay que especificar --use-spdy=off al invocar el navegador.

Conclusiones

En resumen, en cuanto a eficiencia, SPDY parece proporcionar importantes mejoras (cerca del 60% en algunos casos), aunque parece haber escenarios en los que dichas mejoras son menores, como en comunicaciones móviles (donde baja al 23%).

En cuanto a la seguridad y privacidad de sus usuarios, las consecuencias son las derivadas de hacer obligatorio el uso de TLS. Es decir, toda la información viajaría siempre cifrada. Por otra parte, en caso de utilizarse proxies que no estén controlados directamente por quienes proporcionen el servicio al que se quiere acceder, como en el caso de Google para Android e iOS, estos proxies podrán deducir directamente los hábitos de navegación de quienes los utilicen y, en caso de acceder a páginas que no estén protegidas con TLS, también ver los contenidos de la comunicación. No obstante, hay que destacar que esto no es una consecuencia de SPDY, sino del uso de proxies con la intención de facilitar la implantación de SPDY.

Por último, SPDY no es HTTP2, sino que se ha utilizado como base para el mismo. Entre ellos hay varias diferencias. Quizá la más importante, en lo que a eficiencia se refiere, sea que HTTP2 permite “multiplexar” conexiones con varios hosts a través del mismo stream. En cuanto a seguridad, en HTTP2 no es obligatorio el uso de TLS.

Etiquetas: