A estas alturas de la película, no es noticia que Facebook haya abierto una 'sucursal' dentro de TOR
creando su propio 'hidden service' accesible a través de TOR, aquí cabe
decir que esto no significa que antes no se pudiese conectar a Facebook
desde TOR, el matiz está en que ahora Facebook tiene un site 'puro' dentro de TOR.
Dejando a un lado los matices sobre privacidad, si tiene sentido o no el
movimiento, y en general esa clase de análisis que no me parecen
relevantes (en este blog), me gustaría hablar de la parte puramente
técnica.
Cualquiera que haya usado Tor y se haya conectado a un 'hidden service'
sabe que las URLs suelen ser todo menos bonitas o fácilmente
memorizables, así que, de entrada, llama mucho la atención el nombre que
han conseguido para su site en Tor: facebookcorewwwi.onion
En Tor, las URLs cumplen una función que va mas allá de ser un bonito y
descriptivo nombre, las URLs sirven para autenticar un nodo dentro de la
red.
si le damos un vistazo a las especificaciones del protocolo:
1.5. Alice receives a z.onion address.
When Alice receives a pointer to a location-hidden service, it is as a
hostname of the form "z.onion", where z is a base32 encoding of a
10-octet hash of Bob's service's public key, computed as follows:
1. Let H = H(PK).
2. Let H' = the first 80 bits of H, considering each octet from
most significant bit to least significant bit.
3. Generate a 16-character encoding of H', using base32 as defined
in RFC 4648.
(We only use 80 bits instead of the 160 bits from SHA1 because we
don't need to worry about arbitrary collisions, and because it will
make handling the url's more convenient.)
When Alice receives a pointer to a location-hidden service, it is as a
hostname of the form "z.onion", where z is a base32 encoding of a
10-octet hash of Bob's service's public key, computed as follows:
1. Let H = H(PK).
2. Let H' = the first 80 bits of H, considering each octet from
most significant bit to least significant bit.
3. Generate a 16-character encoding of H', using base32 as defined
in RFC 4648.
(We only use 80 bits instead of the 160 bits from SHA1 because we
don't need to worry about arbitrary collisions, and because it will
make handling the url's more convenient.)
Podemos ver que esas URLs tan 'feas' en realidad son una brillante forma
de autenticar sitios en Tor ya que la parte 'fea' que va a la izquierda
de un dominio .onion es, en realidad, una parte del hash SHA-1 de la
clave pública del servicio, de esa forma, podemos autenticar el sitio en
Tor, ya que podemos calcular el SHA-1 de la clave pública que nos
ofrece y validar que coincide con la URL.
Entonces ¿que pasa con Facebook? ¿Se han saltado el protocolo? ¿han hecho magia? Pues sí, se puede decir que han hecho magia,
magia a nivel técnico, ya que han conseguido la proeza de generar una
clave pública que, una vez calculado el hash SHA-1 de la clave, tomados
los primeros 80 bits de ese hash y convertidos a base32 dan exactamente facebookcorewwwi
Para conseguir un dominio tan 'cool' han tenido que hacer fuerza bruta
en la generación de las claves hasta que una ha dado ese precioso
dominio. Absolutamente brillante
Luego de eso, para hacer el golpe aun más efectista, han convencido a Digicert para que les emita un certificado SSL para ese dominio
Como se aprecia en la captura, han incluido varios dominios .onion en ese certificado.
¿Es necesario tener un certificado SSL para un 'hidden service'? La
verdad es que no, de hecho Tor 'by default', como hemos visto, ya ofrece
cierta capacidad para autenticar un site y Tor 'by default' ya
incorpora cifrado. El movimiento, en mi opinión, ha ido más en la línea
de bordar la faena por si no tuviese mérito construirte un dominio
'bonito' además, consigues que te emitan un certificado para él. Como
decía líneas más arriba, un movimiento 10 en todos los sentidos
Fuente: http://www.securitybydefault.com/2014/11/sobre-facebook-tor-y-certificados-ssl_7.html
No hay comentarios:
Publicar un comentario