lunes, 3 de julio de 2017

HSTS & HPKP: Misión salvar HTTPS [Parte II]

En la primera parte de esta serie de entradas donde se explica HSTS & HPKP, se comentaron los antecedentes dieron lugar a que se comenzaran a usar estos dos protocolos. En este post, se explicarán ambos protocolos, comenzando por HPKP y cuál es su funcionamiento y estructura e su cabecera.



Validación basada en Pines

Antes de nada, considero como obligatorio, explicar qué es un Pin en las cabeceras HTTP. HSTS y HPKP son como los Mortadelo y Filemón, cuyo objetivo esta vez, será salvar a HTTPS de los ataques mencionados en la primera parte de esta entrada.

Un Pin, tal y como se ha definido en el RFC7469, es una relación entre un nombre de host y un sistema criptográfico de Identidad. La validación por Pin es el mecanismo que trata de asegurar que un host es autenticado por su Pin que ha sido establecido anteriormente.


La cabecera de HPKP usa el Public-Key-Pins, de ahí el PKP de HPKP. Esto es usado por un servidor para inicar que UA debería realizar un Pin Validation para el host emisor del mensaje y aportar la información necesaria para que UA realice su tarea.

Las directivas definidas para esta especificación son 6 requerimientos generales, las cuales pueden ser interesantes de mencionar:

  1. El orden de aparición de las directivas no es significante.
  2. Las directivas son u opcionales o requeridas, por lo cual no puede aparecer una directiva dada más de una vez en el campo cabecera.
  3. La directiva de nombres no es considerada.
  4. UAs deberían de ignorar cualquier campo cabecera que contenga directiva o cualquier otro campo de valor de datos, que no estén definidos en la especificación. Por lo tanto UA, no deberá de tratar de arreglar campos cabecera malformados.
  5. Si el campo cabecera contiene alguna directiva que UA no reconozca, UA deberá de ignorar esas directivas.
  6. Si los campo cabecera PKP cumplen los requerimientose, UA deberá procesar las directivas que reconozca.
La directiva de Pin

La directiva de pines es una forma para que las operadores de web hos, iniquen una identidad criptográfica que debería de estar ligada a una determinada web host. Cabe mencionar la sintaxis de una directiva de Pin.



Esta directiva se recordará cuando veamos ejemplos reales de web host que usen HPKP en una cabecera. Pero en esta directiva, el token es el nombre del hash del algoritmo criptográfico. Hasta el momento, no podemos usar cualquier algoritmo, hasta ahora, el único permitido es el hash del algoritmo SHA256 definido en el RFC6234 y cuyo funcionamiento es igual al SHA224, ya que antes de la entrada de un mensaje a la función hash, se realizarán una serie de pasos para "engordar" el mensaje en hexadecimal, del mensaje entrante con una longuitud menor de 2^64. Esos pasos vienen perfectamente definidos en el RFC6234, pero se explicará de manera muy resumida por si algun@ tiene interés.

  1. Se añade un 1 al mensaje original.
  2. Se añade una K , siendo K el valor menor posible para una solución no negativa de la ecuación.
  3. Se añade un bloque de 64 bits, provocando que el mensaje original "engorde" hasta una longuitud múltiplo de 512 bits. 


Todos estos pasos, se pueden entender mejor, leyendo detenidamente el RFC6234, donde además te presentan ejemplos de las ecuaciones y la compresión puede mejorar así.

No obstante, no se descarta que el futuro, se permitan otros algoritmos criptográficos. Pero, tal y como está la situación ahora, la cadena emitida, es una secuencia de 64 dígitos, codeada con base64 SPKI Fingerprint. Dicho encoder viene definido en el RFC4648.


Si recordamos las reglas enunciadas anteriormente, UA deberá de ignorar los tokens-que son los nombres del hash del nombre del algoritmo- que no reconozca. Además, si el conjunto de directivas de Pines efectivas restantes está vacía, y si el host es un host conocido, la UA, deberá, obligatoriamente, dejar de considerar al host como un host conocido. Aquí viene un paso importante, y es que la UA deberá de informar a los usuarios que el host no es un Pin de host conocido o Known Pinned Host.

La directiva de max-age

Esta directiva marcará el número de segundos que deberá de pasar después de la recepción del campo cabecera PKP mientras que UA deberá de considerar el host como un Known Pinned Host. Es decir, es como la fecha de caducidad del Pin, y una vez pasados esos segundos, el certificado no tendrán validez alguna.

Esta directiva, el max-age, es un campo requerido para presentar el campo cabecera una Public-Key-Pins. Esta es su sintaxis.


A continuación, vendrán dos directivas opcionales y que no son necesarias pero sí que mejoran la seguridad de la conexión.

La directiva includeSubDomains

Como se ha dicho, es un campo opcional y por el nombre se puede deducir qué es lo que hace. Básicamente es aplicar las mismas reglas de las directivas mencionadas anteriormente a los subdominos de un host. Por ejemplo, las directivas que use https://facebook.com, se aplicarán también a https://subdominio.facebook.com, ya que de lo contrario, no se aplicaría y la conexión a un subdominio, podría comprometerse.

La directiva report-URI

Esta directiva, también es opcional, pero su aplicación, mejoraría notablemente la seguridad de la conexión siempre y cuando se aplique correctamente.

Esta directiva define la URI a la que se van a enviar los reportes con los posibles fallos que puedan ocurrir. Resulta lógico pensar que definir la misma URI que ha fallado, no es una práctica ejemplar, ya que el reporte se enviará a un host que ha fallado, con lo cuál, la conclusión será que el informe fallará. Esto que parece lógico, hay muchas empresas que no lo ven y usan URIs que han fallado para enviar ahí sus reportes.

Básicamente, esto es lo reseñable sobre HPKP. En las próximas entradas se verá cómo usan estas directivas algunas de las empresas más conocidas por los usuarios y así se tratará de mejorar la comprensión de estas directivas.

¿Hackeamos el Mundo?

********************************************************************



No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...