Lección 1. Introducción al cifrado de la información. Herramienta GPG y OpenSSL
D. Eloi Sanfelix - 10/04/2013 

Twittear

Objetivos

En el mundo actual, el intercambio de información entre distintas partes se ha convertido en una de las principales tareas que ejecutamos día a día. El carácter de la información intercambiada se mueve entre lo más puramente intrascendente y la información estrictamente confidencial, pasando por todo tipo de niveles intermedios (por ejemplo, información privada pero no confidencial). Cuando tratamos con información sensible, es necesario tomar las precauciones adecuadas para que dicha información no sea accesible a quienes no deberían tener acceso a la misma. Al mismo tiempo, es necesario asegurar que aquellas personas que legítimamente deban tener acceso a dicha información sean capaces de obtenerla en el momento necesario. Con el fin de cumplir estos objetivos, existen técnicas criptográficas que nos permiten hacer la información accesible a las partes deseadas, mientras se mantiene inaccesible al resto del mundo. Para ello, es necesario proteger la información tanto en origen y destino (es decir, cuando la tenemos almacenada en nuestros discos duros) como en tránsito (cuando la transmitimos por la red hacia su destinatario).

En esta lección se introducen los problemas relativos a la seguridad de la información confidencial tanto en tránsito como en almacenamiento, y se describen mecanismos para cumplir los objetivos marcados y proteger nuestra información de ojos indeseados. Veremos cómo asegurar que nuestras comunicaciones con páginas web determinadas están siendo obtenidas únicamente por el destinatario deseado (por ejemplo, nuestro banco) así como formas de almacenar archivos individuales de forma segura. Junto con la problemática y las posibles soluciones, presentaremos distintos tipos de ataques que se pueden producir e introduciremos formas de detectarlos cuando sea posible.

Temario

Apartado 1. Problemática. Integridad y confidencialidad de los datos
Apartado 2. Cifrado de archivos con GnuPG y OpenSSL
Apartado 3. Seguridad en comunicaciones web: SSL
Apartado 4. Referencias

---

APARTADO 1. PROBLEMÁTICA. INTEGRIDAD Y CONFIDENCIALIDAD DE LOS DATOS

Durante el diseño inicial de Internet, los distintos habitantes de la red se suponían honestos y simplemente interesados en compartir información. De esta forma, en los protocolos básicos de Internet no se diseñaron mecanismos de seguridad que permitiesen proteger a los usuarios de otros usuarios maliciosos. En la gran mayoría de protocolos de Internet, los datos enviados a través de la red viajan en texto claro. Esto es, cualquiera que sea capaz de observar el tráfico de Internet es capaz de leer dichos datos.

Además, cuando dos usuarios intercambian información, ésta se transmite de nodo en nodo hasta alcanzar su destino. Por ejemplo, si un usuario de España se comunica con otro en Argentina, los datos podrían viajar desde Valencia hacia Madrid, de allí a Amsterdam, seguidamente a Nueva York para finalmente acabar en Buenos Aires.

Sin mecanismos de seguridad adicionales, cualquier administrador de sistemas situado en uno de estos puntos intermedios tiene acceso total a los datos intercambiados. No solamente puede leer los datos, sino que sería capaz de imposibilitar la comunicación o incluso realizar modificaciones sobre los datos transmitidos.

Adicionalmente, la gran mayoría de países almacenan las comunicaciones realizadas en sus redes durante un período determinado por ley. Pese a que teóricamente se establecen las garantías adecuadas en un Estado de Derecho, es más que factible acceder a dicha información sin orden judicial de manera preventiva por parte de cuerpos de seguridad y agencias de inteligencia. Por tanto, para garantizar la seguridad y privacidad de nuestras comunicaciones ante agentes externos, ya sean éstos usuarios maliciosos, mafias o incluso agencias de espionaje de unos u otros países, es necesario tomar las precauciones adecuadas.

Integridad y confidencialidad de los datos

Cuando hablamos de garantizar la seguridad y privacidad de nuestros datos, hablamos de garantizar dos propiedades básicas de los mismos:

