Un requisito sine qua non para el trabajo con datos digitales es disponer de canales de tra­n­s­mi­sión seguros que ga­ra­n­ti­cen la seguridad durante todo el trayecto que sigue la in­fo­r­ma­ción. No es ca­sua­li­dad que la in­fo­r­ma­ción co­n­fi­de­n­cial se transmita úni­ca­me­n­te a través de co­ne­xio­nes VPN o SSL/TLS. Las empresas y or­ga­ni­za­cio­nes se aseguran de que estos pro­to­co­los sean casi in­to­ca­bles im­ple­me­n­ta­n­do se­r­vi­do­res DNS propios, así como de­te­r­mi­na­dos me­ca­ni­s­mos de ce­r­ti­fi­ca­ción. Sin embargo, los usuarios activos fuera de estas es­tru­c­tu­ras están sujetos a las je­ra­r­quías de los DNS y ce­r­ti­fi­ca­dos públicos, au­me­n­ta­n­do co­n­si­de­ra­ble­me­n­te la po­si­bi­li­dad de ser víctimas de ataques man in the middle. La razón principal del aumento de los riesgos de seguridad es la emisión de ce­r­ti­fi­ca­dos falsos por parte de entidades dudosas o ma­li­n­te­n­cio­na­das. Por su parte, el usuario confía en que la conexión y los datos están seguros, mientras que, pa­ra­dó­ji­ca­me­n­te, la supuesta y respetada entidad de confianza se encarga de lo contrario. Con el llamado HTTP Public Key Pinning (HPKP), Google presenta una solución que en­tre­ta­n­to ya ha sido es­pe­ci­fi­ca­da como estándar en el RFC 7469.

¿Qué es el HPKP?

El Public Key Pinning es una extensión del protocolo HTTP (Hypertext Transfer Protocol) que permite definir el juego de claves públicas (Public Key Set) para las futuras co­ne­xio­nes SSL/TLS con un host. De esta manera el cliente puede saber, en su primera toma de contacto, en qué claves públicas puede confiar mientras se establece la conexión a este host. Este pro­ce­di­mie­n­to se conoce como modelo “Trust On First Use” (en español: confianza en la primera apli­ca­ción). Cada entrada de una clave ve­ri­fi­ca­da se denomina “pin” (de ahí el nombre de “pinning” dado a este mecanismo). Todos los pines creados se envían al cliente en el en­ca­be­za­do HTTP y se guardan aquí durante un de­te­r­mi­na­do periodo de tiempo.

Cuando se realiza una nueva solicitud de conexión, el cliente comprueba si la cadena de ce­r­ti­fi­ca­ción propuesta para la tra­n­s­mi­sión SSL/TLS contiene una clave pública (key) filtrada pre­via­me­n­te a través de HPKP. Si no es así, por ejemplo en el caso de un ce­r­ti­fi­ca­do falso, se genera un mensaje de error y no se establece la conexión. Este proceso de ve­ri­fi­ca­ción se conoce también como va­li­da­ción de pin. Este que sigue es un ejemplo de las entradas de los pines en el en­ca­be­za­do HTTP:

Public-Key-Pins:
    pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=";
    pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
    pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=";
    max-age=2592000; includeSubDomains; report-uri="http://example.com/pkp-report"

El ejemplo muestra las cuatro di­re­c­tri­ces que debe contener una entrada pin en el en­ca­be­za­do HTTP:

  • pin: la directiva pin es la parte más im­po­r­ta­n­te de la entrada. Como tal, está compuesta por un nombre y un valor. El nombre pro­po­r­cio­na indicios sobre el algoritmo utilizado para el cifrado. Hasta la fecha solo es posible usar SHA256. El valor hash, que se encuentra dentro de las comillas, es una cadena Base64 co­di­fi­ca­da que también se conoce como huella digital (Fi­n­ge­r­pri­nt). Es necesario fijar una directiva pin propia para cada llave (backups).
  • max-age: la directiva max-age es­pe­ci­fi­ca el periodo de validez de un pin en segundos e indica al cliente cuánto tiempo debe co­n­si­de­rar como clave segura a una Public Key de­te­r­mi­na­da. En el ejemplo me­n­cio­na­do, los pines enu­me­ra­dos se de­s­ca­r­ta­rán después de 30 días (2.592.000 de segundos).
  • in­clu­de­Su­b­Do­mai­ns: esta directiva es opcional y no requiere ningún valor. Esta es la encargada de señalar al cliente que las reglas de ce­r­ti­fi­ca­ción definidas no solo se aplican al dominio so­li­ci­ta­do, sino también a todos los su­b­do­mi­nios pe­r­te­ne­cie­n­tes al host.
  • report-uri: si se fija la directiva report-uri, cualquier error de va­li­da­ción del pin se enviará al URL es­pe­ci­fi­ca­do. Este no ne­ce­sa­ria­me­n­te tiene que estar en el mismo dominio de Internet que el host co­n­ta­c­ta­do para in­fo­r­mar­le de los intentos fallidos de co­n­fi­gu­ra­ción.

