Enlaces interesantes sobre OpenBadges (julio 2015)

Algunos enlaces interesantes sobre OpenBadges:

Pasarela RSS -> Twitter que también sube imágenes asociadas

Hace un año publiqué un artículo sobre cómo enviar las actualizaciones de tu blog directamente a Twitter: Ten tu propia pasarela RSS -> Twitter. Ese artículo es imprescindible para entender este. Léelo primero.

El código que publiqué en Ten tu propia pasarela RSS -> Twitter ha funcionado bien durante este tiempo pero, consciente de que la gente reacciona mejor a los mensajes de Twitter cuando tienen imágenes asociadas, quería añadirle esa funcionalidad. Añadir la capacidad de publicar imágenes.

Hay varios ejemplos en Internet sobre cómo hacerlo pero usan el API antiguo de Twitter, marcado como obsoleto. La librería que utilizo soporta la versión nueva del API, pero su uso no estaba documentado por ningún sitio.

Esto está solucionado con un poquito de presión del pesado de siempre :-) :

Con una librería a la altura y la documentación actualizada, ya solo queda picar código.

Leer más…

OCSP y el depender de la profesionalidad ajena

He escrito ya antes sobre Online Certificate Status Protocol. Puedes ver el tag OCSP de este blog. En concreto en El triste estado de las revocaciones SSL en Internet expongo el hecho objetivo de que la mayoría de los navegadores web no comprueban la revocación de certificados o la comprueban de forma muy... peculiar.

Por ejemplo, con la configuración por defecto, un navegador normal que hace verificaciones OCSP hace lo siguiente:

  1. Hay navegadores que no hacen comprobaciones OCSP para certificados X.509 normales, solo para los certificados EV. Por ejemplo, Apple Safari (el navegador de Mac OS X y de iOS). Ni que decir tiene que la inmensa mayoría de los certificados X.509 no son EV.

  2. Supongamos que el navegador decide hacer una consulta OCSP. En este caso, si el servidor OCSP no responde en absoluto, no pasa nada. El certificado X.509 se dará por bueno. Esto es una vía de ataque evidente si nos conectamos a través de una red bajo el control de un ente malicioso.

    ¿Por qué se hace así? Porque no es raro que lo servidores OCSP de las entidades de certificación estén caídos o saturados. Es decir, no recibir respuesta a la petición OCSP es rutina. Como no es aceptable que el usuario del navegador reciba avisos de seguridad o se le deniegue el acceso a la mitad de la webs que visita cada día, los navegadores han sido prácticos y aceptan el hecho habitual de que no obtener una respuesta OCSP no tiene por qué indicar nada feo (al margen de la profesionalidad dudosa de esa entidad de certificación, claro).

  3. Una petición OCSP supone una pérdida de privacidad para el usuario. Explico el problema y la solución en mi artículo OCSP Stapling y la privacidad de tus usuarios.

    Resumiendo, el servidor web de un dominio accesible por HTTPS puede hacer una petición OCSP para su propio certificado X.509, cachear ese resultado durante unas horas e incluir esa respuesta en la negociación TLS entre el servidor HTTPS y el navegador. De esta manera el navegador se ahorra la petición OCSP y el tiempo de espera, y el usuario gana privacidad.

    Una situación Win-Win de libro.

Leer más…

64 bits OpenSSL compilation and 32/64 bits PERL dependencies

I sent the following email to OpenSSL mailing list the Mar 19, 2015:

When compiling a 64 bit OpenSSL 1.0.2a with a 32 bit PERL interpreter I get this error:

./config zlib-dynamic shared
make
[...]
/usr/local/bin/perl asm/ghash-x86_64.pl elf > ghash-x86_64.s
Integer overflow in hexadecimal number at
asm/../../perlasm/x86_64-xlate.pl line 201, <> line 890.
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC
-DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -O3 -Wall -DL_ENDIAN
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
-DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
-DECP_NISTZ256_ASM -c  -o ghash-x86_64.o ghash-x86_64.s
ghash-x86_64.s: Assembler messages:
ghash-x86_64.s:890: Error: junk `.15473355479995e+19' after expression
<builtin>: recipe for target 'ghash-x86_64.o' failed
make[2]: *** [ghash-x86_64.o] Error 1

In line 890 I have this:

subq    $48,%rcx
movq    $1.15473355479995e+19,%rax  <<<<<<<<<<<<<<<<<<
movdqu  48(%rsi),%xmm14
movdqu  64(%rsi),%xmm15

Comparing that line in other machines where compilation is done correctly, I see this:

movq    $11547335547999543296,%rax

Notice that "11547335547999543296" is approximately 1.15473355479995e+19 in scientific notation.

When doing "perl -e 'print(11547335547999543296)' I get:

11547335547999543296

in one machine (64 bits), but

1.15473355479995e+19

in the other machine (32 bits).

The number is being promoted to scientific notation and compilation will fail.

Yes, in Solaris I can mix 32 and 64 bit binaries in the same running system. It is standard practice and the reason I am compiling OpenSSL both in 32 and in 64 bits.

Replacing the scientific notation value with "11547335547999543296" the code compiles correctly and the tests complete 100% OK.

In the 64 bit PERL version "11547335547999543296" is printed correctly as an integer but "21547335547999543296" (first digit changed) is printed as 2.15473355479995e+19. I think that depending of implementation details (the value when an integer is "promoted" to floating point) of the PERL interpreter is bad practice and should be avoided. Maybe using literal string, of splitting the number in two halfs.

I had no useful reply in the mailing list. I patched the source code by hand and forgot about this.

Then OpenSSL 1.0.2b was published and I had the very same issue. I decided to bite the bullet and solve the issue myself.

Leer más…

Si tienes un nodo TOR, actívalo en IPv6 (2)

Hace unos días publiqué el artículo Si tienes un nodo TOR, actívalo en IPv6 explicando por qué y cómo configurar un nodo TOR para dar servicio en la red IPv6. Lamentablemente la configuración que propongo es correcta, pero se tropieza con el siguiente bug en la versión actual de TOR:

En pocas palabras, las versiones actuales de TOR no son capaces de saber su propia dirección IPv6. Como consecuencia de ello es necesario indicar de forma explícita la dirección IPv6 del nodo en la configuración. Esto es especialmente problemático si el nodo tiene una dirección IP dinámica o emplea las extensiones de privacidad de IPv6.

Ciertamente este es un problema serio en esos casos porque, básicamente, hace que no podamos dar servicio en IPv6 sin un mantenimiento manual constante. Por suerte mis nodos TOR con IPv6 tienen IP fija y no empleo las extensiones de privacidad de IPv6. Puedo poder la dirección IPv6 a mano y confiar en que me acordaré de cambiarla si en algún momento cambio de IPs o de máquinas TOR.

La configuración final es:

# Poder acceder a SOCKS5 a través del localhost IPv6
SocksListenAddress [::1]

# Poder controlar el proceso TOR a través de ambos localhosts
ControlListenAddress 127.0.0.1:9051
ControlListenAddress [::1]:9051

# Declaramos que este nodo TOR es accesible a través de IPv6
# OJO, no podemos hacer "autodiscovery" de la dirección
# propia:
# https://trac.torproject.org/projects/tor/ticket/5940
ORPort [MI_DIRECCIÓN_IPv6]:PUERTO_TOR

# Es un nodo de tránsito, no de salida
IPv6Exit 1
ExitPolicy reject6 *:*

Ahora solo queda esperar a que el directorio TOR verifique ese cambio de configuración y quede a disposición del resto de la red. Si todo va bien y el nodo ya ha sido aceptado por la red, el cambio será visible en el directorio TOR en unos pocos minutos.

El bug descrito solo afecta a IPv6, no hay ningún problema con las direcciones IPv4. Es de esperar que se solucione en el futuro. Habrá que estar atento. Roman Mamedov lo resume de forma magistral:

You thought it would be this simple. Nope, unlike every other IPv6-capable program on Earth, in Tor this syntax of "bind to all IPs" is not supported. They want you to specify the actual single IP manually, and then keep track if it changes and each time not forget to go to torrc to update it.

Algunas lecturas sobre este tema:

Si tienes un nodo TOR, actívalo en IPv6

Hace unas semanas recibí el siguiente mensaje a través de la lista de correo tor-relay: [tor-relays] Please enable IPv6 on your relay!. Resumiendo, el problema es que de todos los nodos TOR apenas el 6.3% son alcanzables a través de IPv6.

Aunque la máquina donde tenemos nuestro nodo TOR tenga activado IPv6, TOR no lo usará por defecto. Es necesario configurarlo de forma explícita.

TOR documenta los pasos a seguir en A Tor relay operators IPv6 HOWTO.

En mi caso el cambio que he hecho en la configuración de mis nodos TOR con conectividad IPv6 es añadir lo siguiente:

# Poder acceder a SOCKS5 a través del localhost IPv6
SocksListenAddress [::1]

# Poder controlar el proceso TOR a través de ambos localhosts
ControlListenAddress 127.0.0.1:9051
ControlListenAddress [::1]:9051

# Declaramos que este nodo TOR es accesible a través de IPv6
ORPort [::]:PUERTO_TOR

# Es un nodo de tránsito, no de salida
IPv6Exit 1
ExitPolicy reject6 *:*

Ahora solo queda esperar a que el directorio TOR verifique ese cambio de configuración y quede a disposición del resto de la red.

Si tienes un nodo (¡o varios!) TOR corriendo en máquinas con conectividad IPv6, deberías hacer lo mismo. Recomiendo leer el hilo [tor-relays] Please enable IPv6 on your relay! completo.

Actualización 20150620: Esta configuración no funciona por un bug en la versión actual de TOR. La configuración correcta está descrita en Si tienes un nodo TOR, actívalo en IPv6 (2).

Nada ha cambiado desde Snowden. ¿O sí?

Hace unos días se publicó un artículo interesante en Slashdot: Privacy Behaviors Changed Little After Snowden. No voy a explicar quién es Edward Snowden. Hay infinidad de páginas en Internet sobre él y podéis ver también mi presentación TOR: El árbol de la libertad debe ser regado con la sangre de los patriotas... y de los tiranos.

El argumento del artículo es que a pesar de la evidencia incontestable de la vigilancia masiva a la que nos someten los gobiernos con la excusa de protegernos, el comportamiento del público ha cambiado muy poco o nada. Esto confirma mis propias impresiones: el público en general, a pesar de decir que le importa la privacidad y la seguridad personal, no adopta medidas efectivas para preservarlas.

Se puede discutir largo y tendido sobre el tema, pero yo creo que hay dos facetas básicas para entender esta falta de reacción efectiva. En primer lugar, para la mayoría de la gente la informática es algo mágico que realmente no entiende y está a expensas de las herramientas y tecnologías que les proporcionan terceros. Existe una sensación de que no puedo hacer nada para evitarlo. El segundo factor es nuestra naturaleza acomodada y conformista, borreguil. Cuestionar todo lo que nos pasa y nos rodea interfiere directamente con la felicidad percibida y, sencillamente, la energía mental que podemos invertir en cuestionar el mundo es limitada.

En este sentido personalmente me he dado por vencido. Intentar convencer y mejorar el mundo persona a persona es ineficaz y futil.

Pero, y aquí viene lo importante para mí, existen personas cuyas decisiones afectan a millones. Tecnología que una vez desplegada mejora la privacidad y seguridad de miles de millones. Creo, en resumen, que existen personas situadas en posiciones críticas cuyas decisiones pueden mejorar el mundo de forma transparente para el público, y a pesar de dicho público.

Se me ha llamado paternalista, querer mejorar al pueblo, pero sin el pueblo. Creo, cierto es, que la mayor parte de la gente no tiene ni la preparación ni el interés para decidir sobre cuestiones de privacidad y seguridad online. Pero pienso que es muy importante señalar, también, que la diferenciación entre consumidores y creadores de tecnología no es rígida ni estática. Toda la información está disponible y cualquier persona interesada puede buscarla, formarse y contribuir.

Resumiendo, hay personas cuyas decisiones cuentan. Personas que están decidiendo y tomando medidas que nos benefician a todos. Unos pocos ejemplos:

Leer más…

LD_PRELOAD, interposición de funciones y parcheo de Thunderbird

En mi artículo "fsync" y LD_PRELOAD explico cómo utilizar LD_PRELOAD para interceptar las llamadas a una función determinada cuando esta función reside en una biblioteca dinámica (una de las muchísimas ventajas de emplear bibliotecas dinámicas).

Lo que no expliqué es cómo poder llamar a la función original. Esto puede ser necesario cuando lo que queremos es extender la funcionalidad original, no reemplazarla por completo.

En pocas palabras, queremos que el programa llame a nuestra función pero que nuestra función pueda llamar a la función original.

Leer más…

Servir WebDAV tras un proxy HTTP/HTTPS

Web Distributed Authoring and Versioning (WebDAV) es una extensión del protocolo HTTP que añade verbos adicionales para poder, por ejemplo, realizar cambios en el servidor. Lo más evidente es almacenar o modificar ficheros, pero los cambios pueden ser semánticos. Por ejemplo, modificaciones coordinadas en documentos compartidos como un calendario o una agenda telefónica.

Apache soporta WebDAV y, de hecho, es la opción que yo recomiendo en vez del vetusto FTP, por ejemplo. Hay muchas ventajas: atravesar cortafuegos con facilidad, cifrado integrado a través de HTTPS y, en general, unificación con toda la infraestructura web.

Una cosa que suelo hacer con frecuencia es dar acceso a infraestructura protegida o unificar varios servidores web bajo un árbol común. Esto lo hago a través del módulo mod_proxy de Apache. Básicamente mod_proxy puede hacer que http://www.example.com/servidorA nos enseñe el contenido del servidor A y que http://www.example.com/servidorB nos muestre el contenido del servidor B. Hacer esto con mod_proxy es trivial, rutina. El cliente web se conecta a http://www.example.com/, indica la carpeta que quiere y mod_proxy realiza una petición HTTP/HTTPS por detrás al servidor adecuado para completar la petición del cliente.

Es importante, en estas circunstancias, que los enlaces que genera el servidor A sean o bien relativos o que se cambien para que parezcan provenir de http://www.example.com/servidorA. En el contexto de mod_proxy solemos usar la directiva ProxyPassReverse. Esta directiva nos permite interceptar las redirecciones HTTP generadas por el servidor A para que parezcan provenir de http://www.example.com/servidorA.

¿Qué pasa con WebDAV?. El problema es que WebDAV nos devuelve direcciones absolutas.

Leer más…