DANE: una opción para mejorar el escenario de TLS (y sin hablar de HeartBleed)

lunes, 28 de abril de 2014


Después de la resaca de HeartBleed, ha existido una especie de "caza de brujas" buscando otros servicios (aparte de HTTPS) que pudieran estar comprometidos: servidores de correo, de IMAP, OpenVPN, entornos industriales, dispositivos embebidos, etc. Casi nadie se ha librado debido al uso masivo de OpenSSL. Una de las pocas aplicaciones que usa OpenSSL pero no está afectada (porque no usa la extensión Heartbeat) es DNSSEC, la eterna promesa del DNS. Sin embargo, sí que existe una iniciativa basada en DNSSEC que de alguna manera está afectada por HeartBleed: DANE.

Introducción

DANE (siglas de DNS-Based Authentication of Named Entities), especificado en el RFC 6698es una propuesta de intentar mejorar el escenario actual de uso de TLS y las autoridades certificadoras (CAs). Hoy en día utilizamos certificados para poder relacionar una clave con un nombre concreto (un dominio, un email, etc.), y este certificado combina la clave pública con otra información relevante para el uso de este certificado. Finalmente es firmado por otra clave (generalmente de una CA o subCA). La firma de este certificado sólo tiene sentido si confiamos en la clave que lo ha firmado, y esa es la razón por la que debemos confiar en una serie de CAs que mantenemos instaladas en nuestro sistema operativo o navegador.

De hecho, cuando hablamos del pinning de certificados ya se mencionó a DANE como alternativa, apuntando a los problemas que existen hoy en día con el modelo tradicional de las Certification Authorities (CA): hay una gran cantidad, nuestros sistemas operativos y navegadores confían por defecto en muchas de ellas y por desgracia algunas son comprometidas... además del modelo de negocio que existe detrás. Lógicamente, estas autoridades deben proteger con especial ahínco su clave privada puesto que el que la obtenga puede firmar certificados sin ningún tipo de control. Además de que generalmente no se comprueba si un certificado está firmado por una determinada CA o no (solo que esté firmado), lo que deriva en un gran problema en el caso de que una CA sea comprometida.

Por otro lado, las DNS Security Extensions (DNSSEC) son un modelo similar a las CAs donde claves en las que se confían firman digitalmente información de claves no confiables. Esto significa que para un dominio como www.elevenpaths.com, cada organización de la cadena de estructura DNS debe firmar la clave de la organización inmediatamente inferior. Por ejemplo, .com firma la clave de elevenpaths.com y los dominios raíz firman la clave de .com. Durante la validación, DNSSEC sigue esta cadena de confianza hasta la raíz automáticamente, tal y como ocurre con una validación "normal" de SSL/TLS, y donde los dominios raíz funcionan como CAs. Aunque DNSSEC ofrece varias mejoras: las claves están asociadas a nombres DNS, se pueden acceder a las claves firmadas con una simple petición DNSSEC, y lo más importante: que las claves de un dominio en concreto sólo pueden ser firmadas por las claves del dominio padre, y no por otros, como ocurre en el SSL "habitual" que varias CAs pueden firmar un mismo dominio.

DANE combina estos conceptos y aprovecha la infraestructura DNSSEC para almacenar y firmar las claves y certificados que se usan en cualquier servicio TLS.

Cómo funciona DANE

Su funcionamiento es muy sencillo. Cuando nos conectamos a cualquier servicio TLS, lo que hacemos es:
  • Por un lado, obtener la información del certificado que nos ofrece ese servicio (este es comportamiento normal)
  • Pero a la vez, se hace una petición DNS para ver si concuerda con un registro especial DNSSEC (tipo 52 o TLSA) donde se almacena la información de ese certificado. 
  • Si coincide, es que todo está bien.
Es decir, que para que el sistema funcione, sólo se tiene que modificar el registro DNS del dominio, añadiendo un campo. 
Registro DNSSEC