¿Cómo funciona el Ce­r­ti­fi­ca­te Pinning en el propio servidor?

Para apro­ve­char las po­si­bi­li­da­des de HPKP, primero se debe co­n­si­de­rar a qué claves públicas se quiere “pinear”. En principio, puedes se­le­c­cio­nar cualquier clave pública incluida en la cadena de ce­r­ti­fi­ca­ción, ya sea de raíz (root), in­te­r­me­dia o del ce­r­ti­fi­ca­do del servidor. Sin embargo, si se se­le­c­cio­nan or­ga­ni­s­mos de ce­r­ti­fi­ca­ción externa, se debe tener en cuenta que todos los ce­r­ti­fi­ca­dos de este sitio van a ser co­n­si­de­ra­dos válidos por los clientes y van a conducir a la va­li­da­ción del pin.

En caso de asignar un pin a la clave del servidor, pesará mucho si la clave se vuelve inu­ti­li­za­ble o si se pierde debido a un defecto de hardware. Debido a que en el primer contacto los clientes han al­ma­ce­na­do el pin por el periodo de validez es­pe­ci­fi­ca­do, estos no aceptan un nuevo pin hasta que no se haya vencido el plazo pre­via­me­n­te de­te­r­mi­na­do. Como co­n­se­cue­n­cia para los usuarios, su servidor no sería accesible. Para evitar esta situación, el estándar HPKP (RFC 7569) pro­po­r­cio­na un pin de respaldo que se entrega en el en­ca­be­za­do HTTP y, en caso de que se presente algún problema, se puede utilizar para emitir un nuevo ce­r­ti­fi­ca­do para el dominio co­rre­s­po­n­die­n­te. Esta operación se denomina solicitud de firma de ce­r­ti­fi­ca­do (CSR o Ce­r­ti­fi­ca­te Signing Request).

Consejo

Na­ve­ga­do­res como Mozilla Firefox y Google Chrome se basan en el estándar RFC 7469 y, por lo tanto, ignoran los en­ca­be­za­dos HPKP o muestran mensajes de error cuando se im­ple­me­n­ta un único pin. Para el soporte óptimo del navegador (HPKP browser support) siempre es necesario es­pe­ci­fi­car al menos dos claves públicas válidas o un pin de respaldo para que la va­li­da­ción del pin funcione.

Cálculo de los pines para claves públicas

Si el HTTP Public Key Pinning ha de funcionar en tu servidor es necesario que HTPPS se haya co­n­fi­gu­ra­do pre­via­me­n­te. Debido a que se tienen que “pinear” al menos dos claves públicas, generar los pines es el primer paso a seguir. La solución más sencilla para calcular los valores hash de las claves públicas es la apli­ca­ción de código abierto openssl, que se puede utilizar en la consola de línea de comandos de tu sistema. RFC 7469 pro­po­r­cio­na el comando estándar para los ce­r­ti­fi­ca­dos X.509 de la siguiente manera:

openssl x509 -noout -in certificate.pem -pubkey | \
    openssl asn1parse -noout -inform pem -out public.key
openssl dgst -sha256 -binary public.key | openssl enc -base64

De esta forma puedes crear la secuencia Base64 para el ce­r­ti­fi­ca­do de ejemplo ce­r­ti­fi­ca­te.pem para la clave public.key. Este se emite en la salida estándar y termina siempre con el signo de igual (“=”).

En un siguiente paso configura la solicitud de firma de ce­r­ti­fi­ca­do (aquí: backup.csr) para tu clave de respaldo (aquí: backup.key):

