La prueba de baja del Acceso a la red privada (PNA) para contextos no seguros finalizará pronto: implementa la solicitud de permiso de PNA

Yifan Luo
Yifan Luo
GitHub

Chrome 124 incluye la función de permiso de Acceso a redes privadas para relajar contenido mixto. Hay una prueba de baja en curso para los sitios que necesitan más tiempo a fin de prepararse para este cambio. Sin embargo, esta prueba finaliza en Chrome 126, que se espera que se envíe el 4 de septiembre de 2024. En esta publicación, se explica el cambio, se brinda más información sobre el diseño de la función, cómo migrar tus sitios web actuales y cómo probar tu implementación.

¿Qué aspectos cambiarán?

Para establecer conexiones con dispositivos de una red privada que no tienen nombres únicos a nivel global y, por lo tanto, no pueden obtener certificados TLS, esta función presenta una opción nueva en fetch() para declarar la intención de un desarrollador de comunicarse con ese dispositivo. Esto incluye una función nueva controlada por políticas para restringir el acceso de cada sitio a esta capacidad, además de encabezados nuevos para la respuesta de solicitud preliminar del servidor para proporcionar metadatos adicionales.

¿Qué es el Acceso a redes privadas?

El Acceso a la red privada (PNA, antes conocido como CORS-RFC1918 y, en breve, Acceso a la red local) es una función de seguridad que restringe la capacidad de los sitios web para enviar solicitudes a servidores en redes privadas. Esto ayuda a proteger a los usuarios y las redes internas de posibles ataques, como la falsificación de solicitudes entre sitios (CSRF). Chrome ha ido implementando gradualmente PNA, y la protección se expandirá en las próximas versiones.

¿Por qué se necesita un mensaje de permiso?

Chrome 94 introdujo un bloqueo en el acceso a redes privadas desde sitios web públicos no seguros. La prueba de baja del Acceso a la red privada desde contextos no seguros reveló algunos desafíos para migrar los sitios web afectados a HTTPS. Una preocupación común es la dificultad de migrar dispositivos privados a HTTPS, lo que genera incumplimientos de la verificación de contenido mixto.

Para abordar este desafío, se agregó un nuevo mensaje de permiso en una prueba de origen de Chrome 120 y en la versión estable desde Chrome 124.

¿Cuándo se necesita un mensaje de permiso?

Planeamos finalizar la prueba de baja de contextos no seguros algunos eventos importantes después de que la función de solicitud de permiso estuviera disponible. Para garantizar la compatibilidad, debes migrar tus sitios web públicos a HTTPS. Si no puedes migrar tu servidor privado a HTTPS, la nueva función de solicitud de permiso te permitirá relajar las verificaciones de contenido mixto.

El siguiente es un flujo de trabajo típico para una solicitud de acceso a una red privada con un mensaje de permiso.

Activa la solicitud de permiso

Agrega el nuevo atributo targetAddressSpace como opción de recuperación, luego, la solicitud podrá omitir la verificación de contenido mixto.

fetch("http://router.local/ping", {
  targetAddressSpace: "private",
});

De acuerdo con Acceso a la red privada: presentación de comprobaciones preliminares, cualquier solicitud de red privada está precedida por una solicitud de comprobación previa. Esta solicitud de comprobación previa incluirá un encabezado nuevo, Access-Control-Request-Private-Network: true, y la respuesta correspondiente debe incluir el encabezado Access-Control-Allow-Private-Network: true.

Para admitir la solicitud de permiso nuevo, los dispositivos deben incorporar dos encabezados de respuesta nuevos: Private-Network-Access-Name y Private-Network-Access-ID.

  • Private-Network-Access-ID: Es un valor de 48 bits presentado como 6 bytes hexadecimales separados por dos puntos.
  • Private-Network-Access-Name: Es un nombre válido como string que coincide con la expresión regular de ECMAScript. /^[a-z0-9_-.]+$/.La longitud máxima del nombre es de 248 unidades de código UTF-8.
Private-Network-Access-Name: "My Smart Toothbrush"
Private-Network-Access-ID: "01:23:45:67:89:0A"

Demostración

Puedes ver la demostración en https://private-network-access-permission-test.glitch.me/.

Debes iniciar tu servidor privado personal para usar el sitio web de demostración. El servidor privado debe responder con el encabezado HTTP Access-Control-Allow-Private-Network: true, junto con los encabezados Private-Network-Access-ID y Private-Network-Access-Name especificados por el servidor. Si todo está configurado correctamente, debería mostrarse el siguiente mensaje de permiso:

Salir de la prueba de baja del contexto no seguro

En el caso de los sitios web que registraron una prueba de baja del Acceso a redes privadas para contextos no seguros, este es el momento de migrar su sitio web con nuestro nuevo mensaje de permiso y salir de la prueba ahora.

Después de actualizar el código, borra el token de prueba de los encabezados HTML, JavaScript o HTTP. Si no recuerdas dónde colocaste el token de prueba, consulta la sección Regístrate para la prueba de baja en la entrada de blog anterior.

También puedes borrar el token en la página de la prueba.

¿Qué sigue?

La solución para las solicitudes de fetch() que no son de la API aún está en exploración.

Se probaron varias soluciones, por ejemplo, usar service worker o crear un espacio de direcciones como una nueva política de seguridad del contenido. Sin embargo, la forma final para las solicitudes de fetch() que no son de la API todavía está en investigación.

Es posible que las solicitudes de submarcos se admitan en la política de permisos en el futuro.

En el futuro, es posible que quieras admitir políticas de permisos para relajar la capacidad de submarcos.

Comentarios sobre casos de uso de redes privadas

Si alojas un sitio web en una red privada que necesita solicitudes de redes públicas, el equipo de Chrome quiere recibir tus comentarios. Informa un problema en la Herramienta de seguimiento de errores de Chromium (componente: Blink>SecurityFeature>CORS>PrivateNetworkAccess) o en el repositorio de GitHub.

Recursos