• Confidencialidad: garantizar la confidencialidad de los datos significa asegurarse de que dichos datos son únicamente accesibles para las partes deseadas. Es decir, que si nuestra intención es compartir un archivo con cierta persona y mantenerlo en secreto entre ambos, nadie más debería ser capaz de acceder a ellos (salvo que una de las partes rompa dicha confidencialidad).

• Integridad: garantizar la integridad de los datos implica asegurar que dichos datos no han sido modificados, ya sea de forma accidental o intencionada. Otra propiedad relacionada con la integridad de los datos es la autenticidad de los mismos, que generalmente implica asegurar que los datos provienen de quien dicen provenir y que por tanto no han sido modificados en tránsito.

Para garantizar dichas propiedades, disponemos de una serie de algoritmos criptográficos. Para garantizar la confidencialidad de los datos, se utilizan algoritmos de cifrado. Un algoritmo de cifrado se define por una serie de modificaciones a aplicar a los datos, junto con el uso de otros datos conocidos como claves. Existen dos grandes familias de algoritmos de cifrados: los cifrados de clave simétrica y los cifrados de clave asimétrica. En un cifrado de clave simétrica, existe una única clave que debe ser conocida por todos los participantes en la comunicación.

Es decir, si queremos compartir unos datos con nuestro amigo Luis y con nadie más, y otros datos únicamente con nuestra amiga María, vamos a necesitar dos claves distintas: una de ellas la compartiremos con Luis y la usaremos únicamente para asegurar las comunicaciones entre ambos, y con la otra haremos lo mismo con María. Si María y Luis necesitan intercambiar datos confidenciales entre ellos, van a necesitar a su vez otra clave secreta compartida entre ambos, y así sucesivamente. Como se puede imaginar, este procedimiento funciona bien en comunidades pequeñas. En cambio, cuando las comunidades crecen y se quiere tener la posibilidad de intercambiar información de forma segura con cualquier miembro de la comunidad, el número de claves a manejar se vuelve impracticable.

Para resolver este problema se diseñaron los algoritmos de criptografía de clave asimétrica, también conocidos como algoritmos de clave pública. En este caso, cada persona genera un par de claves complementarias. Una de ellas es conocida como clave pública y, como su nombre indica, se encuentra disponible para todo aquel que lo desee. La otra clave, conocida como clave privada, se debe mantener en secreto. Cuando se desea intercambiar información con un usuario, se obtiene su clave pública y se utiliza ésta para cifrar la información. A partir de ese momento, únicamente aquellos conocedores de la clave privada podrán descifrar la información.

En la actualidad existen multitud de herramientas para cifrar datos o comunicaciones en tránsito aplicando criptografía simétrica o asimétrica. En esta lección se ve interesante resaltar dos de las más importantes desarrollando con ejercicios las operaciones básicas de funcionamiento (cifrado). Si desea profundizar en estas herramientas le aconsejamos visitar la página web oficial de cada una de las herramientas.

---

APARTADO 2. CIFRADO DE ARCHIVOS CON GNUPG Y OPENSSL

Además de la necesidad de proteger nuestras comunicaciones en red, en ocasiones es necesario proteger la información confidencial almacenada en nuestros sistemas informáticos. Para ello, es necesario cifrar la información de forma que aunque ésta caiga en manos no autorizadas no sea posible acceder a los datos. Existen soluciones para este problema tanto a nivel de sistema de ficheros completo (es decir, cifrando el disco duro entero o una de sus particiones) como a nivel de ficheros individuales. En esta lección se verá únicamente cómo proteger archivos concretos mediante herramientas open source y de software libre. Más adelante se dedicará una lección completa al cifrado de disco duro, mediante el cual es posible asegurar la información contenida en un disco duro o en un ordenador en caso de pérdida o sustracción.

Apartado 2.1. GnuPG

La herramienta GnuPG implementa el estándar OpenPGP uno de los sistemas criptográficos más usados en la actualidad. Este estándar permite intercambiar información con usuarios de otras herramientas como PGP Desktop de Symantec. OpenPGP es un sistema híbrido que combina criptografía simétrica y asimétrica. Cada usuario genera un par de claves, publicando su clave pública y manteniendo su clave privada en secreto, generalmente protegida mediante cifrado simétrico usando una frase de paso. Cuando se cifra un documento mediante OpenPGP, se genera una clave simétrica aleatoria y se usa ésta para cifrar el documento mediante un cifrado simétrico como podría ser TDES o AES. Además, la clave usada para cifrar el documento se cifra usando la clave pública de aquellas entidades que se desea tengan acceso a los datos. Por tanto, un documento cifrado mediante OpenPGP contiene una serie de copias de la clave simétrica cifrada con claves públicas de los distintos destinatarios de los datos, así como el propio documento cifrado con dicha clave simétrica. Además de esto, OpenPGP permite proteger la integridad de los datos mediante el uso de firmas digitales. Para ello, se hace uso de la parte privada de un par de claves para generar una firma digital y almacenarla junto al documento a proteger. Por tanto, mediante OpenPGP es posible proteger tanto la confidencialidad como la integridad de los datos. En los siguientes ejercicios se verá cómo utilizar GnuPG paso a paso, con la finalidad de proteger datos para nuestro propio uso futuro.

Apartado 2.2. OpenSSL

Además de implementar el estándar SSL, la suite de herramientas y librerías OpenSSL proporcionan una serie de herramientas criptográficas que permiten a los usuarios cifrar información mediante criptografía simétrica o asimétrica. En los siguientes ejercicios se verá cómo generar claves asimétricas, así como cifrar archivos mediante el uso de OpenSSL desde línea de comandos.

---

APARTADO 3. SEGURIDAD EN COMUNICACIONES WEB: SSL

En el apartado anterior se han destacado las operaciones esenciales para cifrar ficheros con las dos herramientas más conocidas en Internet. Adicionalmente a este tipo de herramientas es necesario habilitar procedimientos para la protección de los datos en tránsito. En la red Internet actual, la gran mayoría de las comunicaciones a nivel de usuario son comunicaciones vía web, hablamos de Facebook, Twitter, acceso a banca online, etc. Con la intención de securizar las conexiones del mayor número de personas posibles se ve interesante en esta lección profundizar exclusivamente en la protección de comunicaciones web. Es por tanto necesario asegurar que cuando interactuamos con una página web estamos realmente intercambiando información con la página legítima y no con un atacante. Para ello, se ha implementado un modelo de seguridad basado en una infraestructura de clave pública (PKI, del inglés Public Key Infrastructure) en el protocolo SSL.

Apartado 3.1. Modelo de confianza

Cuando nos conectamos a una página web mediante el protocolo HTTPS (HTTP sobre SSL), nuestro navegador se conecta al servidor web e intenta establecer una sesión segura mediante SSL. Para ello, se llevan a cabo los siguientes pasos:

1. Obtención del certificado del servidor. En primer lugar, el servidor nos envía un certificado digital. Esto sería equivalente a un pasaporte o documento de identidad generado por las autoridades de nuestro país. Básicamente, el certificado incluye el dominio de la página web, el período de validez, la parte pública del par de claves que el servidor va a usar para establecer la comunicación y una firma digital creada por una Autoridad de Certificación (CA, Certification Authority).

2. Comprobación del certificado. Una vez se tiene el certificado, se obtiene la clave pública de la CA y se verifica la validez del mismo. Para que este paso sea válido, la CA debe estar dentro de una lista de autoridades de confianza (por ejemplo, equivaldría a ser generado por un país de la UE en el mundo real). Para ello, los navegadores contienen una lista de CA de confianza. Si el certificado no ha sido generado por una CA de confianza, es posible no obstante que haya sido por generado por una CA subordinada. En este caso se procede a comprobar la firma digital sobre el certificado de la CA subordinada. Con esto se genera una cadena de certificados, que debe acabar en una autoridad de confianza. Si es posible verificar todos los certificados de la cadena, entonces se asume que la clave pública expuesta por el servidor es de confianza.

3. Comprobación de la identidad del servidor. Una vez establecida la confianza de la clave pública, es necesario establecer la identidad del servidor. Para ello, se utiliza el protocolo SSL para asegurar que el servidor con el que estamos hablando efectivamente tiene conocimiento de la clave privada correspondiente. Además, el protocolo SSL se asegura de introducir datos aleatorios en la comprobación para evitar que un atacante pueda estar reusando comunicaciones almacenadas con anterioridad.

