Advertencia del IE 6 de certificado digital no fiable

El certificado digital es una de las piezas más confusas del entramado criptográfico que nos asiste mientras navegamos por Internet, garantizando la seguridad de nuestras comunicaciones con el mundo exterior. En este contexto, seguridad significa confidencialidad, integridad y autenticidad, entre otras cosas. Es decir, que nadie excepto el destinatario puede ver lo que yo envío o recibo, que nadie puede modificarlo sin que me de cuenta, y que nadie suplanta la identidad de ninguna de las partes.

La confusión viene porque es realmente difícil entender el significado de los conceptos que conforman el certificado digital. En el mundo real, cuando pago en un comercio con mi tarjeta VISA, me piden el DNI (o deberían pedírmelo). El DNI es mi certificado digital, y con él demuestro que soy el titular de la tarjeta. Además, el DNI es fiable, porque lo emite el Cuerpo Nacional de Policía. Probablemente, si presento mi carné de socio del polideportivo, no causaré el mismo efecto, y me rechacen la transacción.

Esto que resulta tan simple en la vida real, en Internet es una pesadilla. Conceptos como firma digital, autoridad de certificación, lista de revocación o autoridad raíz resultan poco comprensibles, por estar totalmente alejados del mundo tangible que todos conocemos. Sin embargo, al problema de entender la tecnología se suma la forma en que se usa, y el modo en que las aplicaciones muestran la información a los usuarios.

Los diferentes navegadores han ido modificando de versión en versión los mensajes de aviso que dan cuando algo falla en la comprobación de los certificados digitales (es decir, cuando el DNI que está presentando la persona con la que queremos realizar una transacción no parece fiable). Las versiones 5 y 6 del Internet Explorer, muy utilizadas aún, muestran un cuadro de diálogo con 3 apartados. El primero informa sobre la confianza que genera el certificado. El segundo advierte si el certificado está caducado. El tercero confirma si el certificado se ha emitido a nombre de quien lo está presentando. Un ejemplo típico de mensaje confuso sería este:

“The security certificate was issued by a company you have not chosen to trust. View the certificate to determine wether you want to trust the certifying authority.”

Que en la versión en español sería algo así:

“El certificado de seguridad fue emitido por una compañía en la que no confías. Revisa el certificado para determinar si quieres confiar en la autoridad de certificación.”

Esta advertencia tiene como objeto prevenir de un posible ataque de tipo man in the middle, en el que un tercero intercepta la comunicación y se hace pasar por una de las partes, con objeto de obtener información o modificar el contenido del mensaje. ¿Realmente podría alguien entender el riesgo que existe, sopesarlo, y tomar una decisión con conocimiento de causa, a partir de la información que muestra el navegador? Yo creo sinceramente que no.

La versión 7 del IE, y la versión 3 del Firefox, han actualizado los mensajes, para que sea más difícil saltárselos, y para que provoquen cierto miedo en el usuario. La información que se da sobre el problema sigue siendo confusa, pero se indica que el posible motivo es la intercepción de la comunicación, y la suplantación de identidad. Esto debería bastar para que si la página web de un banco nos devuelve este aviso del navegador, cortemos la comunicación.

Sin embargo, existe un fenómeno que debilita la seguridad del esquema de certificación. Es habitual que los servidores de Internet utilicen certificados digitales autofirmados, para reducir costes (se evita pagar a la pertinente Autoridad de Certificación). Estos certificados hacen saltar las advertencias de los navegadores, porque no pueden validarse contra una autoridad de confianza. Como resultado, el usuario se acostumbra a ver falsas advertencias de peligro, y termina por hacer caso omiso y continuar navegando sin fijarse en los detalles. El efecto de la sobrecarga de mensajes es peligroso.

El certificado digital es una pieza clave de la seguridad de Internet. Deberíamos prestar mucha más atención a su significado, y usarlo sólo para aquello para lo que fue concebido. Los certificados autofirmados son, sin duda, una mala implementación del concepto de certificación.

Entradas relacionadas:

1. ¿Por qué se puede copiar un disco digital?

