jueves, diciembre 18, 2014

Google o el garante de la privacidad mundial. ¿Lo sabes?

No sé cuántos estáis al día de los movimientos de Google para implantar SDPY Proxy en el funcionamiento natural de toda la navegación web que venga en HTTP2.0. Como sabéis, aún se está discutiendo el estándar en IETF, y parte de la culpa la tiene la definición de qué y cómo hacer el cifrado de las conexiones HTTP que no están cifradas. Vamos por pasos para desgranarlo.

Figura 1: Google o el garante del privacidad mundial

Hoy en día, la guerra es tan encarnizada, que incluso la Wikipedia ha puesto una alerta sobre la posible No neutralidad de los contenidos y afirmaciones que se pueden ver en la entrada sobre HTTP2, así que lo mejor es que te hagas tu propia opinión.

Figura 2: Alerta de posible No Neutralidad en los contenidos de HTTP/2 en Wikipedia

El principio de esta historia comienza con  HTTP/1 y el funcionamiento de las conexiones HTTP y HTTPs de forma natural. En este esquema tanto, si la conexión va cifrada como si no, va desde el navegador hasta el servidor web.

Figura 3: Esquema de conexión tradicional (sin usar un Proxy HTTP) en HTTP/1

En el caso de que la conexión no vaya cifrada, entonces el contenido del tráfico puede ser visto por cualquiera que acceda a la red WiFi o a cualquiera de las redes por las que pase. Es decisión del servidor web elegir qué datos debe cifrar y cuáles no para generar un equilibrio entre privacidad y optimización, teniendo en cuenta en la parte de optimización la velocidad y el ancho de banda que es especialmente crítico en las conexiones móviles de pago.

Google, de forma individual, comenzó a desplegar SPDY Proxy, un servidor Proxy que, haciendo compresión del tráfico HTTP y cifrando la información, envía todos los datos de las conexiones HTTP sin cifrar a los servidores SPDY Proxy de Google que, después, son enviados sin cifrar por HTTP al servidor web que realmente el usuario estaba conectándose.

Figura 4: Esquema de conexión con SPDY Proxy de Google. Todo el tráfico HTTP es suyo

Es decir, que maximizando públicamente una de las características de un Servidor Proxy - la caché para hacer aceleración de navegación -, y dando una capa de cifrado en la conexión local - como hacen las VPNs -, se hace con el tráfico de los clientes. Esto no tiene que ser malo, si el usuario es consciente y tiene la opción de activarlo él manualmente, es decir, si es un Opt-in.

Quiero recordar en este punto que un Servidor Proxy, o un Servidor VPN trabajan bajo un esquema de Man in The Middle, y que con él se pueden hacer mil cosas, como ya os publiqué en "Owning bad guys {and mafia} using JavaScript Botnets" que se aprovechaba de un esquema de Rogue Proxy para ello.


Figura 5: Conferencia sobre ataques a clientes con un Rogue Proxy


Además, en el estándar HTTP existe desde siempre el concepto de HTTP Proxy Explícito, donde el usuario, al igual que con una conexión VPN, puede elegir de forma libre a qué Servidor Proxy desea conectarse, ya que a él le va a nombrar garante de su privacidad y le va a hacer entrega de la responsabilidad de velar por la seguridad de sus datos. En mi caso personal, yo utilizo solo esquemas de servidores VPN propios montados en Eleven Paths, que es de quién más me fío.

Figura 6: Servidores Proxy como addons de Google Chrome.

Con la llegada de HTTP/2, en los comités se está hablando de implantar un solución de SPDY Proxy como Opt-Out por defecto. Eso significaría que los clientes de navegación, como Google Chrome enviarían todo el tráfico de conexiones HTTP sin cifrar contra un Servidor Proxy que haría como VPN - cifraría la conexión entre el navegador y el servidor web - y de caché. La pregunta es ...¿a qué servidor?. La pregunta es importante, porque alerta cuando instalas uno de forma explícita es suficientemente clara.

Figura 7: Alerta de seguridad en Google Chrome cuando instalas un servidor Proxy

Y aquí llega la guerra, porque por defecto a día de hoy no se puede elegir. Si tu activas SPDY en tu navegador cliente Google Chrome, o si Google lo activa - como puede hacer en breve - sin decirle nada a los usurarios aprovechando su posicionamiento con Android en los terminales móviles y lo convierte en un Opt-out, entonces todo el tráfico HTTP se irá de tu navegador HTTP al SPDY Proxy de Google

Y eso es lo que se está peleando. ¿Quién debe ser el garante de la privacidad de los datos de un cliente de Internet? ¿Debe ser Google? ¿Deben dejar los gobiernos que esto pase así después de las filtraciones de Edward Snowden sobre las prácticas de la NSA? ¿Deben nuestros gobiernos en Europa decir algo? ¿Debe ser consciente el usuario de en qué compañía confía y poder elegir a qué servidor HTTP2 PROXY desea conectarse?


Figura 8: Diapositiva de PRISM en la NSA filtrada por Edward Snowden

En mi opinión, lo ideal sería un esquema como el siguiente, donde el usuario pudiera decidir quién debe ser el garante de la privacidad de sus conexiones. Mozilla Firefox y Opera ya han anunciado que no van a poner como Opt-out, sino como Opt-in cualquier implementación de HTTP/2 en conexiones HTTP sin cifrar por medio de un Servidor Proxy, pero Google no tiene esa opinión, y si lo hace aprovechando la cuota de mercado de Android y de Google Chrome en OSX, Windows, Linux e incluso iOS, podría hacerse con casi todo el tráfico mundial HTTP.