4. Generación de claves simétricas. Finalmente, se utilizan los datos intercambiados entre cliente y servidor para generar dos claves simétricas. Éstas se usarán para asegurar la confidencialidad y la integridad de las comunicaciones durante la sesión web.

Como es sencillo de entender a partir la descripción proporcionada, si lo desea en la lección 9 de la enciclopedia Intypedia tiene un vídeo con la explicación de todo el proceso, SSL permite proteger la información en tránsito en una sesión web protegida. Sin embargo, SSL no protege frente atacantes capaces de comprometer la seguridad de cualquiera de los dos extremos de la información. Si el cliente ha sido comprometido, es obvio que el atacante tendrá acceso a cualquier comunicación del mismo con un servidor web por mucho que éste utilice SSL. Por otra parte, si un servidor web es comprometido, el atacante sería capaz de inyectar información en las sesiones SSL así como acceder a toda la información a la que tiene acceso el sistema comprometido. Por último, si el atacante es capaz de obtener la clave privada correspondiente al servidor, éste sería capaz también de descifrar las comunicaciones protegidas vía SSL puesto que tendría acceso a toda la información necesaria para derivar las claves simétricas utilizadas en las sesiones web. Así pues, SSL protege la confidencialidad y la integridad de la comunicación pero no puede proteger al usuario ante servidores maliciosos o comprometidos.

Apartado 3.2. Ataques a SSL

Visto el proceso de establecimiento de sesión y el uso de claves simétricas para cifrar y autenticar la comunicación usado en SSL, queda claro que una simple escucha de la comunicación no es suficiente para obtener el contenido de la misma. Además, cualquier modificación del tráfico en tránsito debería en principio ser detectada mediante la comprobación de integridad realizada tanto en el cliente como en el servidor. Así pues, existen varios niveles a los que se puede atacar SSL: ataques vía red, ataques al protocolo SSL, ataques a la implementación e incluso ataques a la criptografía en sí.

Si desea una resumen detallado de posibles ataques le recomendamos el resumen A brief chronology of SSL/TLS attacks y el artículo Lessons Learned from previous SSL/TLS attacks. A brief Chronology of attacks and weaknesses de Christopher Meyer y Jörg Schwenk.

Seguidamente se resumen algunos de los más significativos:

Ataques vía red: Man in The Middle

Uno de los ataques de red clásicos es el conocido como ataque de hombre en medio, Man in The Middle (MiTM) en inglés. En este caso, el atacante se sitúa en el medio de la comunicación y es capaz de observar y modificar la misma. Para ello, un atacante puede hacer uso de herramientas que realizan ARP Spoofing (como ettercap o arpspoof), o realizar ataques de envenenamiento DNS. Como hemos visto anteriormente, SSL se protege ante este tipo de ataques mediante el uso de cifrado y mecanismos de comprobación de integridad de los mensajes. Sin embargo, si un atacante se sitúa en el medio justo antes de que se establezca la comunicación, podría establecer una sesión con un certificado falso con el usuario, y una sesión legítima con el servidor web. Con ello, el atacante es capaz de descifrar, modificar y reenviar el tráfico entre ambos destinos. Para ello, se pueden utilizar herramientas como burp proxy o similares. Obviamente, el navegador avisará al usuario de que el certificado no es de confianza. Sin embargo, el usuario puede aceptar el aviso y seguir con la comunicación si así lo desea. Es por ello que, como usuario, es necesario ser consciente de dicha posibilidad y comprobar que los certificados presentados por el navegador son en efecto confiables o abortar la comunicación en caso contrario.

Uso de certificados comodín

