Hugo's blog

a.k.a. @huguei

0 notes &

Twitter API with TLS enforcement

I maintain several twitter search monitors that allows keeping several peolple updated with mentions of keywords.

For that, I use the excellent perl module Net::Twitter::Lite::WithAPIv1_1 from many months, without any problem.

However, since yesterday it was obtaining only a “403: Forbidden” code from the Twitter API. I searched through the web and only found a report several days ago with the same problem (still unresolved).

But my good friend @chidalgo found the solution: since yesterday, api.twitter.com is restricting access only with TLS.

Luckly, the Net::Twitter::Lite::WithAPIv1_1 only requires a “ssl => 1” option to turn on TLS traffic, and voila! The search monitor is back.

Filed under dev twitter

0 notes &

RFC6950: Architectural Considerations on Application Features in the DNS

http://www.rfc-editor.org/rfc/rfc6950.txt

Desde hace mucho tiempo que el DNS se ha visto como un lugar atractivo para almacenar todo tipo de información, fuera del propósito original de transformar nombres de hosts en direcciones IP. Quizás basado en su ubicuidad y éxito como base de datos distribuida es que es un candidato directo para su utilización en otras aplicaciones. Sin embargo, el diseño del DNS cumple ciertas características que son inherentes a su uso original, y aunque puedan aparecer ciertamente otros usos no previstos que aprovechan con éxito sus capacidades, hay otras arquitecturas que rompen criterios básicos de diseño del DNS, y que es complejo adaptar para sus propios usos. Muchas veces se llega a callejones sin salida, o a forzar comportamientos que resultan artificiales.

El RFC6950 lo que busca es dar consejos y explicar a desarrolladores que tienen la idea de usar el DNS para almacenar su información, en qué propiedades deben fijarse para tomar la decisión. Hay ciertos parámetros básicos del diseño del DNS que indican claramente si una aplicación se encontrará con problemas.

El primer caso exitoso es uno muy antiguo. Se trata de la idea de almacenar el servidor de correo asociado a un dominio en un registro especial, el MX. Fue tan exitoso que se generalizó su formato para permitir ubicar muchos otros tipos de servicios, con el registro SRV.

Otro ejemplo muy documentado en el RFC es el almacenaje de números telefónicos en el DNS, ENUM, que también utiliza un mecanismo generalizado llamado Dynamic Delegation Discovery System, DDDS. Inicialmente fue una idea completamente alineada con el DNS, pero con el uso han surgido nuevos requerimientos que han estrujado el sustrato que otorga el DNS, y no queda muy claro si ya sería hora de usar una nueva infraestructura y protocolo para ciertas funcionalidades, tales como el manejo de números privados, administración de grupos de troncales de origen, etc.

El capítulo 5 del RFC6950 incluye un checklist de propiedades que indican a un desarrollador si el DNS es un buen lugar para sus datos:

  1. si los mecanismos convencionales de caching del DNS le sirven sin tener que realizar modificaciones en los intermediarios (caches, resolvers, forwarders, etc), considerando que las respuestas de los autoritativos solo se basan en la tripleta (nombre, tipo, clase);
  2. las llaves de indexación de los datos no violan la sintaxis o semántica de los nombres de dominios,
  3. se resuelven nombres completos, no fragmentos;
  4. las respuestas no dependen de la identidad en la capa de aplicación del que hace la pregunta,
  5. las aplicaciones usan el DNS como asistencia para comunicarse con un servicio cuyo nombre es resuelto a través del DNS.

También se indica una lista de las cosas que de ser requeridas por la aplicación, son un signo de preocupación. Acá se incluye por ejemplo las aplicaciones que consideran que existen límites administrativos en los puntos de delegación del DNS, las respuestas muy dependientes de quién hace la pregunta, el almacenaje de respuestas con un tamaño muy grande, entre otras.

Este documento es originado por el Internet Architecture Board (IAB), por lo que no es un RFC clásico en el sentido de haber sido escrito en un working group, ni tampoco indica un consenso del IETF completo. Un documento originado por el IAB es redactado y editado por expertos en el área, y aunque es sometido a discusión a nivel general de toda la IETF, finalmente solo representa la visión de los integrantes del grupo IAB.

Filed under IETF DNS arquitectura aplicaciones

0 notes &

RFC6975: Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)

Dentro del protocolo DNSSEC existen ciertas operaciones criptográficas que pueden variar, dependiendo de la implementación escogida por el firmador de una zona. Por ejemplo, una firma RRSIG puede ser hecha tanto usando RSASHA1, RSASHA512, como ECC-GOST; o bien todas, a gusto del administrador de la zona.

Lo mismo ocurre para el cálculo de los hashes de DS y NSEC3, que pueden ser escogidos de entre varias opciones.

Read more …

Filed under IETF DNS DNSSEC criptografia

0 notes &

RFC6944: Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status

Este artículo es parte de la serie “RFCs de IETF” que en forma periódica comentará en idioma español los últimos RFCs publicados, en especial los que tienen relevancia con la operación de TLDs, DNS y dominios.

http://www.rfc-editor.org/rfc/rfc6944.txt

Pese a que es desde hace sólo un par de años que DNSSEC comenzó su despertar a nivel de producción mundial, principalmente con la firma de la raíz del DNS -influenciado a su vez por los nuevos ataques que aparecieron al protocolo-, los RFC de DNSSEC tienen 8 años de publicados. La criptografía también tiene sus propios plazos y épocas de validez. Un algoritmo que era seguro hace 5 años, hoy puede que ya no lo sea, tanto porque se le encontró una vulnerabilidad en implementación, como porque el avance en el poder computacional ha hecho más probable un ataque de fuerza bruta. Por una u otra razón, es necesario ir revisando de tiempo en tiempo la validez y fortaleza criptográfica de los algoritmos.

Read more …

Filed under DNSSEC seguridad

0 notes &

RFC6962: “Certificate Transparency”

Este artículo es parte de la serie “RFCs de IETF” que en forma periódica comentará en idioma español los últimos RFCs publicados, en especial los que tienen relevancia con la operación de TLDs, DNS y dominios.

http://www.rfc-editor.org/rfc/rfc6962.txt

Con la publicación del RFC6962: Certificate Transparency, continúan las reacciones que se han tomado frente a las vulnerabilidades detectadas los últimos años a la infraestructura PKI (Public Key Infrastructure). Los últimos casos de certificados incorrectamente emitidos, duplicados o fraudulentos, han llevado a la creación y adopción de soluciones técnicas que permiten una mitigación del problema, y una reacción rápida ante su ocurrencia.

Read more …

Filed under PKI certificados HTTP IETF RFC seguridad

0 notes &

eToken storage capacity for DNSSEC keys

In a previous post I wrote about my experience setting up a DNS signed zone using OpenDNSSEC with an USB “Aladdin eToken Pro 64k” HSM.

This time I run some tests in the eToken to try the storage capacity with keys.

Executive summary: 21 keys of 2048 bits, or 25 keys of 1024 bits.

The eToken can be formatted with a special option  ”Load 2048-bit RSA key support” (in Advanced Settings while initializing eToken). But also you need to manually set the number of reserved RSA keys in the same option screen, with a number more than 21 of 2048-bit keys (otherwise it only allows you to create 4 keys!)

With this options, the eToken is created with 31,155 bytes of card free space, out of 65,536 bytes of total memory capacity. Every 2048 bit RSA key takes 1,352 bytes of capacity, giving a maximum of 21 keys.

The test suite that comes with OpenDNSSEC (ods-hsmutil) gives OK creating keys with 512, 768, 1024, 1536 and 2048 bits. All these keys works with RSA/SHA1 and RSA/SHA256 signatures, and the 1024, 1536 and 2048 keys also work with RSA/SHA512 signatures. The tests are also OK with random bits generation in 1024 bytes, 32-bit and 64-bit.

There’s no support for 4096 bits keys.

If you format the eToken without 2048 bits support, you can create up to 25 keys, taking care of “manually reserve the number of keys” at initialization time.

0 notes &

Setting up your website (and DNS) for IPv6

(English translation from Spanish of a previous post).

There is an important news website in Chile that takes long to load on my browser. An analysis revealed there is a problem with the DNS records for IPv6.

The problem is the DNS servers for the domain of this website does not answer anything for an AAAA query (record type for IPv6 addresses), resulting in a “timeout” from customer’s viewpoint. This is an incorrect behavior. If a zone doesn’t have an AAAA record for a name, it must answer an empty response immediately (return code NOERROR, with answer count = 0). Or if it is an old name server, with no knowledge of AAAA records, with an RCODE indicating it doesn’t understand the query. But in both cases is an immediate response, which allows to take proper action. This “no response” behavior may be caused by a firewall in front of the DNS servers that is allowing packets for certain known query types , and is discarding anything else, forbidding the name server from handling the query.

As a consequence of “chained timeouts” is that my browser takes FORTY-FIVE seconds to load the main page. This because I have IPv6 connectivity, so the browser sends both A and AAAA queries to my local resolver. Queries for A records respond immediately, but for AAAA times out after 5 seconds. The failed query is retried 3 times, making a total of 15 seconds only to resolve the name of the site. After that starts loading the page, which contains scripts in another web site from the same domain, again taking 15 seconds to resolve, and finally images on other subdomain, which adds the last 15 seconds.

The latter behavior could also be a browser error, which unnecessarily delays the display of a page with an image, but the scripts must be loaded before the rest.

Moreover, there is unfortunately a very short TTL, which requires a new query every 30 seconds, and even worse, one of the NS records in the zone has a private address, making 1 / 3 of the queries to fail.

The recommendation is to check all name servers about how they respond to AAAA queries, even if they don’t have IPv6 connectivity, because customers connected via IPv6 will query for those records and they will perceive the site as slow or down.

0 notes &

Preparando su sitio web (y DNS) para IPv6

Existe un sitio web de noticias importante en Chile que es muy lento de cargar en mi navegador. Un análisis reveló que hay un problema con los registros DNS para IPv6.

El problema es que los servidores DNS de los dominios de este sitio web no responden nada por una consulta de registro “AAAA” (que son las direcciones IPv6), resultando en un “timeout” del punto de vista del cliente. Este es un comportamiento incorrecto. Si las zonas no tienen registros AAAA, deberían enviar una respuesta vacía en forma inmediata (NOERROR, con answers=0). O por último si se trata de un servidor de nombres muy antiguo, que no tiene conocimiento de los AAAA, con un RCODE que indica que no entiende la consulta. Pero en ambos casos se trata de una respuesta inmediata, que permite tomar las acciones correspondientes. Este comportamiento de “no respuesta” puede deberse a un firewall en frente del DNS que está filtrando los paquetes con ciertas consultas “conocidas”, y quizás descarta cualquier cosa que no entiende, sin permitir que sea el propio servidor de nombres el que lo haga.

Producto de un “timeouts encadenados” es que en mi navegador el sitio demora CUARENTA Y CINCO segundos en cargar. Esto porque yo tengo conectividad IPv6, y entonces el navegador envía tanto consultas A como AAAA a su resolver local. Las consultas A responden de inmediato, pero las AAAA se cancelan a los 5 segundos al no obtener respuesta. Este comportamiento se repite 3 veces, con lo que da un total de 15 segundos solo en resolver el nombre principal del sitio. Luego de esto comienza la carga de la página, el que contiene scripts en otro sitio web del mismo dominio, que nuevamente demora 15 segundos en resolver, y finalmente imágenes en otro subdominio, que suma los últimos 15 segundos.

Este último comportamiento podría tratarse además de un error del navegador, que demora innecesariamente el despliegue de una página por una imagen, pero los scripts deben ser cargados antes que el resto.

A esto se suma lamentablemente un TTL muy pequeño del registro final, que obliga a una resolución nueva cada 30 segundos; y peor aún, uno de los NS para el balanceador de carga posee una dirección privada, con lo que 1/3 de las consultas falla.

La recomendación es la revisión de todos los servidores de nombre en su comportamiento frente a consultas AAAA, incluso aunque aún no se utilicen servicios en IPv6, porque serán los clientes quienes lo comenzarán a utilizar, y enviarán consultas DNS por estos registros en todos los sitios web que visiten.

0 notes &

I won a pie!

Well, an ascii pie meanwhile.

I’m a fan of the DNSSEC blog of SURFNET, a non-profit ‘task organisation’ forming part of SURF, the Dutch higher education and research partnership for ICT-driven innovation.

From almost 5 months they’re publishing in their blog all the steps they’re taken in implementing DNSSEC in their networks, where they provide recursive DNS service to their clients. I think there’s a lack of information yet for the validation side of the dnssec infraestructure, so blogs like this are much needed.

Some weeks ago they posted a quiz. A graph of the validation rate they were seeing in their resolvers. The curve shows a great drop in one week, and there was no clear reason for that. I realized that besides that drop, was a spike one month or so before. If you follow the curve was steadily growing, but in one month was a huge hill, and then it continues with the normal grow. So I thought that something had to be over counting in that weeks. I remembered that .SE and .GOV were in that weeks adding their keys to the root, and they had the keys also in the ITAR before, so in those weeks their keys were in both places at the same time. As surfnet are using the root and ISC’s DLV as trust anchors (who use ITAR), so maybe the spike was for a double counting.

The theory sounded plausible, but there was a confirmation step with the people from Unbound (the server software they use), and it was confirmed. There’s a double validation because the DLV lookups are done using recursion.

image

There was an attempt to give me a real pie, but sadly I couldn’t find any store in my country who accepted orders from outside. But an ascii pie is enough and I’m happy to have helped the guys from surfnet!