El formato del registro DNSSEC donde se indica la información de DANE se divide en cuatro campos principales (y sus posibles valores):
  • Uso del certificado: 
    • (0) CA Constraint, donde indicamos la CA autorizada a firmar el certificado, 
    • (1) Service Certificate Constraint donde indicamos un certificado que ser igual que en el servicio TLS, 
    • (2) Trust anchor assertion donde podemos indicar que CA vamos a usar y 
    • (3) Domain-issued certificate donde podemos indicar un certificado que será el válido (puede incluso ser uno auto-firmado)
  • Selector: la parte del certificado que se usará para comprobar con la información en el registro: 
    • (0) Todo el certificado, 
    • (1) sólo la clave pública
  • Tipo de comprobación
    • (0) exacta, 
    • (1) hash sha256, 
    • (2) hash sha512
  • Los datos concretos: generalmente el hash o bien del certificado o de la clave pública que se quieren comprobar.
El nombre del registro DNS tiene que ser de la forma _puerto._protocolo.dominio. Por ejemplo _443._tcp.torproject.org o _25._tcp.mail.ejemplo.com son nombres de registro válidos.

Ejemplo

En la página del proyecto TOR (que soporta DANE), se puede ver su registro relacionado con la página web del proyecto (para ello se solicita el registro TLSA que son el tipo 52 con este comando):

host -t TLSA _443._tcp.torproject.org

que devolverá:

_443._tcp.torproject.org has TLSA record 3 1 1 578582E6B4569A4627AEF5DFE876EEC0539388E605DB170217838B10 D2A58DA5

donde se puede comprobar que torproject.org en el puerto 443/tcp tiene un servicio TLS donde existe un certificado cuyo hash256 (el tercer 1) de su clave pública (el segundo 1) es 578582E6B4569A4627AEF5DFE876EEC0539388E605DB170217838B10

Para comprobar que coincide con el certificado que nos envía el servidor al acceder a la página web por HTTPS, se debe primero obtener su clave pública y calcular su hash.
  • Se obtiene el certificado de la web de torproject.org con el siguiente comando:
openssl s_client -connect torproject.org:443
** snip **
-----BEGIN CERTIFICATE-----
MIIFXTCCBEWgAwIBAgIQCUixqTslHQ2xBRBZ4sJoCjANBgkqhkiG9w0BAQsFADBwMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3dXJhbmNlIFNlcnZlciBDQTAeFw0xMzEwMjIxMjAwMDFaFw0xNjA1MDMxMjAwMDBad3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNzMHIxCzAJBgNVBAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMRAwDgYDVQQHAoIBAQC3IzntyGiFJ+WBDpwADPriJSptB8h1Gkeq8FNJuWIXUlfA0RlAfNEOu85CEwdXYWxwb2xlMR4wHAYDVQQKExVUaGUgVG9yIFByb2plY3QsIEluYy4xGTAXBgNVBAMMECoudG9ycHJvamVjdC5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKG7rUzGxJWvCqT0qrCvxUoUl4S1geh7+VFdo0evz88YvEGizDALi0+aBwpEeiZyxWqFhHheih24hWS1Uf6bh+uHG8kRfHAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBRRa1LT6udEZoWH4NeZMKLJhMz6i2tzQ3CubaU1+RePA7wU/tGgmUC53Shs1YYiSKRCXX03OvW9YuMRsoc6eAoVBQ7ZivTEWRUbwxZeGWlQXtoWsP/tZHphsIeVLmg/jw6kyZfscEHVAqylgYMJzlSySqq6dv2HNJpJExV6nVA9QUvsILwg4uuH+53csk0IG/CFaP+QrwIHdTzM2WVkYqISuFlyOzAdBgNVHQ4EFgQUgiYI8RMpVTQUtI+AHXG4YNpLc2hhMi1oYS1zZXJ2ZXItZzEuY3JsMEIGA1UdIAQ7MDkwNwYJYIZIAYb9bAEBMCowQcwwKwYDVR0RBCQwIoIQKi50b3Jwcm9qZWN0Lm9yZ4IOdG9ycHJvamVjdC5vcmcwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjB1BgNVHR8EbjBsMDSgMqAwhi5odHRwOi8vY3JsMy5kaWdpY2VydC5jb20vc2hhMi1oYS1zZXJ2ZXItZzEuY3JsMDSgMqAwhi5odHRwOi8vY3JsNC5kaWdpY2VydC5jb20vKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYMGCCsGUKvNlZ9ZI0C0b1vbsl6L6Mtb0GA15ejF5/BT6Q38sN84PmeWp5nbYJ0ZAKsrky/cAQUFBwEBBHcwdTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tME0GCCsGAQUFBzAChkFodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEySGlnaEFzc3VyYW5jZVNlcnZlckNBLmNydDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBCwUAA4IBAQBvcHF+gBHQqmAJYTrpqUtCNI+rdGPQ1otYgx4E16qZhd9kUgwug9c+ygo9LsRqap9aBMSOKYKc5MbHX1a9qkEYFOwlDN24IyClAV+MPkCVTOS/XxK3E7FmHsr6i/OHiGhK1eWbHKPAd6pTg7TT3VDlqyss8E+t7dckuArEekVjmy8opy75N4xkzEhuRMdPq722uOnHsYxXvPOA96RKufTkFwJje/xVm/g7vlN23IEBeKm7UOp6ksIRGTo6b+yYr2fzVOVxpXnMNkbJ7WNS/ZtS
-----END CERTIFICATE-----
** snip **
  • Se almacena el certificado (incluyendo el BEGIN y el END CERTIFICATE) en un fichero. Por ejemplo cert.crt
  • Se extrae la clave pública del certificado (porque como hemos visto en el registro DNSSEC, hacen el hash256 de la clave pública)