En los certificados utilizados para garantizar la autenticidad de los servidores web existe la posibilidad de utilizar comodines dentro del dominio web. Así pues, se pueden generar certificados válidos para cualquier dominio. Obviamente, para generar dicho certificado se necesitaría la colaboración de CAs o el acceso ilegítimo a ellas. Por ejemplo, cabe pensar que agencias de espionaje de determinados gobiernos tengan acceso a este tipo de certificados para realizar labores de vigilancia e investigación. Asimismo, recientemente se ha descubierto un certificado ilegítimo para *.google.com generado mediante un certificado de CA subordinada emitido por TurkTrust, una autoridad certificadora turca.

Ataques a CAs

Durante los últimos años, se han conocido varios ataques a entidades certificadoras que han comprometido la seguridad de SSL. En estos casos, el atacante compromete los sistemas de una CA incluida en las listas de confianza de la mayoría de navegadores y utiliza dicho acceso para generar certificados perfectamente válidos. Una vez los certificados son generados, se puede llevar a cabo un ataque MiTM difícilmente detectable para un navegador. En las referencias de la lección se adjunta el informe forense realizado por Fox IT analizando un ataque de este tipo a la entidad certificadora holandesa DigiNotar.

Ataques a la criptografía: colisiones en funciones resumen

Cuando se realiza una firma digital, generalmente se suele firmar un resumen del mensaje en lugar del mismo mensaje. Dicho resumen se calcula mediante el uso de una función resumen criptográfico (o función hash) como MD5, SHA-1 o la familia de algoritmos SHA-2. Uno de los requisitos de estas funciones es que debe ser complejo encontrar colisiones, es decir, debe ser complejo encontrar dos mensajes distintos con el mismo resumen. Sin embargo, a medida que la ciencia del criptoanálisis avanza, se van encontrando debilidades en este tipo de funciones. En 2008, un grupo de investigadores consiguió crear colisiones en MD5 mediante el uso de mensajes con un prefijo elegido (es decir, que la parte inicial del mensaje puede ser elegida por el atacante) y utilizar dicha técnica para generar dos certificados SSL con el mismo resumen (véase referencias). Uno de dichos certificados apuntaba a un dominio bajo el control de los investigadores, mientras que el otro apuntaba a un dominio víctima, por ejemplo google.com. Puesto que el resumen es el mismo, los investigadores podían enviar el certificado inofensivo para ser firmado por una autoridad de certificación y luego utilizar dicha firma con el certificado fraudulento para realizar ataques.

Ataques lógicos a la implementación

Además de los ataques mencionados, en los últimos años se han publicado ejemplos de ataques a la implementación de SSL en los clientes. Un ejemplo de ellos es el ataque del byte nulo: cuando el navegador encontraba un byte nulo en el nombre común contenido en el certificado, consideraba que ahí acababa el nombre. En cambio, las autoridades certificadoras consideraban el campo entero. Con ello, era posible obtener un certificado con nombre *\0midominio.com, donde \0 representa un byte nulo y midominio.com un dominio bajo el control del atacante. Cuando este certificado es presentado al navegador, éste lo considera un certificado comodín (debido al signo *) y lo acepta como válido. Obviamente, una vez descubiertos y parcheados, este tipo de ataques se acaban volviendo obsoletos. Sin embargo, es importante tener en cuenta su existencia puesto que podríamos estar usando sistemas sin actualizar, o bien sistemas con problemas similares o relacionados.

Ataques laterales a la clave privada

Finalmente, otro punto de ataque es el de conseguir acceso a la clave privada del servidor. Como hemos visto anteriormente, si el servidor ha sido comprometido, la confidencialidad e integridad de los datos no está garantizada incluso si no se conoce la clave privada. Sin embargo, existen formas de obtener la clave privada sin tener acceso directo al servidor donde se encuentra la misma. Para ello, se pueden utilizar un tipo de ataques conocido como ataques laterales (side channel attacks). Uno de los ataques de este tipo más relevantes para servidores web, y en especial para servidores compartidos en los que un mismo hardware se utiliza para virtualizar varios sistemas operativos, lo forman los conocidos como cache timing attacks. Por ejemplo, imaginemos un servicio que utiliza instancias en Amazon EC2 para poder escalar fácilmente el hardware en función de sus necesidades. Todas estas máquinas compartirían una misma clave privada, o varias claves privadas con certificados válidos para el mismo dominio. Si un atacante lograse alquilar una instancia que se ejecutase en una de estas mismas máquinas, podría introducir un proceso con la intención de atacar la clave privada de la instancia vecina. Para ello, la estrategia del proceso atacante consiste en predecir la forma en la que el proceso víctima accede a memoria en función del valor de la clave. El proceso atacante realiza accesos a memoria antes y después del uso de partes de la clave, y mediante medidas de tiempo es capaz de determinar cuáles son los valores de la clave. Para información detallada sobre cómo se implementan este tipo de ataques, se sugiere al lector la lectura de los enlaces reflejados en la sección de referencias.

