bureado

I’ve been recently fiddling with Jasig’s CAS, an outstanding product which allows organizations to seamlessly centralize their login procedures and deploy single sign-on for the web. I call this Kerberos for the Internet, since the authorization is ticket-based (just as in Kerberos) but you don’t need to expose your KDC to the Internet or make assumptions on your user’s operating system setup.

Let’s assume you have several existing applications running in an Apache webserver. Let them be Tomcat-contained applications using mod_jk, Ruby, Python or Perl applications using either FastCGI, the mod_* preprocessors or the plethora of app-executing environments available for other programming languages. You don’t need to modify (or, as we call it, CASify) your applications to deploy centralized, controlled, single-sign-on authentication.

Since CAS only provides authentication (and not authorization, that is, it won’t grant users roles or permissions, and that makes sense since CAS is not aware of application capabilities) you only need to trust in the Web server’s REMOTE_USER HTTP variable. Of course, there’s a mod_auth_cas around for Apache which allows you to protect any part of your application with CAS. Or better yet, CAS-enable any part of your application. Talk about powerful.

Of course, you can always CASify your application by using libraries for your specific programming language which gets the ticket granting ticket and requests other tickets to CAS. In some cases, I even assume that’s the only available scenario, since inferior Web servers such as IIS might not have feasible solutions for the enterprise user.

Authentication is handled using authentication backends. Right, you weren’t expecting CAS to handle users and passwords in-memory. I’m using LDAP with OpenLDAP (of course) but RADIUS, JDBC (that is, any SQL database), X.509 client certs (fully passwordless solution, if you want to) and even SPNEGO for Kerberos are available and distributed among CAS. You’ll still need to build then using Maven but that’s not a problem (though Maven seems like an awkward build manager) and configuration is handled in detail on the Wiki.

Specially when compared with Shibboleth, which is the other big open source single sign-on player, CAS provides an enterprise-grade, robust, straightforward and easy to deploy solution to single sign-on for Web applications on the Internet. Go get it!

Ayer leía en los logs de Glenn Hauser que la Voz de América (el servicio de radiodifusión del Gobierno Federal de los Estados Unidos de América) había empezado una coproducción con Radio Martí (a la sazón, la voz de la disidencia cubana fuera de Cuba) llamada “A Fondo”, que se estaría emitiendo diariamente por SW en las frecuencias 7340, 9415 y 11625 KHz entre las 0100 y 0200 UTC. Al momento del QSL, no había demasiada información disponible sobre el programa.

Tanto Hauser como Kim Elliott argumentaban sobre el objeto del programa. El experimentado diexista Hauser hace notar que Radio Martí está siendo objeto de presión por parte del Congreso para salir del aire, y que podría tratarse de una estrategia del Gobierno para salir de esta incómoda emisora (que ellos mismos crearon) — y que el programa estaría siendo ahora dirigido a Venezuela, con el objeto de difundir mensajes de oposición al gobierno venezolano.

Hauser cita algunos pasajes de la primera transmisión (que fue ayer) como por ejemplo las protestas que se han estado desarrollando en los últimos días en Venezuela, citas de El Nuevo Herald, RCTV y otros medios ¿Será esto suficiente para calificar a VOA como una emisora de propaganda en contra de Venezuela?

Decidí sintonizar el programa hoy alrededor de las 0150 UTC (2050 EST) y lo conseguí en 11625, mucho mejor en 9415. La claridad de la voz y la intensidad de la señal eran sobresalientes, como casi todas las emisiones de Radio Martí que he escuchado tanto en Venezuela como en Ecuador. Ciertamente el programa está dirigido a una temática venezolana: en las entrevistas finales pude escuchar como hablaban de la Alcaldía de Caracas, junto a una entrevista a Milos Alcalay.

¿Mi opinión personal? El programa, al menos hasta ahora, transmite contenido de forma ecuánime. Sospechoso por supuesto el hecho de que el contenido se detalle con tanta densidad al respecto de Venezuela, siendo una emisora extranjera. Resulta curioso que ni siquiera la transmisión diaria del Canal Internacional de Radio Nacional de Venezuela, que tengo que oír por Internet porque la transmisión es un desastre¹, toca la actualidad con tanta profundidad. De hecho, la última transmisión que escuché se limitaron a leer Las Líneas de Chávez, y 2-3 noticias adicionales. Amanecerá y veremos.

¹ RNV utiliza repetidoras, como muchos servicios de radiodifusión por onda corta, en este caso de Cuba, pero la calidad de la transmisión es pésima. No dedico demasiado tiempo a hacer DX, pero nunca he podido escuchar bien a Radio Nacional de Venezuela, y he sintonizado emisoras en Argentina, Perú, Brasil, Colombia, Estados Unidos, Francia, España, Rusia, China…

Desde tiempos inmemorables, un grupo de profesionales venezolanos se ha responsabilizado por mantener el ccTLD de Venezuela, .ve. Desde hace ya varios años, esta actividad ha sido responsabilidad de NIC.ve, ahora parte de CONATEL.

A la fecha, un total de cinco servidores de nombres poseen copias y operan de forma autoritativa el ccTLD de Venezuela. Dos de ellos están fuera de Venezuela (Estados Unidos de América y Chile, específicamente), uno es hospedado por la ULA en Mérida y los dos restantes son operados por NIC.ve en Caracas. Adicionalmente, NIC.ve desarrolló y mantiene el portal, el sistema de registros, la lógica para registro y replicación (SRS, colectivamente) y el servicio WHOIS. Y de los 5 NS, 3 ofrecen servicio en IPv6 (el de EUA y los dos de Caracas) — wunderbar.

En este punto, permítanme subrayar la relevancia y necesidad de operar de forma óptima un ccTLD. En un mundo de direcciones IP, las empresas privadas, el Estado y los/as ciudadanos/as esperan poder comunicarse en Internet de una forma simplificada, usando marcas, identificadores y espacios de nombres coherentes. Hace diez años, nadie pensaba en establecer una imagen de espacios de nombres bajo el ccTLD de Venezuela. Con el pasar del tiempo los costos se hicieron razonable y NIC.ve se mantuvo siempre muy responsivo.

Calculo que NIC.ve debe estar hospedando hoy más de 150 mil dominios. Sin embargo, el hardware que están usando en sus dos NS de Caracas, está obsoleto. Más aun, ¿qué pasaría si se remueven las copias que están fuera de Venezuela? No es necesario que suponga una falla muy complicada; ns1.nic.ve y ns2.nic.ve están en el mismo sitio físico, en el mismo rango de direcciones, y en el mismo enrutador. Con 4 de 5 afuera, dependeríamos del NS (y la conectividad, seguridad física) de la ULA, no habría SRS y definitivamente el servicio se estaría viendo severamente afectado.

¿Afectado? ¿En qué le afecta a usted esto? Pongo un escenario, dirigido por ejemplo a Gobierno: imagine que toda la estrategia comunicacional del Estado en línea desaparece, incluyendo: Radio Nacional de Venezuela, YVKE Mundial, Agencia Bolivariana de Noticias… añada los sistemas del SENIAT, en fechas de declaración del ISLR. Ni hablar de CADIVI y el costo político, de la banca pública (BIV al menos) y sus sistemas al público, las alcaldías y gobernaciones con sus sistemas de consulta para la ciudadanía, Policía Nacional y sus sitios de denuncias…

Estos sistemas no funcionarían, no importa cuántas medidas de protección física y lógica, plantas eléctricas y demás medidas tomen las instituciones, y podría tomarse muchas horas y personal muy especializado y sobre todo muy comprometido (que, lamentablemente, no nos está sobrando) en paliar la situación y varios días en que cesaran los efectos colaterales. Millones de bolívares en pérdidas, muchas al bolsillo del ciudadano. Y una completa desconexión de la comunidad internacional en términos de ser los garantes y protectores de nuestro ccTLD.

Esta situación es innecesaria. ¿Cómo podemos ayudar? NIC.ve necesita nuevos equipos y una red de asociados individuales e institucionales para garantizar la sustentabilidad de la infraestructura de la red pública en nuestro país. Así mismo, necesita que abramos en conjunto los espacios para un consenso y mejoras en lo técnico (¡recuperemos el liderazgo en América Latina!) y en lo social (una idea: dominios .ve para la acción social)

Algunas preguntas: ¿por qué no hay un NS raíz para el ccTLD en CANTV? ¿en CONATEL, propiamente? ¿en ninguna de las universidades? ¿en PDVSA? ¿en CORPOELEC? ¿en los ISPs más grandes? No solamente se va a hacer más robusta la infraestructura, sino que, con la planificación adecuada, los ISPs y usuarios/as de cada una de estas instituciones se verán beneficiados/as directamentes. ¿Por qué no se ha aprovechado el aporte de las comunidades de desarrolladores para el SRS? ¿Se puede hacer? ¿Cómo nos preparamos para el agotamiento de las direcciones IP de IPv4? ¿Es sustentable nuestro soporte IPv6? ¿Cómo mejorarlo?

