Hace un año publiqué un par de artículos interesantes:

• Backup doméstico seguro con Linux, cifrado y ZFS.
• Backup doméstico seguro con Linux, cifrado y ZFS (II).

El sistema sigue en producción y bien. No hay incidentes reseñables más allá de la virtualización sobre un Windows 8 doméstico (detalle anecdótico de mi configuración particular).

El proceso es simple y rutinario: el sistema de backup tiene configurado un mirror formado por dos discos. Uno de los discos está enchufado y funcionando, pero el otro está offline y, de hecho, guardado bajo llave en una localización remota.

En las vacaciones recojo el disco duro offline y lo enchufo al sistema de backup. Esto hace que el mirror resincronice los discos con todos los cambios. Una vez que ambos discos están al día, entonces procedo a realizar una revisión completa de ambos discos duros. Comprobado que todo está OK, desenchufo el disco duro original y dejo conectado el que estaba offline, básicamente alternando los dos discos duros.

Este esquema me protege de catástrofes graves como incendios, inundaciones o robos. O de fuentes de alimentación que fallan y se llevan los discos por delante, o bugs del sistema operativo. También te proteje de meteduras de pata, como borrar algo importante por error. La alternancia de los discos duros los desgasta por igual. Los discos duros en sí están cifrados, así que almacenarlos por ahí no es problema.

Leer más…

Los curiosos que frecuenten mi web habrán visto que las últimas fotos que he publicado contienen una pequeña y discreta firma visual en la esquina inferior derecha.

La cuestión es que me he encontrado fotos mías en páginas sobre fantasmas (glup) o, peor aún, en una web oficial de la Junta de Andalucía. Los emails al respecto siempre giran sobre lo mismo: "no sabíamos que no se podían usar". En fin. El logo se puede eliminar pero, al menos, no se podrá decir que se eliminó "por error" :-)

A nivel tecnológico, utilizo ZOPE y el producto ExtFile. ExtFile almacena la imagen original, a toda resolución, y genera una pequeña imagen "preview", que es lo que se muestra en la página web si no tienes permiso para ver las imágenes en grande, que será lo habitual. La firma irá en esas "previews" para no estropear el original, al que normalmente no tendrás acceso.

Leer más…

ZOPE es, posiblemente, el abuelo de los servidores de aplicaciones escritos en Python. Muchas y buenas ideas han salido de él. Tuvo su época dorada en la primera mitad los 2000. Hoy en día sigue en mantenimiento, aunque moviéndose rápidamente hacia la irrelevancia, salvo por excepciones honrosas como Plone.

Pero el legado pionero de ZOPE sigue vivo. Productos como ZODB o zc.buildout son utilizados a diario por millones. Frameworks como Piramid se basan en los principios de diseño de ZOPE.

Aunque ZOPE sigue en mantenimiento, está desapareciendo poco a poco y, ciertamente, todo el tiempo invertido en él es tiempo desperdiciado. Lamentablemente, mi web principal se basa en ZOPE. He invertido casi 20 años en el proyecto, y migrar a cualquier otra cosa es costoso y arriesgado.

Por tanto, no recomiendo ZOPE a nadie con un proyecto nuevo por su empinadísima curva de aprendizaje y su cuota de mercado en extinción. Pero yo soy perro viejo. ¡Qué se le va a hacer!.

Así que cada vez que me planteo una mejora en mi página web tengo que valorar siempre si invertir tiempo en mi instalación ZOPE o morder la bala por fin y migrar a algo hipotéticamente mejor pero que en realidad no necesito.

La situación se ha vuelto a repetir una vez más recientemente: Firma de imágenes. ¿Ampliar ZOPE o migrar toda mi infraestructura a un hipotético Edén?

Leer más…

Los OpenBadges son un estándar abierto promovido por Mozilla para la difusión de certificaciones seguras y verificables en el mundo digital actual.

Básicamente consisten en un fichero gráfico (un PNG o un SVG), una insignia, que contiene en su interior metadatos adicionales. Estos proporcionan información sobre el propietario de la insignia, qué certifica, cuándo se emitió y por quien, cuándo caduca (si es el caso), etc.

Para un visitante normal, la insignia es un simple gráfico. Pero con las herramientas adecuadas no solo podemos ver sus metadatos, sino también verificarlos. El flujo sería más o menos el siguiente:

Leer más…

En mi artículo anterior explico muy por encima qué es DNSSEC y por qué es importante para la seguridad de Internet. El tema tiene mucha miga y planeo escribir unos cuantos artículos más. Hoy hablaremos de cómo podemos realizar una validación DNSSEC manualmente. Con nuestros deditos.

Lo primero que hay que entender es que DNSSEC utiliza dos claves. La KSK: Key Signing Key y la ZSK: Zone Signing Key. La primera clave, KSK, es una clave de larga duración (por ejemplo, uno o dos años) y es la clave que se va a utilizar como anclaje con el resto del árbol DNS.

Los registros DNS en sí están firmados por la ZSK, firmada a su vez por la KSK. La ZSK es una clave más corta y con una duración muy limitada (por ejemplo, dos semanas o tres meses). La utilidad de este esquema es que las firmas en los registros DNS son más pequeñas y que la clave KSK puede mantenerse offline o, por ejemplo, en un dispositivo Hardware Security Module (HSM).

En resumen, los registros DNS están firmados por la ZSK actual de la zona. La ZSK en sí se firma con la KSK de la zona. El hash de la clave pública de la KSK se comunica a la zona DNS padre, que lo incluirá en registros DS para completar el anclaje seguro.

En la práctica, las cosas son bastante complicadas. Una zona puede tener varias KSK y, sobre todo, varias ZSK. Las claves caducan y hay que reemplazarlas por otras nuevas, todo mientras el DNS sigue funcionando. El key rollover es complejo y crítico en el funcionamiento de DNSSEC. Sí, lo habéis adivinado: es tema de un artículo futuro :-).

Para verificar un resultado DNSSEC hay que seguir la cadena y validar todas las firmas digitales y todos los anclajes. Veámoslo.

Leer más…

Casi cualquier usuario de Internet, no digamos ya administradores de sistemas, sabe lo que es el DNS. El Domain Name System consiste, básicamente, en una base de datos distribuída de cobertura mundial que, para el común de los mortales, se encarga de convertir nombres aptos para seres humanos a direcciones IP, que es lo que realmente entiende un ordenador. Así, podemos escribir en nuestro navegador http://blog.jcea.es/, en vez de pedirle que se conecte a la dirección IP 10.71.238.11.

Teniendo en cuenta la longevidad y la sencillez del sistema DNS, resulta sorprendente (demos a sus creadores el crédito que se merecen) lo bien que suele funcionar en la práctica. De todos los protocolos de nivel de aplicación de Internet, el DNS debe ser el más fundamental y el único que no falla nunca :-).

Al menos no falla de forma accidental, porque siendo un protocolo nacido en una era más pacífica y tranquila de Internet (como ocurrió con el correo electrónico), la seguridad no entraba dentro de los puntos a ser considerados. Pero hoy en día Internet es una infraestructura crítica y zona de guerra permanente. El DNS tradicional es muy vulnerable a ataques y todos los demás servicios se sustentan en el DNS. Los cimientos están podridos.

Hace 10 años, en 2004, se publicó el RFC 3833: Threat Analysis of the Domain Name System (DNS). En él se describen modelos de ataque inherentes al propio protocolo DNS. Durante los años se han sucedido los ataques al protocolo DNS, débil por diseño. Y una vez que se consigue contaminar la caché de un servidor DNS importante, como el de un gran ISP, se puede afectar al funcionamiento Internet de millones de usuarios durante días, aunque el ataque haya durado unos pocos segundos. Dan Kaminsky, por ejemplo, se hizo famoso en 2008 por demostrar que los ataques de DNS spoofing eran prácticos. Y, de hecho, fáciles de llevar a cabo. Una búsqueda simple en Google muestra decenas de miles de tutoriales sobre cómo hacerlos.

No son ataques teóricos. Un ejemplo que ha transcendido a los medios: Google’s Malaysian Domains Hit with DNS Cache Poisoning Attack. El reciente caso de censura de Twitter en Turquía muestra a las claras la fragilidad de la infraestructura DNS actual y el valor que puede aportar DNSSEC.

El hecho es que el protocolo DNS es inseguro por diseño. Pero todo Internet depende de su buen funcionamiento.

Leer más…

With the cloud and the ubiquitous free services we as users have surrendered to the feudal lords. We surrender our independence and rights to feudal lords in exchange for free but valuable (for us) services.

With the exception of people like me, always worried about privacy, security and personal rights, most people are OK with that. "We don't have anything to hide", they say. And that can be true in the sense of you not being a serial killer or cheating on your partner, but sure you don't share your tax forms, your private pictures or your home security cameras with everybody online. So yes, you have things to hide. Not because you are doing anything wrong, but because some things are just private. Nobody else's business.

Most of the time we, as vassals, live an easy life under our lords' protection. We get useful services for free (email, picture hosting, blog hosting, collaboration tools, social network management, ...) in exchange for commercial exploitation of our personal profiles and our acquaintances' ones. Fair enough, if you know what you are getting into, and you decide that that is OK.

The rule under feudal lords ruling is simple: Do whatever we say, don't stand out. Don't get noticed. Most of the time that is easy enough. But sometimes you are simply unlucky.

Leer más…

En un artículo anterior titulado El triste estado de las revocaciones SSL en Internet comento que Online Certificate Status Protocol (OCSP) tiene varios problemas:

1. Un serio problema de privacidad para el usuario final: cada vez que entras es una página web HTTPS, tu navegador hará una consulta OCSP, filtrando el hecho de que estás entrando en esa web en concreto. Esa información llega a la entidad de certificación que "avala" el certificado SSL de ese servidor y, naturalmente, es accesible también para todas las redes intermedias entre ella y tu ordenador
2. El volumen de tráfico en la entidad de certificación es proporcional al volumen de usuarios de una web determinada. Si una web tiene éxito, la entidad de certificación tendrá un coste adicional, sin ningún beneficio.
3. Para el usuario final, la consulta OCSP supone añadir latencia, porque el navegador tiene que saber que el certificado SSL no ha sido revocado antes de mostrarte el contenido de la web.
4. Si la entidad de certificación no responde a la petición OCSP, el navegador debe elegir qué hacer. Ahora mismo, la configuración por defecto suele ser soft-fail. Es decir, si la respuesta OCSP es "certificado revocado" o "certificado desconocido", el navegador nos denegará el acceso, pero si no nos llega ninguna respuesta OCSP, el navegador considerará que todo ha ido bien. Evidentemente, si estamos sufriendo un Man in the Middle o una impersonación, el atacante nos filtrará OCSP.

Leer más…

Este artículo está inspirado en el muy recomendable podcast Security Now, más concretamente en los programas Certificate Revocation Part 1 (29 de abril de 2014), Certificate Revocation Part 2 (6 de mayo de 2014) y Listener Feedback #187 (13 de mayo de 2014). Tenéis las transcripciones online.

Latch es un producto de Eleven Paths publicado a finales de 2013. Se trata de un producto curioso: Es un mecanismo de seguridad adicional que permite que un usuario active y desactive el acceso a funciones arbitrarias proporcionadas por un tercer jugador. Dicho tercer jugador consulta a Latch cuando un usuario quiere hacer una acción protegida, para verificar si dicho usuario se ha cerrado a sí mismo el acceso o no. Y el usuario controla Latch desde su móvil.

Confieso que no le presté ninguna atención cuando salió la noticia. No le veía el interés para mí. Pero durante la RootedCON 2014 estuve charlando un rato con Chema Alonso y me dio un par de casos interesantes que despertaron mi interés (control de pagos por Internet con la tarjeta de crédito, por ejemplo). Luego la charla de Chema en la RootedCON, siendo el showman consumado que es, metió el gusanillo en la audiencia. Servidor incluído. El manejo desde el móvil me enamoró.

El día siguiente a la RootedCON me colapsé en la cama todo el día, tras una semana de gripazo, medicación en vena y madrugones desacostumbrados. Físicamente agotado, pero con la mente despierta (y hambrienta, puñetera maldición), me pasé la tarde entera empapándome de Latch, sus SDK, su API, etc.

He de decir que lo que vi no me gustó. El código publicado parece apresurado y da la impresión de que no está siendo mantenido de forma activa. El SDK Python no verifica el certificado SSL del servidor. La aplicación iOS era muy limitada comparada con lo que mostró Chema Alonso en su presentación (él mostraba la versión Android, y en honor a la verdad la versión actual de iOS ha mejorado bastante). Lo cierto es que tengo mucho que decir sobre todo esto, pero me lo reservaré para un futuro artículo. Una cosa que sí puedo decir es que mis quejas, en su inmensísima mayoría, son muy fáciles y rápidas de resolver si Eleven Paths está por la labor. Es decir, no son defectos estructurales de Latch, sino problemas concretos y solucionables con muy poco trabajo. Con todo, Latch es un producto intrigante.

Leer más…