Apartardo 3.3. Protección ante ataques

En vista de los ataques más comunes ante SSL, existen dos formas principales de protegerse como usuario: limitando la lista de CAs de confianza y/o vigilando los certificados de aquellas páginas webs con las que interactuamos. Puesto que la verificación manual de certificados cada vez que visitamos una página web es una tarea tediosa, en esta sección vamos a ver algunas utilidades que nos pueden ayudar en este cometido.

SSLCop

SSLCop es una herramienta desarrollada con el objetivo de limitar el número de CAs de confianza en sistemas Windows. El concepto básico detrás de esta herramienta es que en general, un usuario español, por ejemplo, no tiene ninguna necesidad de acceder a sitios web con certificados emitidos en Macao. Siguiendo este concepto, la herramienta SSLCop nos permite elegir en qué CAs queremos confiar basándonos en el país de origen de la misma. Cómo se puede ver en esta imagen, la interfaz nos permite seleccionar CAs por países y bloquear aquellos países seleccionados.

Una vez presionado el botón BLOCK!, estas CAs son eliminadas de la lista de CAs de confianza de Windows, que es usada entre otros por Microsoft Internet Explorer y Google Chrome.

Certificate Patrol

Certificate Patrol es una extensión para el navegador Firefox que avisa al usuario cuando el certificado de una página web ha cambiado. Para ello, la primera vez que se accede a una página con la extensión instalada se nos mostrará el certificado y se nos pedirá aceptarlo. En las siguientes conexiones a la misma página web, Certificate Patrol comprobará que el certificado no haya cambiado, y en caso de haberlo hecho nos mostrará las diferencias entre el certificado anterior y el nuevo. Además, la extensión intenta averiguar si había razones para cambiar el certificado (e.g. si el certificado anterior iba a caducar) e intenta aconsejar al usuario. Instalar Certificate Patrol es tan sencillo como abrir el Administrador de complementos de Firefox, vía el menú Herramientas > Complementos. Una vez abierto, podemos realizar una búsqueda por Certificate Patrol y seleccionar Instalar.

Una vez instalado, hará falta reiniciar Firefox. Tras esto, Certificate Patrol está instalado y listo para funcionar. A partir de ahora, al acceder a un sitio web usando HTTPS, Certificate Patrol comprobará si su certificado ha sido almacenado con anterioridad.

Si no es así, nos avisará de que se ha aceptado un nuevo certificado para este servidor mediante una notificación en la misma ventana de Firefox:

En este caso, podemos ver los detalles del certificado o incluso rechazarlo. Hay que tener en cuenta que Certificate Patrol no está completamente integrado con el manejo de certificados del navegador, con lo que no es capaz de bloquear el acceso a páginas web determinadas. Por tanto, si presionamos rechazar simplemente no se almacenará el nuevo certificado, pero accederemos a la página igualmente.

En caso de cambio del certificado, veremos un aviso de Certificate Patrol ofreciendo detalles del certificado actual y el observado anteriormente. La siguiente captura corresponde al aviso obtenido cuando se ha producido un ataque MitM usando burp proxy:

Como se puede ver, en la parte de arriba se nos dice que ha habido cambios y deberíamos tener cuidado. Si inspeccionamos los cambios, vemos que el nuevo certificado está emitido por PortSwigger CA en lugar de Google Internet Authority. Como se ha comentado antes, aunque presionemos Reject (rechazar) el acceso a la página continuará. Así pues, no se debe tomar Certificate Patrol como una herramienta que nos hará inmunes ante ataques, sino más bien como una herramienta para detectar dichos ataques.

