¿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.

 

Llevando Internet y Telefonía vía WiFi

Situación:

Zona rural en la Sierra Norte de Madrid, el punto más próximo al que se puede acceder a una línea telefónica y al ADSL está a unos 700 metros en línea recta de donde necesitamos estos servicios.

Internet móvil no es una opción dada la escasa o nula cobertura de todos los operadores, GPRS en el mejor de los casos y el mejor de los días, con tormenta o lluvia fuerte ni eso.

La otra opción es usar los servicios por satélite de Telefónica, con un coste de instalación de varios miles de euros y de varios cientos al mes de servicio, sin garantía de que vaya a funcionar bien el envío de imágenes de webcams desde el lugar a la red.

Solución, montar una red WiFi entre este sitio y una casa del mismo propietario a 700 metros.

La ventaja es que entre ambos puntos todos son pastos y no hay posibilidad de que construyan nada que obstaculice la señal, salvo dos líneas de chopos que impiden la visión directa entre ambos puntos, entre los que existe un desnivel de 14 metros.

Material empleado:

– 2 Antenas Stella Doradus 24 SD de 19 Dbi

– 2 Routers Pheenet WAP-654g de 200 mW de potencia

– 2 Cajas estancas IP55 de plástico

– 1 Router Linksys SPA2102 VoIP

– 1 Router Linksys SPA3102 VoIP

– 2 Pigtails RP-SMA a N Hembra de 60 cm.

– 30 metros de cable de red Cat 5e

– 2 mástiles de acero inoxidable

Coste del material: 355 Euros + IVA

Instalación:

Conectamos las antenas a los routers Pheenet mediante los pigtails, que quedarán alojados en las cajas estancas sujetas al mástil de la antena, el dejarlo ahí con un pigtail tan corto es para no perder demasiada ganancia en las comunicaciones.

El mástil A en la casa del pueblo incluye 10 metros de cable de red, la alimentación del router se hace mediante POE sobre el propio cable de red.

El mástil B en el punto de destino lleva 20 metros de cable de red, también con alimentación POE.

El router Pheenet del mástil A se conecta al router Linksys SPA2102 que va conectado al router ADSL de Telefónica y a la roseta de teléfono, se con figura para que deje pasar los puertos 80, 443 y 22, además de enrutar las llamadas entrantes de teléfono hasta el otro Linksys vía el router Pheenet.

El router del mástil B se conecta al switch que hay en las instalaciones, al que también se conecta el Linksys SPA3102 al que se conecta un teléfono analógico y una impresora multifunción con fax.

El SPA3102 se encarga de enrutar las llamadas salientes hasta el SPA2102 para que este las envíe por la línea telefónica.

El alineado de las antenas, a falta de visibilidad se hace de noche empleando un dispositivo laser verde de 30 mW, para solventar el problema de las dos líneas de árboles y el desnivel, la antena del mástil A apunta 30º sobre la horizontal, la antena del mástil B solo necesita 5º bajo la horizontal.

Los routers Pheenet se configuran en modo emisor-receptor con filtrado MAC, encriptación WPA2 y ocultación del SSID.

Tiempo de configuración y pruebas: 60 minutos

Instalación mástiles, etc: 120 minutos

Resultado:

Tras 2 años completos de funcionamiento, con sus 2 veranos y dos inviernos bastante extremos con temperaturas exteriores de -15ºC, se registraron fallos de conexión por mala instalación de las antenas en los mástiles que fueron movidas por fuertes vientos.

Tras la mejora de los mástiles y el realineado, los únicos fallos han sido siempre achacables a cortes de luz prolongados que dejaron las instalaciones sin servicio al agotarse las baterías de los SAI y a fallos en el servicio de ADSL de Telefónica.

Todos los productos fueron adquiridos en http://www.ciudadwireless.com a excepción de los mástiles.