openssl genrsa -out backup.key 2048
openssl req -new -key backup.key -out backup.csr

A co­n­ti­nua­ción, utiliza openssl para calcular el valor hash de esta clave:

openssl req -noout -in backup.csr -pubkey | \
    openssl asn1parse -noout -inform pem -out backup.key
openssl dgst -sha256 -binary backup.key | openssl enc -base64

Pro­te­c­ción del backup pin

Puesto que la razón de ser de la clave de respaldo de HPKP es re­em­pla­zar a la clave pre­de­te­r­mi­na­da en caso de fallos, es útil al­ma­ce­nar­las por separado. Para una mayor efe­c­ti­vi­dad, elije una pla­ta­fo­r­ma de al­ma­ce­na­mie­n­to externo a la que puedas acceder en cualquier momento y desde cualquier lugar. Adi­cio­na­l­me­n­te, se re­co­mie­n­da utilizar un ad­mi­ni­s­tra­dor de co­n­tra­se­ñas. Si, además, proteges la solicitud de firma de ce­r­ti­fi­ca­do y su re­s­pe­c­ti­va clave con un software en una base de datos separada, el nivel de seguridad aumenta y las claves backup están listas para usarse.

La crítica al Public Key Pinning

Gracias al enfoque “Trust On First Use”, el HPKP se involucra desde el primer contacto con el cliente. Sin embargo, la primera visita en la que el servidor transmite las claves fijadas no está protegida por el método mismo. No obstante, esta pequeña brecha solo conduce a problemas en casos aislados, mientras que un gran número de ataques inad­ve­r­ti­dos a las co­ne­xio­nes SSL/TLS de tu proyecto web es casi imposible. La principal crítica al Public Key Pinning tiene lugar en el siguiente escenario de ataque, que solo es posible una vez se ha im­ple­me­n­ta­do la te­c­no­lo­gía pinning:

  1. Un atacante obtiene acceso a tu servidor.
  2. Este instala un nuevo ce­r­ti­fi­ca­do SSL/TLS y crea su propio par de claves.
  3. Para la clave pública, este genera el valor hash apropiado y lo coloca en el lugar co­rre­s­po­n­die­n­te dentro del en­ca­be­za­do del Ce­r­ti­fi­ca­te Pinning.
  4. Los usuarios o clientes que acceden por primera vez a tu proyecto web reciben el pin in­co­rre­c­to y no pueden es­ta­ble­cer una conexión segura con tu servidor.
  5. Si el atacante elimina el ce­r­ti­fi­ca­do del servidor, a dichos usuarios se les deniega el acceso a su web hasta que el periodo de validez del pin in­co­rre­c­to haya caducado.
  6. Además de los daños re­su­l­ta­n­tes por la pérdida de tráfico, el atacante también tiene la po­si­bi­li­dad de exigir dinero y cha­n­ta­jear­te para liberar el ce­r­ti­fi­ca­do falso.

Incluso si este escenario es teó­ri­ca­me­n­te posible, no es en ningún momento un argumento contra el uso de HTTP Public Key Pinning. Esto se debe a que el atacante siempre podría co­n­fi­gu­rar la extensión del protocolo HTTP si logra acceder al servidor. El problema demuestra la im­po­r­ta­n­cia de la pro­te­c­ción contra ataques de hackers. Si utilizas pins, deberás ase­gu­rar­te de que tu software de monitoreo esté en situación de in­fo­r­mar­te con prontitud cuando se realicen cambios en los en­ca­be­za­dos HPKP para, así, poder in­te­r­ve­nir a tiempo. Un posible enfoque para so­lu­cio­nar este problema desde el lado del cliente serían los me­ca­ni­s­mos pin reset, que se encargan de eliminar los pines “ma­li­cio­sos” re­gu­la­r­me­n­te.

Otras críticas negativas son pri­n­ci­pa­l­me­n­te el bajo nivel de di­s­tri­bu­ción y la co­m­ple­ji­dad asociada con la co­n­fi­gu­ra­ción del Public Key Pinning. Las razones para esto son pro­ba­ble­me­n­te el hecho de que el estándar es, a menudo, poco conocido o to­ta­l­me­n­te de­s­co­no­ci­do.

Ir al menú principal