Disco digital

Esta pregunta no tiene fácil respuesta. Llevo días intentando entender cómo hemos llegado a donde estamos: la copia digital de archivos musicales y películas de vídeo resulta trivial. Los magnates de la producción de CDs y DVDs deben ser, o muy tontos, o todo lo contrario y se les fue la mano (se pasaron de listos).

Empecemos por el CD o compact disc. El primer disco óptico vio la luz comercialmente en el año 1982, y se desarrolló desde el principio como un medio de almacenamiento de audio en formato digital (lo que llegó incluso a condicionar su capacidad de almacenamiento, que se adaptó a la duración de la Novena Sinfonía de Beethoven). El estándar que normalizó este formato se conoce como Red Book, y aunque hoy resulta difícil de creer, no se incluyó en él ningún mecanismo de protección de la información digital almacenada.

Se trata de un error excusable. En la década de los 80 el ordenador personal estaba dando sus primeros pasos (el IBM PC nació en 1981). Su capacidad de proceso era insuficiente para tratar los archivos de audio contenidos en el CD. No existía tampoco forma de comprimir el audio en un tamaño que fuera fácilmente manipulable. No existía tampoco Internet (el embrión de Internet, ARPANET, había nacido hace unos pocos años). En este contexto, sólo un gurú habría podido prever la necesidad de proteger lo que realmente contiene un compact disc: una copia maestra digital de cada canción. Y aún habiendo sido capaz de preverlo, ¿era el estado del arte de la tecnología de aquella época suficiente como para desarrollar un sistema de protección eficaz? Probablemente, no.

Y llegamos al DVD. Este formato de almacenamiento fue concebido como una evolución natural del CD. En este caso, se partía de la experiencia adquirida con el formato anterior, y se buscaba una solución de mayor capacidad, que sirviera tanto para almacenar contenido audiovisual (DVD vídeo y DVD audio), como archivos de ordenador (DVD ROM). Los primeros DVDs se comercializaron a finales de la década de los 90.

En esta ocasión, el grupo de trabajo encargado de definir el estándar consideró necesario proteger el contenido, para lo que se adoptó el esquema de cifrado conocido como CSS (Content Scramble System). El cifrado propietario introducido con este sistema era poco robusto. Se basaba además en un conjunto de claves únicas distribuidas entre todos los fabricantes de equipos reproductores de DVD. Al parecer, uno de los fabricantes no protegió lo suficiente su clave, lo que permitió que un grupo de hackers tuviera acceso a ella y rompiera el algoritmo de cifrado, desarrollando después un programa para descifrar el contenido de cualquier DVD (lo que conocemos como DVD rip). Esto sucedió en 1999, sólo dos años después del lanzamiento del formato.

Probablemente, el hecho de que sólo se utilizaran claves de 40 bits facilitó la tarea. En el momento de definir el formato del DVD, las leyes americanas prohibían la exportación de sistemas criptográficos que emplearan claves de más de 40 bits. También se apunta que el algoritmo de cifrado tenía un diseño tan débil, que con la potencia de cálculo de los ordenadores de finales de los 90, un ataque de fuerza bruta lo hubiera roto en pocos días (y con la actual, en pocos segundos).

Esta historia se está repitiendo ahora con el Blue-ray Disc. La falta de visión y los errores técnicos en la concepción de los sistemas de protección han posibilitado la copia digital del audio y del vídeo contenido en los soportes diseñados y fabricados para satisfacer las necesidades de la industria audivisual. Ellos mismos cavaron su propia tumba; la tecnología informática e Internet únicamente dieron un empujocito.

Entradas relacionadas:

1. La confusión del certificado digital

Transmission: lista de peers conectados

Tras instalar y configurar el programa P2P Transmission, decidí seleccionar la opción “Prefer encrypted peers” (que traducido al español sería algo así como “Utilizar preferentemente peers cifrados”), para ver hasta qué punto esto podía añadir cierta privacidad al proceso de descarga de archivos. Ingenuo de mí, acaba de cometer un error básico: confundir confidencialidad con privacidad.

Ciertamente, la comunicación con peers que soporten mecanismos de cifrado hace que el chorro de bits que fluyen entre mi PC y el peer al que estoy conectado sea un amasijo indescifrable de ceros y unos, es decir, un mensaje cifrado. De ser interceptado por terceras partes (el famoso man in the middle), sería ilegible. Pero no, eso no aporta privacidad.

La privacidad es algo totalmente diferente. Está relacionada con la imposiblidad de obtener de una persona información sobre sí misma que ella no quiere revelar. Un ejemplo habitual es el relacionado con las compras on-line, en las que es necesario que se garantice la privacidad de las transacciones: la entidad que gestiona el pago por internet no debe conocer el objeto de la transacción.

La privacidad en las redes P2P es, simplemente, nula. Basta con observar la ventana de Transmission que me da la información de los peers a los que estoy conectado para descargar el openSuse (por poner un ejemplo). Podemos ver la larga lista de direcciones IP, que identifican a los equipos que están descargando o compartiendo ese mismo fichero. Y podemos ver también el cliente BitTorrent que utilizan y su versión.

Podríamos pensar que la dirección IP no es suficiente para identificar unívocamente con quién nos estamos conectando, puesto que puede tratarse de la dirección de un proxy, o bien puede ser una dirección IP asignada mediante DHCP (y que por tanto cambia dinámicamente). Esto es cierto, pero también lo es que, en virtud de la LSSI (Ley de Servicios de la Sociedad de la Información), los opeardores están obligados a guardar ficheros de log donde se registre para cada comunicación los datos necesarios para identificar a las partes.

La revelación de la información almacenada por los operadores de telecomunicaciones sólo es por mandato judicial, lo que podría hacernos pensar que estamos protegidos. Esto es así en lo que se referiere a poder determinar nuestra identidad a partir de una dirección IP. Pero a veces no hace falta saber quién está detras de una dirección IP, basta con saber que ha vuelto a conectarse. Con técnicas de data-mining es factible establecer patrones y hábitos de descarga a partir del tráfico P2P, y determinar, por ejemplo, qué IPs comparten películas de Disney o cuáles son aficionadas a la música de los Beatles. El resto, forma parte de la historia reciente de Amazon o Google, expertos en el marketing personalizado.

Esa misma información podría utlizarse, por cierto, para emprender acciones legales contra quienes se descargan archivos de redes P2P, suponiendo que esto fuera ilegal (que no lo es). Pero esta es ya otra historia, de la que hablaremos más adelante.

No hay entradas relacionadas.

Banner de paypalsucks.com

Mi última experiencia en eBay no hizo sino confirmar lo que antes había podido leer en varios foros: PayPal sucks. Y este es precisamente el lema (y dominio) de una página web dedicada a mostrar las “bondades” de PayPal, con pelos y señales. Pero no es la única. Bajo el título de PayPal – Horror Stories, Lawsuits, PayPal Problems & Information, el sitio AboutPayPal desgrana cientos de malas y muy malas experiencias con el medio de pago más conocido de Internet.

Mi historia es como la de muchos otros: vendo un artículo en eBay (una memoria de PC, concretamente), la envío por correo ordinario (tal y como se indicaba en el anuncio), y Correos pierde el paquete (eufemismo para decir que el paquete se lo queda alguien, porque le pareció que aquello podía serle útil).

Al no recibir el artículo, el comprador decidió abrir una disputa en el Centro de Resolución de Conflictos de PayPal. Antes habíamos intercambiado ya varios correos electrónicos, en los que le expliqué que debía haber elegido una modalidad de envío certificada si consideraba que el importe de la venta lo justificaba. No sirvió de nada.

El Centro de Resolución de Disputas congela el importe de la transacción inmediatamente (obsérvese la confianza que tiene PayPal en sus vendedores, que al fin y al cabo son los que le pagan las comisiones que constituyen su negocio). A la vez, facilita que comprador y vendedor se intercambien mensajes para aclarar las cosas (algo inútil, naturalmente, dado que el comprador ha abierto una disputa).

Terminado el turno de los mensajes, PayPal ofrece al vendedor 3 opciones para resolver el conflicto:

1. Devolver el importe al comprador sin más (es decir, reonocer que no se ha realizado el envío)
2. Probar que ya se ha devuelto el importe (más de lo mismo)
3. Demostrar que efectivamente se ha realizado el envío.

Eligiendo una de las dos primeras opciones, el comprador tiene que asumir que es un estafador. No existe, por ejemplo, una opción para indicar que no se tiene nada que ver con esa transacción, y que es un error de alguien que ha puesto mal la dirección de correo electrónico del vendedor (cosa que también me sucedió en otra ocasión).

La opción 3 te lleva a un formulario donde hay que introducir, ineludiblemente, el código de seguimiento del envío. Si no existe tal código, no hay forma de continuar. De esta forma, si el envío se ha realizado por correo ordinario sin certificar, o el artículo se ha entregado en mano, no existe forma de justificarlo usando el Centro de Resolución de Disputas. Y no hay alternativa.

El fin de la histora es que PayPal resuelve que el comprador tiene razón (aún sigo preguntándome cómo el compardor pudo demostrar que no había recibido el artículo). Por alguna razón misteriosa, la transacción estaba cubierta por cierta garantía de PayPal, lo que hizo que yo no tuviera que devolver el importe. PayPal se lo reintegró el comprador (o al menos eso es lo que se indicaba en el último email que recibí).

Moraleja: si vendes algo en eBay y admites PayPal, el envío siempre certificado. O mejor aún: si vendes algo en eBay, no uses PayPal.

No hay entradas relacionadas.

Firewall del Leopard en mi PC

Ayer estuve un rato en modo paranoico, debido a lo que supongo fue sólo un cuelgue de mi router. El caso es que, de pronto, no había forma de cargar ninguna página en el navegador. Pero a la vez, tenía al Cyberduck (mi cliente FTP) dando caña, descargando en mi PC el blog desde elcodigo.com (tenía ganas de investigar un poco).

Me pareció extraño y pensé por un momento que algo iba mal, que igual había sido infectado por alguna clase de troyano maligno que no me dejaba navegar por Inernet, pero que sí me dejaba conectar con el servidor FTP de mi proveedor de hosting. Así que me puse a revisar las reglas del firewall del PC y las del firewall del router. Curiosamente, la web de administración del router no indicaba por ningún lado que el cortafuegos estuviera habilitado. Así que decidí hacer una prueba desde las páginas de PC Flank, un sitio web que proporciona diversas herramientas para verificar hasta que punto nuestro PC está siendo protegido. Y fue cuando me llevé la sorpresa.

Los chicos de la empresa con la que tengo contratado el ADSL son muy eficientes a la hora de proporcionar un router que se configure sólo, y en el que no haya que tocar absolutamente nada para comenzar a navegar desde el primer día. Son partidarios, como otros muchos proveedores, de la simplicidad, y por tanto, la web de administración del dispositivo ofrece las mínimas opciones de configuración. Pero al parecer, también son partidarios de la inseguridad por defecto. Así, mi router tiene abiertos dos puertos que se consideran extremadamente peligrosos, desde el punto de vista de la seguridad: el puerto 80 (HTTP) y el puerto 23 (TELNET).

El TELNET es una reliquia del pasado, cuyo historial de brechas de seguridad hace que sea el primer servicio a desactivar, y el primer puerto a bloquear, en toda máquina conectada a Internet que se desee tenga una vida feliz y tranquila. No está justificado que haya puertos abiertos en mi router, salvo los imprescindibles para la resolución de incidencias y la configuración remota. Y aún así, incluso éstos se podrían habilitar bajo demanada, desde la interfaz web (si esa opción de configuración no estuviera capada, claro).

Así las cosas, tengo un dispositivo configurado de forma insegura y que no puedo reconfigurar. Supongo que es mejor así, ya que de esta forma, tampoco lo puedo configurar mal. Pero sinceramente, prefiero ser yo el que rompa las cosas, a que me las rompan los demás.

No hay entradas relacionadas.