Canalicemos nuestras opiniones directamente al equipo de NIC.ve, por el correo electrónico nicve arroba conatel.gob.ve, pidamos que adquieran nuevos equipos y se distribuyan de forma resiliente en distintas redes públicas y privadas, propongamos organizar un Foro de NIC.ve en CONATEL, ayudemos a difundir los logros que el NIC tiene a nivel regional. A todos y todas nos interesa. Disfrutamos del servicio ahora y, si no hacemos nada, vamos a ser dolientes de lo inexistente mañana. ¡Ayudemos a NIC.ve!

Microblogging: #NICve

After my last post about timestamping according to RFC 3161, I’ve setup a Perl/OpenTSA-based Open Timestamping Authority which is open to the public -no warranties, read the disclaimer and also no provisions for handling non-trivial traffic- for tests.

Just visit tsa.g33k.com.ve and follow the instructions. I’d appreciate your feedback through either my blog, my Identi.ca/Twitter accounts (bureado) and/or tsa at g33k.com.ve

Desde hace un año he estado trabajando con OpenTSA, un conjunto de parches a OpenSSL para incorporar soporte al estampillado de tiempo en la popular suite de criptografía de llave pública.

Muy a grandes rasgos, el estampillado de tiempo llena una necesidad corporativa e individual de certificar que una data existía a partir de cierto momento en el tiempo. Adicionalmente, al estar involucrado en una infraestructura de llave pública, nos trae las ventajas de la autenticidad y la integridad. Lamentablemente, hoy en día organizaciones en todo el Mundo hacen inversiones de varios cientos de miles de dólares en tecnología para estampillado de tiempo.

Hace un año OpenTSA tenía muchos problemas, ya que se necesitaba bastante OpenSSL-fu para parchar la popular y sobre todo ubicua suite de criptografía. En distribuciones mainstream como Debian tenemos gran cantidad de software que se enlaza con OpenSSL y con muchas otras cosas (p.ej., Apache con MySQL y Postgres… out of the box) y eso dificulta mucho la accesibilidad de las tecnologías que van saliendo.

En Noviembre 2009, OpenSSL publicó la beta4 de OpenSSL 1.0.0, que absorbe el valioso trabajo de Zoltan Glozik y sus colaboradores. Junto a mod_tsa del proyecto OpenTSA original, hoy en día es más que feasible poner a operar un servicio de estampillado de tiempo bajo HTTP(S) POST que le permita a un/a usuario/a relativamente lego en cuanto a criptografía poder hacer estampillados de su data.

A la fecha, no existe en Debian un paquete disponible de OpenSSL 1.0.0. Un paquete de este tipo no puede entrar en una distribución no autocontenida como experimental ya que hay demasiados paquetes compilados contra la versión 0.9.8. Así que en principio hay dos formas de hacer esto: con chroots o máquinas virtuales o esperar que el paquete entre en unstable. Yo utilizo equivs para crear los paquetes de openssl, libssl0.9.8 y libssl0.9.8-dev y no romper el sistema de paquetes. Espere que paquetes como wget o curl que hacen uso extensivo desde su arranque de SSL no funcionen o tenga que recompilarlos.

No es necesario aplicar parches en OpenSSL. Ya OpenSSL 1.0.0-beta4 tiene soporte para timestamping. Lo único que se necesita compilar es mod_tsa para Apache, y como Apache y sus dependencias también dependen extensivamente de SSL, lo mejor es compilar directo httpd 2.2 desde los repositorios fuente. Finalmente se compila mod_tsa, que necesita una DB para guardar las estampillas: MySQL, PostgreSQL o Firebird. Sólo se necesita una tabla sin funciones complejas: MySQL es lo más NoSQL que es accesible colocar.

¿Cómo se usa? Cuando se tiene un archivo o una data, se aplica openssl ts para obtener el timestamping request y luego se manda a firmar el request en la autoridad de estampillado de tiempo. El emisor distribuye la estampilla junto con la data, y el/la interesado/a puede verificar la integridad y existencia de la data teniendo la data, la estampilla y el certificado de la autoridad de estampillado.

Una reflexión final: sigo abogando por el uso de GnuPG para garantizar autenticidad, integridad y cifrado en todas las comunicaciones vía electrónica. Sin embargo, GnuPG carece de mecanismos pulidos para estampillado de tiempo y aunque la mayor parte de nuestras comunicaciones las hacemos vía correo electrónico, ni siquiera allí podemos contar con las estampas de los servidores de correo intermedio. Por esto considero que enfocar el uso de OpenSSL sólo para TSA puede ser una muy buena idea, complementada con GnuPG.