Figura 9: Un esquema deseable con elección

Eso significaría que Google se llevaría a sus servidores, sin que muchos usuarios lo sepan, una buena cantidad de datos que a día de hoy no ve, y que de seguro le daría una posición dominante en nuevos servicios, en optimización de sus recursos, en competitividad, etcétera. Eso sí, todo vestido de que su objetivo es "la privacidad del usuario". ¿Tú qué opinas? ¿Deben ser ellos los garantes de la privacidad mundial?

Saludos Malignos!

11 comentarios:

  1. Tal y como yo lo veo, lo que está tratando de potenciar Google es el uso de HTTPS.

    Por un lado, anunció que iba a favorecer en su buscador a los servidores que usan https
    http://googlewebmastercentral.blogspot.com.es/2014/08/https-as-ranking-signal.html

    Por otro lado recientemente han anunciado intenciones de marcar explícitamente como inseguras las conexiones http.

    https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure

    Por lo tanto, a medida que se extienda el uso del https, su proxy deja de perder sentido porque no creo que se planteen interceptar el tráfico cifrado.

    Evidentemente el uso del cifrado end-to-end hace que los operadores de red intermedios pierdan la visibilidad y esto es algo que seguro Google conoce bien. Controlan gran parte del software de cliente y sus servicios son usados masivamente (Youtube, Gmail, buscador, ...) , con lo que se quedan con un control muy grande sobre la información que fluye por ellos.

    ResponderEliminar
  2. Whaat?

    Pero que pelicula te has montado?

    Que proxy, mitm ni historias?

    Te has molestado en mirar que es el protocolo spdy siquiera?

    Cada vez os pareceis mas a las escenas de csi hackeando con la gui de visual basic

    Spdy esta soportado hace siglos en chrome por defecto y hace no mucho en firefox, anda echale un ojo al spdy de nginx antes de decir tanta chorrada peliculera, no es mas que forzar ssl y gzip con ajustes tcp.

    ResponderEliminar
  3. @anonimo 2 no te has enterado bien, tronco. Hay un spdy proxy para servidores web sin spdy. Lee más.

    Saludos!

    ResponderEliminar
  4. "Google" y "privacidad", en una misma frase es algo que suena demasiado a chiste.
    Bastante complejo es eliminar la maraña de "servicios" y configuraciones incrustrados de Google (incluyendo la imposición de sus DNS por defecto con el wifi en DHCP) en todos los telefonos android y sin perder la garantia del fabricante por obtener acceso root. ¿Neutralidad? Una maquinaria tan engrasada para obtener por activa y por pasiva cualquier tipo de información de los usuarios (nada es gratis), no deberia siquiera contemplarse como un interlocutor valido para implementar estandares de ningun tipo. Es como si un banco dejara en manos de un caco la elección del mecanismo de apertura de su caja fuerte.

    ResponderEliminar
  5. Al Maligno le salta la vena "maligna" cuando detecta a un "troll" en sus comentarios }:)

    ResponderEliminar
  6. Sin embargo hay algo que no me cuadra de todo esto, según la documentación http://www.chromium.org/spdy/spdy-proxy-examples el Proxy no es más que un MITM para el trafico HTTP (y una pequeña parte para el HTTPS) es decir, si queremos saber el origen del trafico de algun incidente veremos la IP del proxy de Google, no la de nuestro cliente, eso puede generar incidentes de seguridad en pequeñas páginas. Como podemos controlar eso? acuerdate que hay muchos sitios e-commerce que permiten el pago a través de un tercero que si usa HTTPS, eso es cierto en mi país por ejemplo, y donde se tumben el sitio del e-commerce, es complejo saber como se hizo si todo pasara por un proxy

    ResponderEliminar
  7. Tan sencillo como No usar google. Si es por buscadores...

    ResponderEliminar
  8. Un nuevo sub mundo nace, en donde los consumidores de información llegaran a google, como siemrpe, y los "conocedores" buscaran alternativas de conexión. Apoyo la opinión de Mozilla.

    ResponderEliminar
  9. El proxy SPDY de Google se activa con la opción de "Reducir uso de Datos"en el Chrome del móvil.
    No afecta a las conexiones HTTPS.
    Cuando el servidor soporta SPDY nativamente (Twitter, facebook, Proxy) la conexión se hace directamente sin usar el proxy.

    Para conocer la IP real del cliente en el servidor final, hay que mirar la cabecera "X-Forwarded-For" que el proxy añade.

    Aquí hay más información
    https://support.google.com/chrome/answer/3517349?hl=es

    Saludos.

    ResponderEliminar
  10. Y esto que es bueno o es malo Dr?
    Salu2!

    PD: Fortifica el filtro anti trol Chema ;-)

    ResponderEliminar
  11. Hay un spdy proxy para servidores web sin spdy

    Debe ser que estoy muy espeso (he leido la expecificación HTTP/2, no la de spyd). Si un servidor web no ha habilitado HTTP/2, dificilmente se conseguirá las carecterísticas de multiplexado y compresión mediante la introdución de un servidor proxy, porque al fin y al cabo ese servidor proxy se contectará igualmente al servidor web y este seguirá sin soportar HTTP/2.

    Además, en HTTP/2 no recuerdo haber leido nada acerca de un proxy.

    ResponderEliminar