Perspectives y Convergence

Un concepto relacionado al anterior, aunque basado en lo que se ha denominado perspectivas de red es implementado por Perspectives y su sucesor, Convergence. En este caso, el usuario define una serie de notarios de red de confianza. Estos notarios de red pueden ser bien sistemas públicos ofreciendo el servicio, o sistemas añadidos por el usuario. La idea en este caso es eliminar la confianza en las listas de CAs fijas en el navegador, y moverla a dichos notarios de red. Cuando el usuario intenta acceder a una página web, realiza una consulta a los notarios. En respuesta a la consulta, los notarios emitirán un voto a favor o en contra del sitio web: nos dirán si ven lo mismo que nosotros, y si creen que el sitio web es legítimo. Si suficientes respuestas son positivas (dependiendo de la configuración), la aplicación determina que el sitio web es legítimo. Perspectives se encuentra actualmente en el repositorio de extensiones de Mozilla Firefox, y por tanto es extremadamente sencillo de instalar. Igual que con Certificate Patrol, se puede acudir al Administrador de complementos y realizar una búsqueda para encontrar la extensión:

Tras reiniciar Firefox, se pueden configurar las preferencias de la utilidad desde el mismo Administrador de complementos. En ellas se encuentra una lista de notarios, así como varias opciones en cuanto al nivel de seguridad requerido (todos los notarios deben estar de acuerdo, una mayoría de ellos debe estar de acuerdo, etc.).

Cuando Perspectives se encuentra activo, el usuario puede ver un pequeño icono con la letra P sobre fondo azul en la barra de navegación. Dicho icono se convierte en un tick sobre fondo verde cuando el sitio web es considerado seguro.


Pulsando sobre dicho icono accedemos a un menú que nos permite, entre otras cosas ver los resultados de las notarías, reportar un ataque, u obtener Ayuda:


Si accedemos a los resultados de las notarías, en el caso de twitter veremos lo siguiente:

Como se puede observar, en este caso todas las notarías han ido observando el mismo certificado desde hace 30 días. En cambio, si accedemos a un sitio web cuyo certificado cambia dependiendo del origen de la petición (por ejemplo Google) veremos un icono con una X sobre fondo rojo y la verificación de las notarías tendrá el siguiente aspecto:

Se puede observar que en este caso nuestro navegador observa un certificado que coincide con el observado por 4 notarías (en verde). En cambio, estas notarías observaron certificados distintos durante los últimos 30 días (amarillo y naranja), y hay otras 4 notarías que en la actualidad observan otro tercer certificado (violeta). Finalmente, cuando nos encontramos ante ataque, veremos que todas las notarías acceden a un certificado distinto al nuestro:


Aquí podemos observar que la llave vista por el navegador no coincide con la vista por ninguna notaría. Es más, en este caso todas ellas observan la misma clave. Por tanto, Perspectives nos permite averiguar si estamos siendo objeto de un ataque comparando nuestra perspectiva de la red con la perspectiva de los notarios.

---

APARTADO 4. REFERENCIAS

- Firmas digital - http://es.wikipedia.org/wiki/Firma_digital
- Extended Validation Certificate - http://en.wikipedia.org/wiki/Extended_Validation_Certificate
- ettercap - http://ettercap.github.com/ettercap/
- Envenenamiento DNS - http://es.wikipedia.org/wiki/DNS_cache_poisoning
- TurkTrust: Algunas reflexiones sobre el último 'CA Gate' -http://www.securitybydefault.com/2013/01/algunas-reflexiones-sobre-el-ultimo-ca.html
- Informe forense sobre el caso DigiNotar - http://www.rijksoverheid.nl/documenten-en-publicaties/rapporten/2011/09/05/diginotar-public-report-version-1.html
- Proyecto HashClash - http://www.win.tue.nl/hashclash/
- Cache missing for fun and profit - http://www.daemonology.net/papers/htt.pdf
- Cache timing attacks on AES - http://cr.yp.to/antiforgery/cachetiming-20050414.pdf
- SSL Cop - http://www.security-projects.com/?SSLCop
- Convergence - http://convergence.io