La fijación de TLS y el acceso por VPN responden a preguntas distintas

Ponga una aplicación móvil privada detrás de una VPN y una persona razonable preguntará si aún necesita fijación de certificados. La pregunta suena como una elección entre dos controles equivalentes, y en realidad es una pregunta sobre dos puertas distintas. La VPN decide si este dispositivo puede usar siquiera el camino; la aplicación decide si el servidor al que llegó es el que esperaba. Responda ambas por separado y el diseño se vuelve más simple.

Dos puertas, dos preguntas

La admisión a la red tiene que ver con el cliente: ¿está inscrito este dispositivo, son válidas sus credenciales y permite la política que entre en este camino? La confianza de la aplicación tiene que ver con el servidor: ¿llegó la conexión a un servicio con una identidad que la aplicación acepta? Esas respuestas vienen de sistemas distintos, fallan por motivos distintos y las corrigen equipos distintos. Un apretón de manos de VPN puede tener éxito mientras la aplicación habla con un certificado caducado detrás del par. Una aplicación perfectamente fijada puede seguir siendo inalcanzable para todos, porque el dispositivo nunca llegó a la red.

Las dos se suman. Quitar una elimina un control; añadir la otra no la sustituye.

Qué limita realmente una fijación

Una fijación estrecha el conjunto de identidades de servidor que la aplicación aceptará, normalmente nombrando una clave pública o un resumen de certificado en lugar de confiar en cada cadena que un almacén avalaría. Es una restricción superpuesta a la validación ordinaria, no un sustituto de ella. La validación ordinaria responde si una cadena es fiable; la fijación responde si es la cadena que esta aplicación espera. Una implementación que se salta el primer paso no ha ganado seguridad, solo novedad.

El objeto que se fija varía entre plataformas, así que la palabra por sí sola dice muy poco. Copiar un resumen del almacén de confianza de un producto y tratarlo como lo mismo en una aplicación móvil es un error común y silencioso.

La fijación en la plataforma es una configuración, no una política

Android expone la fijación mediante su configuración de seguridad de red, donde un conjunto de fijaciones guarda resúmenes de una clave pública y la cadena debe contener al menos uno de ellos. Ese archivo es por aplicación y requiere un cambio de compilación deliberado. iOS no tiene un mecanismo de manifiesto equivalente, así que allí la fijación vive en el propio código de evaluación de confianza de la aplicación.

Como el mecanismo difiere, el requisito debe escribirse por plataforma. Una política que diga fija el certificado sin nombrar la plataforma no es implementable.

La rotación decide si la fijación sobrevive

La parte difícil no es la primera versión, sino la renovación del certificado posterior. Una política de confianza restrictiva rechaza una clave nueva legítima con la misma firmeza que la de un atacante.

Dos mecanismos hacen la rotación superable: una fijación de respaldo ya confiada antes de necesitarse, y una fecha de caducidad en el conjunto de fijaciones para que la aplicación de la política decaiga en lugar de inutilizar la aplicación. Ambas son decisiones de política, y la caducidad en particular es una reducción deliberada de seguridad, no un temporizador inofensivo. Nombren quién controla la compilación de la aplicación, el extremo de TLS y la renovación del certificado, y pónganlos en un solo proceso de cambio. Si son tres equipos distintos, la fijación acabará provocando una caída que nadie había planificado.

Un dispositivo perdido es un tercer problema

Revocar una credencial de VPN no termina necesariamente una sesión de aplicación, y una fijación de servidor no hace absolutamente nada por un teléfono en manos ajenas. El bloqueo del dispositivo, el almacenamiento de credenciales, la vida de la sesión y la revocación remota son decisiones separadas con dueños separados. Plegarlas dentro de la discusión sobre la fijación garantiza que ninguna de ellas se diseñe.

Prueben cuatro relaciones en lugar de la que pueden ver: el servidor y la operación previstos, una cuenta que debería ser rechazada, una identidad de servidor que debería ser descartada y la rotación planificada. Una VPN que funciona ejercita solo la primera. Anoten qué probó cada prueba, porque la siguiente persona asumirá que un túnel verde significa que las cuatro pasaron.