Protege tu identidad digital protegiendo tus claves de acceso

Con demasiada regularidad estamos asistiendo al robo de las bases de datos de usuarios de empresas más o menos conocidas.

El último caso ha sido el robo de miles de cuentas de correo en Yahoo, aunque esta vez no haya sido debido a un fallo de seguridad por su parte, sino a que los atacantes han empleado los datos conseguidos en el ataque a otra compañía.

El robo de cuentas en Yahoo ha sido gracias a los propios usuarios, que han usado la misma clave para acceder a su email como al servicio comprometido de donde sacaron sus credenciales de acceso, una práctica demasiado habitual.

Las primeras recomendaciones son siempre las mismas, usa diferentes claves para cada servicio, crea claves complicadas que no se puedan descubrir mediante ataques de diccionario.

12345678, password, iloveyou, admin son una constante en las listas de las claves más usadas por los usuarios.

Usar frases de canciones o libros ha dejado de ser una buena idea desde que existen proyectos que recopilan ebooks para incluirlos en diccionarios de crackeo de passwords.

Y mucho ojo con el servicio para recordar claves que ofrecen muchas webs, ¿como se llamaba tu primera mascota? ¿como se llamaba tu primer profesor? Este es otro punto débil en la protección de contraseñas, es preferible usar una cadena ilegible (y que podremos guardar en alguna de las herramientas que veremos) a cualquier dato real o palabra normal.

La mejor solución, además de usar una clave diferente en cada servicio, es usar claves muy largas y absolutamente ininteligibles como wXxZkkf>M|O5rqG}oU»~LcCn<lC*P!`l1Ew^ o Lu8TeJi.4dF=rjwq=dBPsI$b:5.>:{«{d!, pero es un problema recordarlas, además confiar en como las almacena nuestro navegador web también puede ser un problema.

Para solucionarlo existen multitud de aplicaciones y servicios on-line, vamos a ver como usar un par de ellos y las medidas de seguridad que implementan.

Lastpass

Lastpass es un servicio on-line (y la opción más cómoda de las que vamos a ver) que nos permite guardar todas nuestras claves en un depósito cifrado, está disponible para Windows, Linux y Mac y con soporte para los navegadores web más usados, Chrome, Internet Explorer, Firefox y Safari, con auto rellenado de formularios de login, y más opciones bastante interesantes como importar nuestras claves almacenadas en el navegador web (recuerda borrarlas luego desde la configuración de tu navegador) o el Reto Lastpass, el cual analizará tus actuales claves, valorará su seguridad, si están repetidas y tu posición en el ranking de usuarios con mejores claves.

Incluye un generador de passwords fuertes como las mostradas anteriormente y tan sólo necesitaremos usar una clave maestra para poder descifrar el depósito de claves. Podemos asegurar un poco más el depósito empleando identificación en dos pasos con Google Authenticator.

El servicio es gratuito, salvo que tengamos pensado usar nuestras claves en dispositivos móviles, en cuyo caso tendremos que adquirir una cuenta premium, que tiene un coste de $1 al mes, un precio bastante razonable.

Esta empresa afrontó en 2011 un fallo de seguridad con transparencia y la posterior implementación de medidas para asegurar el servicio sin ninguna incidencia reseñable hasta la fecha.

Además del uso de identificación en dos pasos con herramientas como Google Authenticator, Lastpass incluye el algoritmo de generación de clave derivada PBKDF2 para proteger nuestra clave principal contra ataques de fuerza bruta (por si nos roban el depósito de claves cifrado de nuestro ordenador, por ejemplo).

Lo habitual es cualquier servicio web es que nuestra clave se almacene con algún tipo de cifrado a partir de la clave que hemos tecleado, con mejores medidas de seguridad o peores como sucedió con la filtración de usuarios y claves de la web de Adobe.

Empleando PBKDF2 nuestra clave es introducida en un bucle, en cada ciclo, la clave se vuelve a cifrar hasta el número de rondas que hemos seleccionado. Esto hace que cuando nos identificamos el sistema tarde un tiempo apenas perceptible en hacer login, pero ante un ataque de fuerza bruta, obliga al atacante a ejecutar ese bucle por cada clave que quiera probar contra nuestra clave almacenada, dificultando que descubran nuestra clave maestra, aunque no haciéndolo imposible.

Configuración PBKDF2 de LastPass. 5.000 rondas son las recomendadas, aunque permiten hasta 200.000, lo cual hace mucho más lento el login, más seguro y de paso problemático en dispositivos móviles

Configuración PBKDF2 de LastPass. 5.000 rondas son las recomendadas, aunque permiten hasta 200.000, lo cual hace mucho más lento el login, más seguro y de paso problemático en dispositivos móviles

 

También tenemos la opción de que sólo se permita el acceso desde determinados países, evitar el acceso desde Tor, incluso seleccionar que dispositivos móviles y ordenadores están autorizados a acceder a la cuenta.

Tras empezar a usar esta herramienta, es importante ir visitando las webs en las que tenemos cuenta y cambiar las claves y las preguntas de recordatorio por unas nuevas que se irán actualizando en nuestro depósito de claves.

Generando un clave segura desde Lastpass

Generando un clave segura desde Lastpass

Conviene pasar el reto Lastpass de vez en cuando para ir mejorando la calidad de las claves empleadas e ir cambiando las duplicadas en diferentes servicios.

Las aplicaciones para dispositivos móviles de la versión de pago consisten en una app para Android y otra para iOS.

La primera permite consultar usuarios y claves, además de disponer de su propio teclado con el que pegar esos datos en, por ejemplo, Chrome para Android.

La versión para iOS trae embebido un navegador web en el que la aplicación puede rellenar automáticamente los campos de login en el mismo modo que lo hace el plugin para navegadores web de ordenador de sobremesa.

Por seguridad conviene sacar de vez en cuando una copia de seguridad de nuestras claves almacenadas en Lastpass, nunca se sabe cuando un servicio on-line puede perder todos sus datos o cerrar la empresa que lo ofrece.

Para esta copia de seguridad es interesante emplear una aplicación como la que vamos a ver a continuación, ya que es capaz de importar perfectamente el archivo de volcado generado por Lastpass y las almacena de manera segura.

Keepass

Keepass no es un servicio on-line como Lastpass (en este enlace está la versión traducida a español de la aplicación), se trata de una aplicación desarrollada sobre la plataforma .NET y que dispone de versiones para Windows, Linux y MacOS. También existen multitud de aplicaciones compatibles para Android e iOS que nada tienen que envidiar a las de Lastpass.

Existen 2 ramas de esta aplicación la 1.x y la 2.x, ambas siguen desarrollándose, aunque la segunda dispone de mejores opciones de seguridad y herramientas como disparadores y scripts que nos puede ser de utilidad para tareas como mantener un backup de nuestra base de datos de claves.

Para instalar la aplicación en Windows es necesario tener antes instalado Microsoft .NET Framework 2.0 o superior, todos los equipos con Windows Vista, 7, 8 u 8.1 lo tienen por defecto.

En Linux es necesario instalar antes Mono, aunque si instalamos directamente el paquete Keepass2 disponible en los repositorios de Debian y Ubuntu, el instalador se encargará de resolver las dependencias e instalar los paquetes de Mono necesarios. En algunas versiones de Ubuntu puede dar problemas al ejecutarse que se solucionan instalando el paquete mono-complete.

En MacOS debemos instalar Mono y Xquartz, los paquetes y las instrucciones están aquí. Hay otra opción más cómoda y rápida, adquirir Kypass por poco más de 5€ en la Mac App Store, compatible con los plugins para Keepass 2 que necesitaremos para poder hacer login de manera cómoda desde nuestro navegador web.

Al no tratarse de un servicio on-line nos encontraremos que es un poco más complicado compartir nuestras claves entre diferentes dispositivos. Para este caso vamos a usar dos, Google Drive y Dropbox, aunque también podemos usar cualquier otro servicio de almacenamiento en la nube que nos permita usar el protocolo WebDAV, como OwnCloud o iDriveSync, el uso de dos diferentes a la vez es importante para nuestro propósito, almancenar las claves de manera segura.

Teniendo instaladas las aplicaciones de sincronizado automático de Google Drive y Dropbox, ejecutamos KeePass 2 y creamos nuestra primera base de datos.

El primer dato que nos pide es el nombre de la base de datos y donde la queremos almacenar. Seleccionaremos la carpeta que sincroniza Google Drive.

El segundo paso es seleccionar nuestra clave maestra, la que va a proteger todas nuestras claves.

Si bien existen plugins para usar sistemas de identificación en dos pasos con Google Authenticator, si pretendemos usar esa base de datos desde app móviles nos vamos a encontrar con un problema.

Para garantizar un alto nivel de seguridad y que al mismo tiempo la base de datos sea 100% compatibles con otras aplicaciones, además de usar una clave larga y segura, emplearemos un archivo de clave que generaremos desde la propia aplicación Keepass 2.

Seleccionando nuestra clave y el archivo con la clave de cifrado para mayor seguridad de la base de datos.

Seleccionando nuestra clave y el archivo con la clave de cifrado para mayor seguridad de la base de datos.

 

Durante la generación de dicha clave la aplicación nos pedirá mover el ratón sobre una imagen y teclear en un campo de texto, cuyo contenido no es necesario recordar y que se usa como complemento para generar entropía y que la clave sea más fuerte que usando sólo el generador de números aleatorios que trae el propio sistema operativo.

Captura de pantalla de 2014-02-02 12:03:45

Finalizado este proceso, se nos pedirá que indiquemos donde queremos guardar el archivo resultante. Este lo almacenaremos en la carpeta de Dropbox, nunca en la misma que está el archivo de la base de datos, o perdería sentido su función.

También es posible que en lugar de subirla a otro servicio en la nube, la pasemos por usb a nuestro dispositivo móvil o bien la llevemos en un pendrive para usarla en otros ordenadores desde los que queramos tener acceso a nuestra base de datos.

Es muy importante tener una copia de seguridad de ambos archivos, tanto de la base de datos como de este archivos que acabamos de generar, si perdemos cualquiera de los dos archivos, habremos perdido todas nuestras claves.

Realmente ya tenemos una copia local en las carpetas de sincronizado de Google Drive y Dropbox, sólo si usamos dos servicios webdav estarán fuera de nuestra máquina esos dos archivos y será más importante tener esa copia de seguridad.

Al igual que Lastpass, cuando introducimos nuestra clave esta pasa por un algoritmo de generación de claves derivadas que cifra la clave de la base de datos pasando la clave tecleada por una función SHA-256 junto con el contenido del archivo que acabamos de generar, repitiendo este proceso tantas veces como rondas de este proceso hayamos decidido que use la aplicación.

En la pestaña Seguridad de la configuración de nuestra base de datos podemos modificar el número de rondas, estableciendo este valor en 1500000 tan solo notaremos que cargar y grabar los cambios en la base de datos son un poco más lentos, unos pocos segundos tantos en PC de sobremesa como dispositivos Android e iPhone/iPad.

Es igual que el sistema usado por Lastpass para dificultar el ataque por fuerza bruta contra nuestra base de datos, con el añadido de tener nuestro archivo de clave separado, esto vuelve virtualmente imposible romper nuestra clave.

Instalado y funcionando llegó el momento de instalar los plugins para Chrome o Firefox, En la lista veréis otros para Internet Explorer, Opera… seguid las instrucciones de esos plugins para instalarlos.

En el caso de los dos plugins para Chrome y Firefox, necesitaremos añadir también un plugin a la propia aplicación Keepass 2, el KeepassHTTP, descargando el archivo KeePassHttp.plgx de aquí y copíandolo en la misma carpeta en la que está instalado Keepass 2 en nuestro equipo:

c:\archivos de programa\keepass2 en Windows

/usr/lib/keepass2/plugins/ en Linux

Cerramos la aplicación y la volvemos a ejecutar para que compile el plugin instalado, en el menú Tools aparecerá al final la opción KeePassHttpSettings.

Captura de pantalla de 2014-02-02 12:06:53

En la primera pestaña podemos desactivar la primera de las opciones, nos ahorraremos una notificación en pantalla cada vez que el plugin solicite una clave a Keepass, en Advanced podemos desactivar que nos pida permiso cuando se pide acceso a una clave para una página por primera vez.

Con KeePassHttp funcionando, podemos pedir desde el plugin en el navegador web que se empareje con este plugin, para lo que generará una clave de identificación única que quedará guardada en nuestra base de datos, esto es para evitar que cualquier malware que haya infectado nuestro ordenador pueda ponerse a pedir datos a KeePassHttp de manera indiscriminada.

Con esto terminado, podemos proceder a ir visitando las webs en las que tenemos cuenta e ir cambiando nuestras claves por algo más complicado, el propio plugin irá modificando los datos en nuestra base de datos, así como añadiendo nuevos registros para las webs en las que nos demos de alta a partir de ahora.

Generador de claves de Keepass

Generador de claves de Keepass

 

En cuanto a las aplicaciones para dispositivos móviles, en Android hay varias compatibles, la más cómoda de usar que he encontrado es KeepShare, aunque no es gratuita.

Nos permite cargar la base de datos desde Google Drive y el archivo de clave desde Dropbox o desde un archivo almacenado en local.

Para facilitar el acceso a las claves puede substituir nuestra clave maestra por un PIN de bloqueo… úsalo bajo tu propia responsabilidad.

Una de las funcionalidades que trae, al igual que la app Android de Lastpass, es su propio teclado, cuando seleccionamos en KeepShare que usuario/clave queremos usar, este se copia en el teclado, facilitando la introducción de los datos en el navegador.

Screenshot_2014-02-02-20-28-13

 

Una vez finalizado, podemos borrar del portapapeles los datos.

En iPhone/iPad disponemos de la app Kypass 3, la cual nos permite también cargar desde Google Drive la base de datos y la clave desde Dropbox.

photo

 

Ambas app permiten cargar los datos también desde otros servicios WebDAV, así como ajustar los tiempos de timeout, el tiempo máximo que deben permanecer las credenciales copiadas en el portapapeles, timeout de clave maestra, etc.

Por supuesto que existen más aplicaciones, servicios on-line y maneras de encarar su uso, me he limitado a elegir uno de los más conocidos y aparentemente seguros de cada tipo cuya instalación y operación resulte sencilla para cualquier usuario de ordenadores.

Si usas otras aplicaciones o servicios on-line comparte en los comentarios tu experiencia con ellos, información de seguridad, etc.

¿Es el protocolo seguro HTTPS realmente seguro? Lecciones que nos deja Snowden, la NSA y Lavabit

A estas alturas la gente anda ya un poco saturada de las filtraciones que nos va facilitando The Guardian sobre los papeles que Edward Snowden sacó de la NSA.

Aunque hay muchos y diversos temas sobre los que hablar a partir de estos papeles, me gustaría centrarme en este post en el tema del cifrado de las comunicaciones por Internet, principalmente en el protocolo de comunicación seguro para la web HTTPS, el que nos debería proteger cuando hacemos transacciones con nuestro banco, leemos el correo en Gmail, etc. cifrando desde nuestro usuario y contraseña, a los datos que enviamos o recibimos.

Desde el punto de vista del usuario medio, el HTTPS es eso que hace que aparezca un candado de color verde al lado de la dirección de la web en nuestro navegador.

ssl-gmail

ssl-santander

Algún usuario más avispado se habrá fijado que en algunas webs, además de aparecer el candado en verde indicando una presunta conexión segura, también pueden ver una pastilla con información de verificación del nombre de la empresa que ha solicitado el certificado de seguridad para esa web.

ssl-fastenal
ssl-deutschebank

 

Básicamente, esta pastilla con información sirve para verificar que estás realmente entrando a Deutsche Bank y no a una falsificación.

¿Es más segura la web de Fastenal (una cadena de cientos de ferreterías en EE.UU) que el Gmail de Google?

¿Es más segura la de Deutsch Bank que la del Santander que no dispone de esa información?

No necesariamente.

Más allá de la seguridad del servidor que almacena estos certificados, tema que daría para unos cuantos posts, vamos a centrarnos en la parte de la seguridad de las comunicaciones.

Confiar en que el candado verde significa que nuestras comunicaciones son seguras es un error que poca gente sabe que está cometiendo.

Ese candado tan solo nos informa de que el sitio web al que nos estamos conectando usa un protocolo de cifrado de datos y que el certificado que usa es correcto, ni ha caducado, ni está revocado y lo firma una autoridad certificadora de confianza.

Como se esté empleando luego el certificado seguro para cifrar el tráfico HTTPS es otra cosa bien diferente.

En la parte menos visible nos encontramos con que existen varios protocolos sobre los que se sustenta HTTPS: SSL versión 2, SSL versión 3, TLS versión 1.0, TLS versión 1.1, TLS versión 1.2

Dentro de estos protocolos tenemos diferentes métodos de cifrado, de establecer la comunicación segura entre el servidor y tu navegador, opciones para comprimir o no el tráfico HTTPS.

Aquí es donde verdaderamente reside la seguridad, en los protocolos y métodos de cifrado que se le han configurado al servidor para poder abarcar todos o la mayoría de los navegadores web del mercado ofreciendo la máxima seguridad posible.

Una de las enseñanza de Snowden es que la NSA y otros organismos afines almacenan durante un tiempo indeterminado la información cifrada con vistas a poder descifrarla en el futuro.

Esto puede suceder de varias formas, que el sistema de cifrado sea antiguo o débil, que se encuentre un nuevo fallo que permita adivinar la clave de cifrado o romperla, o que el FBI pida una orden judicial para que el propietario del servidor entregue el certificado y llave de cifrado.

Esto le ha sucedido al dueño de Lavabit, donde Snowden tenía su dirección de correo electrónico. Aunque el certificado se revocó en cuanto la información salió a la luz, el daño ya estaba hecho, gran parte de la información que pudiera tener el FBI almacenada, podría ser descifrada con facilidad gracias a esa orden del juez y a que Levison tuvo mal configurados los métodos de cifrado de las comunicaciones del servidor bastante tiempo.

¿Se podría haber evitado? Sí, utilizando una propiedad de los sistemas de cifrado llamada Forward Secrecy, que he visto por ahí traducida como «secreto hacia adelante», a mi me suena mejor «confidencialidad futura».

Forward Secrecy es lo que anunciaba hace poco Google como novedad en su sistema de cifrado HTTPS que ya funciona para las comunicaciones con Gmail.

Para no liarnos demasiado con que es Forward Secrecy, la diferencia fundamental de usarla o no en las comunicaciones radica en que con FS, cada sesión que tengamos con el servidor, genera una clave nueva que se destruye al terminar la sesión, es decir, que no hay manera de que pase lo que ha pasado con Lavabit.

Sin FS el cifrado recae en el certificado y la llave del servidor, que son datos registrados en el sistema de almacenamiento de la máquina y que pueden ser solicitados por el juez.

Cierto es que si el juez está bien asesorado puede pedir al dueño del servidor que guarde una copia de todas las claves de sesión, pero todo el tráfico de datos HTTPS anterior no se podría descifrar teniéndolo almacenado como hizo el FBI en el caso Lavabit.

Con esta información estamos en disposición de responder a la primera pregunta:

¿Es más segura la web de Fastenal (una cadena de cientos de ferreterías en EE.UU) que el Gmail de Google?

La respuesta es un estrepitoso NO aunque visualmente la de Fastenal nos parezca más válida.

La realidad es que aunque ambos usan certificados de seguridad de confianza, Gmail implementa mejor los protocolos, así como las combinaciones de cifrado y negociado de claves entre el servidor y el cliente.

De hecho Fastenal sólo es capaz de ofrecer una combinación de cifrado sobre un servidor muy mal configurado que permite realizar ataques Man-In-the_Middle de tal manera que un atacante puede inyectar información en el contenido cifrado de la transmisión sin demasiada dificultad; aunque limitado a no poder recibir la respuesta, el atacante puede enviar peticiones con las credenciales de la víctima.

Gmail en cambio no solo no es vulnerable a este fallo (ya un poco viejo) sino que implementa Forward Secrecy en las comunicaciones cifradas, una capa más de seguridad para ponerle las cosas difíciles a los «amigos de lo ajeno», lo cual incluye a la NSA y demás sucedáneos nacionales e internacionales.

Con los bancos mencionados pasa lo contrario, Deutsche Bank, además del certificado con validación de empresa, cuenta con mejor cifrado que el Santander, aunque ambos cumplen con los requisitos mínimos para obtener el certificado PCI que viene a ser una garantía sobre la seguridad de las transacciones realizadas en esa web.

Por si todo esto de los diferentes tipos de cifrados no fuese suficiente, de vez en cuando aparecen noticias como esta en la que el servicio secreto francés ha usado a la entidad certificadora del Departamento del Tesoro para falsificar los certificados de varios dominios de Google y que los navegadores web no alertasen al usuario sobre el uso de una entidad certificadora no reconocida.

Que si era para vigilar a sus empleados, que si fue por un error, un descuido, el perro se comió mi clave privada… La cascada de excusas es la habitual cuando se pilla a todo un gobierno haciendo un ataque MitM empleando recursos que deberían ser confiables.

Google ya revocó esos certificados en su navegador Chrome, y ya hay en marcha varios proyectos para tratar de evitar que esto se repita, de momento sólo nos queda tener los ojos abiertos, ya que no sólo podemos ser víctimas de este ataque por parte de un gobierno junto con su entidad certificadora reconocida, también es posible que un desconocido ataque nuestra máquina y nos imstale un certificado propio como de confianza para poder descifrar nuestras comunicaciones basadas en SSL.

 

El CDN de Telefónica NO rompe la neutralidad de la red

Escribo esto a raíz de este artículo en El País y este otro en Público que imagino que han redactado a partir de alguna noticia de agencia y usan el sensacionalismo en lugar de documentarse en condiciones.

Telefónica comienza a ofrecer un servicio de CDN (Content Delivery Network) para los proveedores de contenidos como Google, Facebook… o cualquier otra empresa que quiera contratarlo.

Esto para ambos medios es el fin de la neutralidad de la red, para ellos se trata de una red «VIP»…

Voy a tratar de no ser muy técnico para que todos podamos entender como funciona la red, que es una CDN y por qué estas no rompen la neutralidad de la red.

Internet está conformada por millones de nodos interconectados.

Dichos nodos puede ser los routers de nuestro proveedor de acceso que tenemos en casa, switches, servidores, etc.

Cuando desde Madrid (pon aquí la ciudad en la que vives), en nuestro navegador web escribimos www.facebook.com, nuestra máquina pregunta a los servidores de DNS la dirección IP de esa URL que hemos escrito, algo como 69.171.224.39 que es la dirección que identifica a www.facebook.com en la red.

Esto es como querer llamar a Paco (Facebook) y tener que mirar la guía telefónica (DNS) para saber que teléfono debemos marcar (dirección IP)

Una vez que nuestro navegador web sabe a que IP debe dirigirse, comienza el viaje por Internet, de nuestro ordenador a nuestro router (sea wifi o no), de nuestro router al enlace con el primer nodo de nuestro proveedor, que al ver que es una IP de Norte América, nos deriva a otro nodo de nuestro proveedor que enlaza con nodos internacionales.

Este nodo nos envíe a otro nodo en Londres o Amsterdam que es por donde pasan las grandes redes de fibra óptica transoceánica, este otro nodo internacional envía nuestra petición hasta Nueva York, de ahí pasamos por otros 3-4 nodos ya en suelo estadounidense, hasta llegar a un nodo en Seattle que finalmente entrega nuestra petición a los servidores web de Facebook, que nos devuelve la información necesaria para ver la página en nuestro ordenador.

Este proceso puede suponer que desde Madrid a Seattle hayamos pasado por unos 20 nodos de Internet.

Cada nodo, en función de lo saturado de peticiones de los millones de usuarios que tiene la red, tarda más o menos en tramitar nuestra petición, desde 1 milisegundos que tarda nuestro router en recibir la petición, a los 30-40 milisegundos, hasta los 200-300 milisegundos que tardan los nodos internacionales mucho más cargados de trabajo.

(Estos datos son de ahora mismo probando con mi conexión ADSL de Movistar contra www.facebook.com, pueden variar dependiendo de la web que queramos cargar y el proveedor de acceso que tengamos).

La suma final de tiempos es de 2.300 milisegundos, es decir, que la petición ha tardado 2.3 segundos en llegar a Facebook.

Si repetimos el proceso con un diario nacional como www.elmundo.es que tiene sus servidores en España, tenemos que en lugar de tener que pasar por 20 nodos, pasamos por apenas 5 nodos con un tiempo total de 223 milisegundos, 0,223 segundos

Aclarado el concepto de los nodos, ¿que es una CDN?

Una CDN es una red de servidores distribuidos en diferentes localizaciones (ciudades, países) que contienen copias de datos de otros servidores (www.facebook.com por poner un ejemplo).

Cuando un servicio de contenidos como Facebook hace uso de un servicio de CDN, lo que logra es que los datos que antes nos costaban 2.3 segundos en ir pasando por los 20 nodos de la red hasta llegar a ellos en sus servidores de Estados Unidos, se conviertan en muy pocos al estar la copia de los datos en un servidor que está en el mismo país desde el que te estás conectando.

Si extrapolásemos esto al mundo real, es como si Facebook abriese una oficina filial en España. Si quieres ir a verles, tardas menos en llegar a su filial en España que tener que ir hasta Estados Unidos a su sede central.

De hecho hay muchas empresas que hacen uso de redes CDN, que esto no lo ha inventado Telefónica…

Existen empresas con servidores repartidos por todo el mundo formando CDN muchísimo más grandes que la que está poniendo en marcha Telefónica, la más conocida es Akamai cuya CDN usa desde hace mucho tiempo www.elpais.com.

¿Por qué esto no rompe la neutralidad de la red?

El concepto de neutralidad en la red es que toda la información que circula por ella tiene el mismo valor y no se prioriza el tráfico de un proveedor de contenidos sobre el resto.

Volviendo a extrapolarlo al mundo real, todos podemos caminar por las calles sin que nadie tenga prioridad de usar una acera sobre el resto de caminantes, si alguien nos mandase parar para que pasase antes otra persona, entonces si que se estaría rompiendo la neutralidad.

Pero en este caso, la CDN no estaría parando a unos para dejar pasar a otros, tan solo se limita a acortar la distancia entre el usuario y el destino al que va a solicitar datos (una web, su email, etc)

Esto tampoco significa que al final Telefónica se salga con la suya y consiga que los proveedores de contenidos como Google o Facebook tengan que pagar obligatoriamente por usar sus redes como se menciona en estas noticias.

Telefónica está ofreciendo un servicio de proximidad a los proveedores de contenidos, por el que obviamente tendrán que pagar si voluntariamente deciden contratarlo.

¿Que gana un proveedor de contenidos usando un servicio de CDN, sea el de Telefónica, Akamai, Level 3, Edegecast o cualquiera de las decenas de CDN disponibles en el mundo?

Gana proximidad al usuario, las webs cargan más rápido y se mejora la experiencia de uso.

Gana que reduce el consumo de ancho de banda de sus servidores centrales

Gana que ante posibles incidentes en sus servidores centrales, las webs se seguirán sirviendo (como ejemplo el caso de la web del PSOE cuando fue atacada hace meses mediante un ataque de denegación de servicio, los servidores centrales sucumbieron pero la web siguió en marcha gracias a que usan la CDN de Akamai).

Resumiendo, que ambas noticias son falsas, totalmente sacadas de contexto buscando el sensacionalismo con una falta de conocimientos y rigor periodístico terribles.

Bonus:

Si eres usuario del ADSL de Movistar notarás que por las tardes la carga de los vídeos de Youtube es infinitamente más lenta.

Eso es debido a que el ancho de banda que tiene Movistar contratado contra Youtube es muy bajo, y cuando mucha gente trata de conectarse a ver vídeos, la red se satura y se vuelve lenta.

Un truco para mejorar la velocidad de carga es cambiar los DNS de tu proveedor de ADSL por estos de RedIris:

193.145.66.2

193.146.141.130

Resulta que Google está instalando de manera gratuita servidores en lugares como RedIris y diferentes ISP para montar una especie de CDN propio que mejore la experiencia de uso de sus servicios (incluyendo Youtube)

Al usar estos dos DNS de RedIris, al hacer una petición a Youtube, nuestra solicitud será enviada al servidor que Google ha instalado en RedIris en España en lugar de a los servidores centrales de YouTube, con lo que la carga de los vídeos mejora de una manera brutal.