openssl x509 -pubkey -noout -in cert.crt > pubkey.pem
  • Se calcula su hash sha256 (código rápido en python basado de las dnssec-tls-tools de Adam Langley)
import sys
import hashlib

def main(args):
  if len(args) != 2:
    print 'usage: %s ' % args[0]
    return

  base64_data = ''
  in_base64_data = False
  for line in [x[:-1] for x in file(args[1], 'r').readlines()]:
    if in_base64_data:
      if line == '-----END PUBLIC KEY-----':
        break
      base64_data += line
    elif line == '-----BEGIN PUBLIC KEY-----':
      in_base64_data = True

  spki = base64_data.decode('base64')

  tlsa = hashlib.sha256(spki).digest()
  print 'Hash256 is %s' % (tlsa.encode('hex'))
  
if __name__ == '__main__':
  main(sys.argv)
  • Y finalmente se comprueba que sean iguales
hash256.py pubkey.pem
Hash256 is 578582e6b4569a4627aef5dfe876eec0539388e605db170217838b10d2a58da5

que efectivamente coincide con el hash previamente calculado.
  • Se puede comprobar además que los datos del registro DNS están firmados de forma correcta. El comando: dig +nocomments +nostats +nocmd +noquestion -t dnskey . > trusted-key.key almacenará la clave de la raíz. Luego, el comando dig +topdown +sigchase +multiline -ta www.torproject.org devolverá si la operación de comprobación de todas las cadenas ha tenido éxito o no.
Ejemplo de comprobación con www.torproject.com, y el comando usado 
¿Qué aporta DANE?

DANE proporciona algunas ventajas a la hora de lidiar con TLS:
  • Es posible limitar por CA, es decir, que es posible especificar que sólo una CA concreta puede firmar los certificados de un servidor (lo que disminuye la probabilidad de que alguien lo suplante si se compromete la seguridad de una CA concreta). Por ejemplo, en el caso del incidente de DigiNotar se crearon certificados falsos de Gmail; si Google hubiera usado DANE y hubiera limitado que sus certificados sólo pueden ser firmados por la CA que utiliza (GeoTrust), este ataque no hubiera funcionado para los clientes que visitaran el sitio falso.
  • Permite definir libremente qué CA se quiere usar para un certificado (y puede ser una CA propia).
  • Permite utilizar un certificado auto-firmado. Según el observatorio de SSL de la EFF, un 46% de los certificados en Internet son auto-firmados.

Problemas

DANE no aporta la validación extendida que ofrecen las CAs, donde se comprueba realmente la organización detrás de un certificado. Es algo que todavía hoy tiene que ser un procedimiento manual. Se trata de comprobar ciertos datos para que por ejemplo alguien que quiera un certificado goog1e.com, debademostrar que es Google Inc, "burocráticamente".

Pero el principal problema es la falta de uso generalizado de DNSSEC, tanto a nivel de servidor como de los clientes. Todavía hoy incluso algunos routers en Internet bloquean las peticiones y respuestas DNSSEC por resultar paquetes demasiado grandes. Además, por compatibilidad con navegadores u otros clientes TLS antiguos se necesitan aún certificados firmados por CAs bajo algunos escenarios.

Pero independientemente de la solución, lo fundamental es que sea respaldada por los navegadores. Y aún los navegadores no lo soportan. De hecho, durante un tiempo estuvo implementado en navegadores como Chromium aunque parece ser que eliminaron la funcionalidad por "poco uso"; en Firefox se discute hace años el poder incluirlo (existen parches no oficiales) aunque por ahora no está priorizado. Por suerte, existe un plugin para todos los navegadores que funciona bastante bien llamado DNSSEC TLSA Validator.

Plugin DNSSEC TLS Validator para Firefox

Por si fuera poco, se suma un problema al aumentar la latencia. Se añaden varias peticiones más en cada conexión TLS, con lo que se agrega un retardo que puede llegar a ser significativo en protocolos que requieren inmediatez como SIP, XMPP, etc. Existe una opción para evitarlo y es que, por ejemplo, se almacenen datos del registro DNSSEC serializado en el propio certificado (esta es la opción que eligió Chromium en su implementación), pero a su vez tiene problemas relacionados con el corto tiempo de vida de las firmas de DNSSEC... lo que obligaría a su vez a renovar los certificados TLS de forma casi constante.

Todo esto es lo que ha llevado a que, a día de hoy, de los 10.000 "top domains" de Alexa, tan sólo 3 de ellos mantengan DANE habilitado: torproject.org, fedoraproject.org y freebsd.org.

Otros usos

DANE ya se puede utilizar en BIND desde la versión 9.9.1-P3 de diciembre 2012, y también está presente en servidores SMTP como Postfix, clientes de IRC, servidores de XMPP, SIP, etc.

También existen ideas para poder utilizar DANE como método seguro de recuperar el certificado SMIME de un usuario, donde si por ejemplo se quiere conocer la clave pública de chris@example.com, tan sólo tendría que solicitar el registro 3f51f4663b2b798560c5b9e16d6069a28727f62518c3a1b33f7f5214._smimecert.example.com donde 3f51f4663b2b798560c5b9e16d6069a28727f62518c3a1b33f7f5214 es el sha224 de 'chris' y de esta forma obtendría la clave pública de Chris. También podría funcionar para claves OpenPGP con el formato 3f51f4663b2b798560c5b9e16d6069a28727f62518c3a1b33f7f5214._openpgp.example.com e incluso para claves públicas OTR: nb2wo2a=._otrfp.example.com. donde nb2wo2a= es el Base32 del usuario, en este caso "hugh".

El futuro

Si se utilizara DANE de forma masiva, el horizonte apuntaría a eliminar CAs comerciales, puesto que se podrían usar certificados sin que estas CA los firmasen. Aunque siempre quedarán las CAs que ofrecen los certificaciones extendidos, que ahora mismo son las menos. Pero por supuesto, el lobby de las CA hará todo lo posible para que iniciativas como DANE no salgan adelante, puesto que puede hacer peligrar su negocio de venta y renovación de certificados.

Adicionalmente se estaría dando un rol de seguridad más importante a los administradores de DNS, puesto que serían los árbitros con el poder de decidir quién se puede autenticar bajo un nombre concreto. Su función, realmente sería parecida a las CAs actuales (lo que significa que si alguien compromete su seguridad, las consecuencias serán muy negativas). Esto podría llevar a nuevos problemas en grandes organizaciones puesto que, generalmente los equipos que gestionan el DNS son diferentes a los que gestionan los certificados. Y ante casos como HeartBleed podrían existir problemas de coordinación.

David Barroso
david.barroso@11paths.com

2 comentarios:

  1. Hola, muy interesante el artículo. Solo una aclaración en cuanto a lo que habláis de DigiNotar y Gmail. Hoy en día Google ya verifica que el certificado sea de la CA que ellos usan. Creo que son una de las pocas empresas que lo verifican. Yo me di cuenta usando fiddler. Si alguien sabe como añadir esa verificación de forma sencilla en un Apache con .htacces que me avise ;)

    ResponderEliminar
  2. Hola,
    es por el certificate pinnning que hace Google, y sólo deja ciertos certificados que tiene en su whitelist. Aquí lo explican ellos mismos e incluso hablan de Fiddler ;)

    https://www.imperialviolet.org/2011/05/04/pinning.html

    ResponderEliminar