Timestamp con TSA con HTTP

Si quisiéramos enviar una request a un timestamp server, ¿Cómo lo harías? Yo conozco una TSA que antes me funcionaba (las pruebas que hacía tiraban) hasta que hace poco me encontré con que ya no tiraba el método empleado. Al menos tengo pruebas realizadas que daban resultado y ahora ya no. ¿Por qué? Porque me ahora me está pidiendo que le envíe los datos por post. [Actualización antes de publicar] Porque aun pudiendo haber funcionado con el método de más abajo, el problema no era que no estuviera llamando por post. Realmente en alguna prueba debí de quitar algún carácter y dejó de funcionar [fin actualización] Si accedemos directamente nos encontramos con:

The GET method is not allowed. Try with POST!

La siguiente pregunta es: ¿Cómo sé qué parámetros tengo que pasasrle si quiero continuar usando curl? Hice lo que todo el mundo haría en su sano juicio: leerse la mitad de la RFC1381. Es cierto que hay muchas cosas que se te escapan hasta que encuentras la sección que dice:

There is no mandatory transport mechanism for TSA messages in this document. The mechanisms described below are optional; additional optional mechanisms may be defined in the future.

Y te enumera las distintas formas. Entre las mencionadas están e-mail, fichero (con extensión .tsq o Time-Stamp query), sockets y el que estaba buscando:  HTTP(S). Pero la información que muestra ya la sabemos, porque lo estábamos usando. Pero a partir de otra búsqueda pude encontrar en Stackoverflow que hablaban de un "navegador" específico para estos menesteres. Por lo tanto, para enviar a una TSA un fichero .tsq hay que usar la herramienta tsget.

En teoría deberíamos de poder acceder a ella directamente porque se espera que esté en el path. Pero en mi caso la encontraba. Ni siquiera probando whereis. Así, con otra búsqueda más, apareció en /usr/lib/ssl/misc/. Además, lo más curioso de todo es que el comando man sí que mostraba el manual.

Ahora que ya la tenemos, nos encontramos con un nuevo bache: esta herramienta está hecha en perl y nos muestra un mensaje de error:

"&WWW::Curl::Easy::global_cleanup called at ./tsget line 196."

Aunque después descubrí que sí que había funcionado con este mensaje, hice una nueva búsqueda en la que me encontré con que se podían instalar dos cosas para eliminar el mensaje:

• Una librería para curl y openssl: 
• apt-get install libcurl4-openssl-dev
• Una librería de perl:
• perl -MCPAN -e "CPAN::Shell->force(qw(install WWW::Curl::Easy));"

Aunque en una de ellas empezó a pedirme que configurara ciertos parámetros y me ofreció hacer casas automáticamente, primero decidí hacerlo a mano. Pero terminé desistiendo y cancelé el proceso para más tarde repetirlo y permitirle hacerlo automáticamente. También hay que tener en cuenta que es posible que te haga falta instalarlo para cada usuario (lo hice con root y parecía que me también me pedía ejecutar el comando de perl para mi usuario mortal).

Una vez instaladas las cosas y encontrarme con que seguía saliendo el mensaje, pero también obtenía resultados, se puede explicar las distintas formas de llamar a la TSA. 

¿Qué estaba haciendo antes y cómo se puede hacer con el nuevo comando?

Antes estaba ejecutando esta línea, pero sin los caracteres en negrita (con ellos funciona, sin ellos no):

cat miFich.tsq > curl -s -S -H "Content-Type: application/timestamp-query" --data-binary @- http://tss.accv.es:8318/tsa -o result.tsr

Con tsget se podría ejecutar de esta forma:

./tsget -h http://tss.accv.es:8318/ts -o /ruta/destino/fich.tsr /ruta/fichero/query.tsq

Ahora si se quiere se podría añadir la ruta de esta herramienta al $PATH para no depender de tener que poner la ruta completa de los ficheros de entrada/salida. Para eso tendremos que editar el fichero /etc/profile. Para mi usuario mortal funciona, que es lo importante.

¿Qué podemos contar de todo esto?

• Que para estas cosas nos tenemos que acordar de mirar todos los comandos letra a letra, que a veces leemos lo que queremos, no lo que realmente hay escrito.
• Que para trabajar con una agencia de sellado de tiempo, además de curl tenemos tsget.
• Que si una cosa no funciona, siempre puedes terminar buscando una posible solución en el RFC del tema en cuestión, si es que existe. En mi caso me lo leí hasta la mitad y como mínimo alguna cosa curiosa aprendes aunque no consigas solucionar el problema. 

Trust no one, user-agent.

Este es uno de esos que lo escribí a medias tiempo ha y creo que va siendo hora de revisarlo bien, terminarlo (si es que hace falta terminarlo) y editarlo bien, dado que el original estaba escrito desde el móvil.

--

Como si fuera Garganta Profunda en esa (para mí) magnífica serie de televisión Expediente X, "no confíe en nadie, agente Mulder", tendríamos que decirle lo mismo a nuestros navegadores.

Se me ha ocurrido todo esto a raíz de un artículo de SbD, y escrito por Juan Garrido, Juanito, @tr1ana.

Seguro que ya os he hablado alguna vez de las CAs. Son las entidades que se encargan de suministrar los certificados digitales. Si alguien ha llegado aquí y no sabe qué es eso, es un fichero que de guarda en un lugar especifico del ordenador y que hace que cuando visitas una página que lo usa, salga el famoso "candado".
Sí, está explicado de una manera muy, muy simple y no muy exacta. No es (¿era?) fácil hacerlo desde el móvil.

¿Y cómo sabemos si es bueno o no? Precisamente porque si está guardado en ese lugar, llamado almacén, es que confiamos en él. Y, si confiamos en él, el sistema no nos alterará de nada sospechoso. Por lo que, si aceptamos uno de estos sin ser conscientes, el hecho de que tu navegador ponga el candado no servirá de nada. Y mucho menos si se acepta que se guarde permanentemente en el almacén. Tengamos en cuenta que normalmente ese almacén suele pertenecer al sistema operativo. Aunque, en ocasiones, un navegador (como por ejemplo Firefox), tiene su propio sistema de almacenamiento y obvia el que tiene el sistema operativo.

Además, a veces, los navegadores, o el propio sistema, preguntan a la CA si su certificado sigue siendo valido. Pongamos un ejemplo: una CA, que en teoría, es seria, se ve comprometida. Una vez se dan cuenta, ésta puede avisar de que lo que ha emitido ya no es válido. Cada navegador reacciona de una forma un otra según los sistemas para preguntar o si le llegan o no las respuestas.

La historia está en que algunos no hacen nada, no avisan ni ponen medios para activar el aviso. Otros, como en el post de Juanito, se puede activar.

Total, que volvemos al principio: la confianza en la CA que ha emitido ese certificado. Porque :¿de qué sirve tener el candado o la "s" al final del http si estamos confiando en alguien en el que no deberíamos confiar? Al fin y al cabo, eso es lo que suele pasar en los MITM (Man In The Middle).

Me faltaría explicar en dos líneas, para el que no lo sepa, que esa entidad emisora/CA es capaz de descifrar aquello para lo que ha sido emitida además de poder hacerlo para todos sus hijos. Una vez más, muy resumido.

¡Y todo esto, por asociación de ideas del post de Triana! De todas formas, si tienes dudas o no has entendido algo, por favor, no tengas reparos en poner un comentario e intentaremos explicarlo lo mejor posible.