Certificate pinning. El qué, el cómo y el porqué (I)

ElevenPaths    26 agosto, 2013
Últimamente se usa mucho este concepto. Las muestras de
debilidad de las PKI y el TLS/SSL en general, han llevado a pensar soluciones
contra este problema
que pone en riesgo las entrañas del cifrado en la red. Certificate pinning no es un método, sino solo eso, un concepto que cada uno interpreta a su manera.
Aclaremos conceptos.

Por qué
Porque SSL tiene (entre otros) un claro punto débil: la cadena de certificación.
Cuando se visita una web bajo SSL, se producen una serie de muestras de confianzas en
cadena, normalmente con tres pasos:
  • El dueño del dominio configura su servidor para que él y
    sólo él disponga del certificado asociado a ese dominio. El usuario que lo
    visita confía en que ha acudido al dominio correcto y que el certificado que se
    le presenta, está aprobado por una CA válida. Sería como pedir el DNI a una página web, y comprobar que el Estado lo ha validado.
  • Pero no lo ha validado el Estado directamente. Ese
    certificado es aprobado por una autoridad certificadora intermedia, en la que
    la CA raíz delega (por segregación y seguridad) la firma de certificados de
    terceros. Esta autoridad firma la relación entre el dominio y el certificado.
  • En las autoridades se confía porque lo dice tu navegador.
    Poco más. Vienen preconfigurados con una serie de certificados raíz en los que
    se confía.
Cadena de confianza habitual de Google
Cadena de confianza alterada. No se confía en la CA que se supone ha emitido ese certificado.
Los puntos débiles son obvios y se han dado casos de todo
tipo.
  • Gobiernos o empresas que han introducido entidades
    intermedias. Se desvía el tráfico y se introducen servidores intermedios en los
    que las autoridades certificadoras confían. Los servidores intermedios pueden
    descifrar y cifrar el tráfico de forma transparente para el usuario, y la
    cadena de confianza queda “intacta”, aunque con más pasos. En enero
    de 2013 se supo que Nokia descifraba en sus servidores el tráfico SSL de sus
    teléfonos. Se sospecha que ciertos gobiernos también puede estar interceptando comunicaciones cifradas entre su población.
  • Si se comprometen las certificadoras raíz o intermedias,
    un atacante podría crear certificados para cualquier dominio, y firmarlos. Si al
    usuario se le desvía el tráfico (por envenenamiento DNS, pharming, etc) y acaba
    en ese dominio, la cadena de certificados seguirá aparentemente igual. La CA delega en la CA intermedia
    y esta en el certificado. Esto ha ocurrido a niveles preocupantes. El caso
    Diginotar (agosto 2011), Comodo (marzo 2011) y TURKTRUST (enero de 2013) son los
    más sonados.
La lista de certificados en los que no se confía ha crecido bastante en los últimos años
Entendemos entonces que el problema es que los certificados
finales o intermedios pueden cambiar y el navegador del usuario no mostrará
ninguna advertencia, puesto que la cadena de confianza se ha modificado, pero no
se han “roto”
. El atacante ha podido firmar certificados para
dominios que no le pertenecen, introducir sistemas intermedios, o incluso
alterar los certificados raíz en los que confía máquina… pero todo viene a
ser lo mismo: la cadena de confianza alterada. Y eso debe levantar siempre sospechas, porque los
certificados de dominios no suelen modificarse a menudo. ¿Por qué no recordar
esas cadenas de confianza y alertar al usuario cuando se modifiquen?
El qué

Esta es la idea detrás del certificate pinning. Ahora es
necesario implementar el concepto. ¿Cómo hacerlo? Por ahora no hay ningún
estándar globalmente aceptado. Los navegadores más populares están tomando caminos diferentes,
construyendo encima de lo que ya existe, sin querer modificar demasiado ningún protocolo.
Pero también hay propuestas más profundas, que involucran algún cambio más o
menos importante alrededor:
  • Por otro lado andan Moxie Marlinspike y T. Perrie que han
    propuesto hace tiempo una extensión al propio protocolo TLS para permitir el
    “pinneo” de certificados. Se llama TACKS (Trust Assertions for Certificate Key).
  •  DNS-Based Authentication of Named Entities es un RFC que
    habla de asociar TLS a los dominios en cierta manera. Requiere modificar el
    DNS.
  • HSTS junto con la incrustación en el código, es el camino tomado por Google y Chrome. HSTS Requiere, en
    cierto modo, un cambio en HTTP, pero ya está en marcha en sus navegadores y no se centra tanto en el “pin” sino en la obligación de usar SSL.

Y luego está la propuesta de EMET y por tanto de alguna manera, el camino tomado por Microsoft. EMET (que viene siendo imprescindible) es el único que no requiere ningún cambio en el navegador o protocolo, lo que no significa que sea el mejor… aunque cómodo, sufre sus limitaciones.

Así el asunto, veremos en próximas entregas cómo están
funcionando ya Chrome e Internet Explorer, estudiando sus propuestas.






* Certificate pinning. El qué, el cómo y el porqué (II)
* Certificate pinning. El qué, el cómo y el porqué (III)
* Certificate pinning. El qué, el cómo y el porqué (IV)


Sergio de los Santos

Comentarios

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *