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 Permiso de acceso a la red privada para relajar el 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 132 y se espera que se envíe el 4 de febrero de 2025. En esta publicación, se explica el cambio, 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 en 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 nueva opción para fetch() para declarar la intención de un desarrollador de comunicarse con un dispositivo de este tipo. Esto incluye una nueva función controlada por políticas para restringir el acceso de cada sitio a esta función y encabezados nuevos para la respuesta de verificación previa del servidor para proporcionar metadatos adicionales.

¿Qué es el acceso a redes privadas?

El acceso a redes privadas (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 estado implementando gradualmente la PNA, y la protección se ampliará en las próximas versiones.

¿Por qué se necesita una solicitud de permiso?

En Chrome 94, se bloqueó el acceso a redes privadas desde sitios web públicos no seguros. La prueba en curso de baja del acceso a red privada desde contextos no seguros reveló 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 mezclado.

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

¿Cuándo se necesita un mensaje de permiso?

Planeamos finalizar la prueba de baja de los contextos no seguros unos cuantos hitos 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 red privada con mensaje de permiso:

Activa el mensaje de permiso

Agrega el nuevo atributo targetAddressSpace como una opción de recuperación. Luego, la solicitud puede omitir la verificación de contenido mixto.

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

De acuerdo con Acceso a redes privadas: presentación de solicitudes preliminares, cualquier solicitud de red privada está precedida por una solicitud preliminar. 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 el nuevo mensaje de permiso, 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 que se presenta como 6 bytes hexadecimales separados por dos puntos.
  • Private-Network-Access-Name: Es un nombre válido como una cadena 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 aparecer el siguiente mensaje de permiso:

Salir de la prueba de baja del contexto no seguro

En el caso de los sitios web que registraron la prueba de baja del acceso a red privada para contextos no seguros, ahora es el momento de migrar tu sitio web con nuestro nuevo mensaje de permiso y salir de la prueba.

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

También te recomendamos que borres el token en la página de la prueba.

Próximos pasos

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

Se probaron varias soluciones, por ejemplo, usar service workers o hacer que el espacio de direcciones de destino sea una nueva Política de Seguridad del Contenido. Sin embargo, la forma final de las solicitudes de fetch() que no es de API aún está en proceso de investigación.

Es posible que las solicitudes de submarcos sean compatibles con la política de permisos en el futuro.

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

Comentarios sobre los 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 conocer tus comentarios. Informa un problema en el seguimiento de errores de Chromium (componente: Blink>SecurityFeature>CORS>PrivateNetworkAccess) o en el repositorio de GitHub.

Recursos