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

Ú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 sólo 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.

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.

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:

• 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í está el asunto, veremos en las siguientes entregas puedes ver cómo están funcionando ya Chrome e Internet Explorer, estudiando sus propuestas:

Descubre todo lo que necesitas saber sobre certificados digitales: