Compatibilidad con proxy en Microsoft Edge

En este documento se establece la terminología básica del proxy y se describen los comportamientos de proxy específicos de Edge.

Contenido

Identificadores de servidor proxy

Un servidor proxy es un intermediario que se usa para las solicitudes de red. Un servidor proxy se puede describir mediante su dirección, junto con el esquema de proxy que se debe usar para comunicarse con él.

Este identificador se puede escribir como una cadena mediante el "formato PAC" o el "formato URI".

El formato PAC es cómo se asigna un nombre a un servidor proxy en scripts de configuración automática de proxy . Por ejemplo:

PROXY foo:2138 SOCKS5 foo:1080 DIRECT

En su lugar, el "formato URI" codifica la información como una dirección URL. Por ejemplo:

foo:2138 http://foo:2138 socks5://foo:1080 direct://

El número de puerto es opcional en ambos formatos. Cuando se omite, se usa un valor predeterminado por esquema.

Consulte la sección Esquemas de servidor proxy para obtener más información sobre qué esquemas admite Edge y cómo escribirlos en los formatos PAC y URI.

La mayoría de las superficies de interfaz de usuario en Edge (incluidas las líneas de comandos y la directiva) esperan identificadores de servidor proxy con formato URI. Sin embargo, fuera de Edge, los servidores proxy se identifican con menos precisión cuando se usa solo una dirección: el esquema de proxy se asume en función del contexto.

En la configuración de proxy de Windows, hay campos de host y puerto para el proxy "HTTP", "Seguro", "FTP" y "SOCKS". Excepto "SOCKS", son todos identificadores de servidores proxy HTTP no seguros (el esquema de proxy se supone como HTTP).

Resolución de proxy

El proxy en Edge se realiza en el nivel de dirección URL.

Cuando se le pide al explorador que capture una dirección URL, debe decidir a qué punto de conexión IP enviar la solicitud. Puede ser un servidor proxy o el host de destino.

Esto se denomina resolución de proxy. La entrada a la resolución de proxy es una dirección URL y la salida es una lista ordenada de identificadores de servidor proxy.

Los servidores proxy que se van a usar se pueden describir mediante:

Configuración de proxy manual : la resolución de proxy se define mediante un conjunto declarativo de reglas. Estas reglas se expresan como una asignación del esquema de dirección URL a los identificadores de servidor proxy y una lista de reglas de omisión de proxy para cuándo ir DIRECTAMENTE en lugar de usar el proxy asignado.

Script PAC: la resolución de proxy se define mediante un programa JavaScript, que se invoca cada vez que se captura una dirección URL para obtener la lista de identificadores de servidor proxy que se van a usar.

Detección automática: el protocolo WPAD se usa para sondear la red (mediante DHCP/DNS) y, posiblemente, detectar la dirección URL de un script PAC.

Esquemas de servidor proxy

Cuando se usa un proxy explícito en el explorador, se ven afectadas varias capas de la solicitud de red, en función del esquema que se use. Algunas implicaciones del esquema de proxy son:

¿Se realiza la comunicación con el proxy a través de un canal seguro? ¿La resolución de nombres (por ejemplo, DNS) se realiza en el lado cliente o en el lado proxy? ¿Qué esquemas de autenticación se admiten en el servidor proxy? ¿Qué tráfico de red se puede enviar a través del proxy? Edge admite estos esquemas de servidor proxy:

Esquema de proxy DIRECT

Puerto predeterminado: N/A (no se aplica el host ni el puerto) Identificador de ejemplo (PAC): Identificador de ejemplo (URI): DIRECTdirect:// se trata de un esquema de pseudo proxy que indica en lugar de usar un proxy que vamos a enviar la solicitud directamente al servidor de destino.

No es preciso llamarlo "servidor proxy", pero es una abstracción conveniente.

Esquema de proxy HTTP

Puerto predeterminado: 80 Identificador de ejemplo (PAC): PROXY proxy:8080, proxy (no estándar; no use) Identificadores de ejemplo (URI): http://proxy:8080, proxy:8080 (puede omitir esquema) Generalmente cuando se hace referencia a un "servidor proxy" o "proxy web", se habla de un proxy HTTP.

Cuando se usa un proxy HTTP en Edge, la resolución de nombres siempre se aplaza al proxy. Los servidores proxy HTTP pueden proxy http://, ws://https://y wss:// direcciones URL.

La comunicación con los servidores proxy HTTP no es segura, lo que significa que las solicitudes con http:// proxy se envían sin cifrar. Al proxy de https:// solicitudes a través de un proxy HTTP, el intercambio TLS se reenvía a través del proxy mediante el método CONNECT, por lo que el cifrado de un extremo a otro no se interrumpe. Sin embargo, al establecer el túnel, el nombre de host de la dirección URL de destino se envía al servidor proxy sin cifrar.

Los servidores proxy HTTP de Edge admiten los mismos esquemas de autenticación HTTP que para los servidores de destino: Básico, Digest, Negotiate, NTLM.

Esquema de proxy HTTPS

Puerto predeterminado: 443 Identificador de ejemplo (PAC): HTTPS proxy:8080 identificador de ejemplo (URI): https://proxy:8080

Esto funciona como un proxy HTTP, excepto que la comunicación con el servidor proxy está protegida por TLS y puede negociar HTTP/2 (pero no QUIC).

Dado que la conexión con el servidor proxy es segura, https:// las solicitudes enviadas a través del proxy no se envían de forma clara como con un proxy HTTP. Del mismo modo, dado que las solicitudes CONNECT se envían a través de un canal protegido, tampoco se revelan los nombres de host de las direcciones URL con https:// proxy.

Además de los métodos de autenticación HTTP habituales, los servidores proxy HTTPS también admiten certificados de cliente.

Los servidores proxy HTTPS que usan HTTP/2 pueden ofrecer un mejor rendimiento en Edge que un proxy HTTP normal debido a límites de conexión más altos (los servidores proxy HTTP/1.1 en Edge se limitan a 32 conexiones simultáneas en todos los dominios).

Edge, Firefox y Opera admiten servidores proxy HTTPS; sin embargo, la mayoría de las pilas HTTP anteriores no.

La especificación de un proxy HTTPS no es posible a través de la configuración del proxy del sistema. En su lugar, se debe usar un script PAC o una configuración de proxy perimetral (línea de comandos, extensión o directiva).

Esquema de proxy SOCKSv4

Puerto predeterminado: 1080 Identificadores de ejemplo (PAC): SOCKS4 proxy:8080, SOCKS proxy:8080 Identificador de ejemplo (URI): socks4://proxy:8080 SOCKSv4 es un proxy de capa de transporte simple que encapsula un socket TCP. Su uso es transparente para el resto de la pila de protocolos; después de un protocolo de enlace inicial al conectar el socket TCP (al proxy), el resto de la pila de carga no cambia.

No se admiten métodos de autenticación de proxy para SOCKSv4.

Cuando se usa un proxy SOCKSv4, la resolución de nombres para los hosts de destino siempre se realiza en el lado cliente y, además, debe resolverse en una dirección IPv4 (SOCKSv4 codifica la dirección de destino como cuatro octetos, por lo que los destinos IPv6 no son posibles).

Hay extensiones para SOCKSv4 que permiten la resolución de nombres del lado proxy e IPv6, es decir, SOCKSv4a. Sin embargo, Edge no permite configurar ni revertir a v4a.

Una mejor alternativa es simplemente usar la versión más reciente del protocolo, SOCKSv5 (que todavía tiene más de 20 años).

Esquema de proxy SOCKSv5

Puerto predeterminado: 1080 Identificador de ejemplo (PAC): SOCKS5 proxy:8080 identificadores de ejemplo (URI): socks://proxy:8080, socks5://proxy:8080

SOCKSv5 es un proxy de capa de transporte que encapsula un socket TCP y permite aplazar la resolución de nombres al proxy.

En Edge cuando el esquema de un proxy se establece en SOCKSv5, la resolución de nombres siempre se realiza en el lado proxy (aunque el protocolo también permite el lado cliente). En firefox client side vs proxy name resolution can be configured with network.proxy.socks_remote_dns; Edge no tiene ninguna opción equivalente y siempre usará la resolución del lado proxy.

No se admiten métodos de autenticación para SOCKSv5 en Edge (aunque existen algunos para el protocolo).

Una manera práctica de crear un proxy SOCKSv5 es con ssh -D, que se puede usar para tunelizar el tráfico web a un host remoto a través de SSH.

En Edge SOCKSv5 solo se usa para proxy de solicitudes DE DIRECCIÓN URL basadas en TCP. No se puede usar para retransmitir el tráfico UDP.

Configuración de proxy manual

La manera más sencilla de configurar la resolución de proxy es proporcionar una lista estática de reglas compuesta por:

Una asignación de esquemas de direcciones URL a identificadores de servidor proxy Una lista de reglas de omisión de proxy Nos referimos a este modo de configuración como "configuración de proxy manual".

La configuración de proxy manual puede describir de forma sucinta configuraciones como las siguientes:

Usar proxy http://foo:8080 para todas las solicitudes Use proxy http://foo:8080 para todas las solicitudes excepto para un contoso.com subdominio Use proxy http://foo:8080 para todas las https:// solicitudes y proxy socks5://mysocks:90 para todo lo demás Aunque la configuración de proxy manual es una manera ubicua de configurar servidores proxy entre plataformas, no hay ninguna representación estándar o conjunto de características.

La configuración de proxy manual de Edge se parece más a la de WinInet. Pero también admite expresiones de otras plataformas: por ejemplo, la noción de KDE de invertir la lista de omisión, o la interpretación de Gnome de patrones de omisión como coincidencias de sufijos.

Al definir la configuración de proxy manual en Edge, se especifican tres listas (posiblemente vacías) de identificadores de servidor proxy:

proxies para HTTP: una lista de identificadores de servidor proxy que se usarán para http:// las solicitudes, si no hay ningún proxy para HTTPS: una lista de identificadores de servidor proxy que se usarán para https:// las solicitudes, si no hay otros servidores proxy: una lista de identificadores de servidor proxy que se usarán para todo lo demás (no coincidentes con las otras dos listas) Hay muchas maneras de terminar con la configuración de proxy manual en Edge (se describe en otras secciones).

En los ejemplos siguientes se usa el método de línea de comandos. Iniciar Edge con --proxy-server=XXX (y opcionalmente --proxy-bypass-list=YYY)

Ejemplo: para usar el proxy http://foo:8080 para todas las solicitudes, podemos iniciar Edge con --proxy-server="http://foo:8080". Esto se traduce en:

proxies para HTTP: servidores proxy vacíos para HTTPS, otros servidores proxy vacíos: http://foo:8080 con la configuración anterior, si no se pudiera acceder al servidor proxy, se produciría un error en todas las solicitudes con ERR_PROXY_CONNECTION_FAILED. Para solucionar este problema, podríamos agregar una reserva a DIRECT iniciando mediante --proxy-server="http://foo:8080,direct://" (anote la lista separada por comas). Esta línea de comandos significa:

proxies para HTTP: servidores proxy vacíos para HTTPS, otros servidores proxy vacíos: http://foo:8080, direct:// Si en su lugar queríamos proxy solo http:// las direcciones URL a través del proxy https://foo:443HTTPS y hacer que todo lo demás use el proxy socks5://mysocks:1080 SOCKSv5, podríamos iniciar Edge con --proxy-server="http=https://foo:443;socks=socks5://mysocks:1080". Ahora se expande a:

proxies para HTTP: https://foo:443 servidores proxy para HTTPS, otros servidores proxy vacíos: socks5://mysocks:1080 la línea de comandos anterior usa el formato de mapa proxy de WinInet, con algunas características adicionales:

En lugar de asignar un nombre a los servidores proxy solo por , hostname:portpuede usar el formato URI de Edge para los identificadores de servidor proxy. En otras palabras, puede anteponer el esquema de proxy para que no tenga como valor predeterminado HTTP. La socks= asignación se entiende más ampliamente como "otros servidores proxy". La lista de proxy posterior puede incluir servidores proxy de cualquier esquema, pero si se omite el esquema, se entenderá como SOCKSv4 en lugar de HTTP.

Asignación de direcciones URL de WebSocket a un proxy

La configuración de proxy manual no tiene asignaciones ni ws://wss:// direcciones URL.

Seleccionar un proxy para estos esquemas de direcciones URL es un poco diferente de otros esquemas de direcciones URL. El algoritmo que usa Edge es:

Si no hay "otros servidores proxy" úselo si "proxies para HTTPS" no lo usa; de lo contrario, use "proxies para HTTP" Esto es según la recomendación de la sección 4.1.3 de RFC 6455.

Es posible enrutar ws:// y wss:// por separado mediante un script PAC.

Credenciales de proxy en configuración de proxy manual

La configuración de proxy manual de la mayoría de las plataformas permite especificar un nombre de usuario o contraseña de texto no cifrado para el inicio de sesión de proxy. Edge no implementa esto y no usará ninguna credencial incrustada en la configuración del proxy.

En su lugar, la autenticación de proxy pasará por el flujo normal para buscar credenciales.

Reglas de omisión de proxy

Además de especificar tres listas de identificadores de servidor proxy, la configuración de proxy manual de Edge le permite especificar una lista de "reglas de omisión de proxy" mediante patrones de dirección URL.

Este conjunto de reglas determina si una dirección URL determinada debe omitir el uso de un proxy en conjunto, incluso cuando se haya definido un proxy para él de otro modo.

Este concepto también se conoce con nombres como "lista de excepciones", "lista de exclusión" o "sin lista de proxy".

Las reglas de omisión de proxy se pueden escribir como una lista ordenada de cadenas. Por lo general, la ordenación no importa, pero puede usar reglas restivas.

Cuando se especifica la configuración de proxy manual desde la línea de comandos, se puede usar el --proxy-bypass-list="RULES" modificador, donde RULES es una lista separada por punto y coma de reglas de omisión.

Consulte patrones de direcciones URL de configuración de proxy para ver el formato de patrones de dirección URL compatible con Edge para las reglas de omisión de proxy.

Cuando se usa la configuración del proxy del sistema, se debe usar el formato de regla de la plataforma y no el de Edge.

Patrones de direcciones URL de configuración de proxy

En esta sección se describen las construcciones de cadena que Edge admite para especificar patrones de dirección URL en el contexto de la configuración de proxy, por ejemplo, reglas de omisión de proxy o para el DestinationMatchers valor de la ProxyOverrideRules directiva. Estos patrones se pueden usar al definir una configuración de proxy manual de Edge a partir de marcas de línea de comandos, extensiones o directivas.

Patrones de dirección URL de configuración de proxy: nombre de host

[ URL_SCHEME "://" ] HOSTNAME_PATTERN [ ":" <port> ]

Coincide con un nombre de host con un patrón comodín y con un esquema opcional y una restricción de puerto.

Ejemplos:

foobar.com- Coincide con la dirección URL de cualquier esquema y puerto, cuyo host normalizado es foobar.com*foobar.com : coincide con la dirección URL de cualquier esquema y puerto, cuyo host normalizado termina con (por ejemplo blahfoobar.com y foo.foobar.com) *.org:443 : coincide con las direcciones URL de cualquier esquema, usando el puerto 443 y cuyo dominio de nivel superior eshttps://x.*.y.com:99.org: coincide con foobar.com las direcciones https:// URL del puerto 99 cuyo nombre de host normalizado coincide conx.*.y.com

Patrones de dirección URL de configuración de proxy: subdominio

[ URL_SCHEME "://" ] "." HOSTNAME_SUFFIX_PATTERN [ ":" PORT ]

Los patrones de nombre de host que comienzan con un punto tienen mayúsculas y minúsculas especiales para significar coincidencias de subdominio. .foo.com es, en realidad, otra forma de escribir *.foo.com.

Ejemplos:

.contoso.com - Coincide outlook.contoso.com con y foo.bar.contoso.com, pero no contoso.comhttp://.contoso.com : solo http:// coincide con las direcciones URL que son un subdominio de . contoso.com

Patrones de dirección URL de configuración de proxy: literal ip

[ SCHEME "://" ] IP_LITERAL [ ":" PORT ]

Coincide con direcciones URL que son literales de dirección IP y restricciones de esquema y puerto opcionales. Se trata de un caso especial de coincidencia de nombre de host que tiene en cuenta la canonización de literales ip. Por ejemplo, las reglas [0:0:0::1] y [::1] son equivalentes (ambos representan la misma dirección IPv6).

Ejemplos:

127.0.0.1 http://127.0.0.1 [::1] : coincide con cualquier dirección URL a la dirección [0:0::1] de bucle invertido IPv6: igual que la anterior http://[::1]:99 : coincide con cualquier http:// dirección URL al bucle invertido IPv6 en el puerto 99.

Patrones de direcciones URL de configuración de proxy: intervalo de direcciones IPv4

IPV4_LITERAL "/" PREFIX_LENGTH_IN_BITS

Coincide con cualquier dirección URL cuyo nombre de host es un literal IPv4 y se encuentra entre el intervalo de direcciones especificado.

Tenga en cuenta que esto solo se aplica a las direcciones URL que son literales IP.

Ejemplos:

192.168.1.1/16

Patrones de direcciones URL de configuración de proxy: intervalo de direcciones IPv6

IPV6_LITERAL "/" PREFIX_LENGTH_IN_BITS

Coincide con cualquier dirección URL que sea un literal IPv6 que se encuentre entre el intervalo especificado. Los literales IPv6 no deben estar entre corchetes.

Tenga en cuenta que esto solo se aplica a las direcciones URL que son literales IP.

Ejemplos:

fefe:13::abc/33 [fefe::]/40 --¡INCORRECTO! Los literales IPv6 no deben estar entre corchetes

Patrones de dirección URL de configuración de proxy: nombres de host simples

<local>

Coincide con nombres de host sin un punto en ellos y que no son literales IP. Se trata de una búsqueda de cadenas ingenua, lo que significa que los puntos que aparecen en cualquier lugar cuentan (incluidos los puntos finales).

Esta regla corresponde a la casilla "Excluir nombres de host simples" en macOS y a "No usar el servidor proxy para direcciones locales (intranet) " en Windows.

El nombre de la regla procede de WinInet y se puede confundir fácilmente con el concepto de localhost. Sin embargo, los dos conceptos son ortogonales. En la práctica, no se agregarían reglas para omitir localhost, como ya se ha hecho implícitamente.

Patrones de dirección URL de configuración de proxy: resta reglas implícitas

<-loopback>

Resta las reglas implícitas de omisión de proxy (localhost y vincular direcciones locales). Esto solo es necesario para las configuraciones de prueba. Tenga en cuenta las implicaciones de seguridad para el proxy localhost.

Mientras que las reglas de omisión normales indican al explorador las direcciones URL que no deben usar el proxy, esta regla tiene el efecto contrario y le indica al explorador que use el proxy en su lugar.

La ordenación puede importar cuando se usa una regla restativa, ya que las reglas se evaluarán en un orden de izquierda a derecha. <-loopback>;127.0.0.1 tiene un efecto ligeramente diferente al de 127.0.0.1;<-loopback>.

Significado de las reglas de omisión del intervalo de direcciones IP

La regla de omisión del intervalo de direcciones IP en la configuración de proxy manual solo se aplica a los literales de dirección URL. Esto no es lo que cabría esperar intuitivamente.

Por ejemplo:

Supongamos que hemos configurado un proxy para todas las solicitudes, pero se ha agregado una regla de omisión para 192.168.0.0.1/16. Si ahora navegamos a http://foo (que se 192.168.1.5 resuelve en en nuestra configuración) el explorador se conecta directamente (omita el proxy) porque hemos indicado una regla de omisión que incluye esta dirección IP?

Pasa por el proxy.

La regla de omisión en este caso no es aplicable, ya que el explorador nunca realiza realmente una resolución de nombres para foo. La resolución de proxy se produce antes de la resolución de nombres y, en función del esquema de proxy que se elija más adelante, es posible que nunca se realice la resolución de nombres del lado cliente.

La utilidad de las reglas de omisión de proxy de intervalo IP es bastante limitada, ya que solo se aplican a las solicitudes cuya dirección URL era explícitamente un literal ip.

Si es necesario tomar decisiones de proxy en función de las direcciones IP resueltas del nombre de host de una dirección URL, se debe usar un script PAC.

Reglas de omisión implícitas

Las solicitudes a determinados hosts no se enviarán a través de un proxy y, en su lugar, se enviarán directamente.

Llamamos a estas reglas de omisión implícitas. Las reglas de omisión implícitas coinciden con las direcciones URL cuya parte del host es un nombre localhost o un literal DE IP local de vínculo. Básicamente coincide con lo siguiente:

localhost *.localhost [::1] 127.0.0.1/8 169.254/16 [FE80::]/10 Las reglas completas son ligeramente más complicadas. Por ejemplo, en Windows, también reconocemos loopback.

Este concepto de reglas implícitas de omisión de proxy es coherente con la compatibilidad de proxy de nivel de plataforma en Windows y macOS (aunque con algunas diferencias debido a sus peculiaridades de implementación; consulte las notas de compatibilidad en net::ProxyHostMatchingRules::MatchesImplicitRules)

¿Por qué aplicar reglas de omisión de proxy implícitas en primer lugar? Ciertamente hay consideraciones sobre la ergonomía y las expectativas del usuario, pero el problema más grande es la seguridad. Dado que la plataforma web trata localhost como un origen seguro, la capacidad de proxy le concede poderes adicionales. Esto es especialmente problemático cuando la configuración del proxy se puede controlar externamente, como cuando se usan scripts PAC.

Invalidar las reglas de omisión implícitas

Si desea que el tráfico a localhost se envíe a través de un proxy a pesar de los problemas de seguridad, se puede hacer agregando la regla <-loopback>de omisión de proxy especial . Esta regla tiene el efecto de restar las reglas implícitas.

Por ejemplo, inicie Edge con la marca de línea de comandos:

--proxy-bypass-list="<-loopback>"

Actualmente no hay ningún mecanismo para deshabilitar las reglas implícitas de omisión de proxy cuando se usa un script PAC. Las reglas de omisión de proxy solo se aplican a la configuración manual, por lo que esta técnica no se puede usar para permitir que los scripts PAC decidan el proxy para las direcciones URL de localhost.

Licencia de contenido

Nota

Algunas partes de esta página son modificaciones que se basan en trabajo creado y compartido por Chromium.org y que se usan de acuerdo con los términos descritos en la Licencia internacional de Creative Commons Atribution 4.0. La página original de Chromium se puede encontrar aquí.

Licencia de Creative Commons
Este trabajo dispone de licencia conforme a Licencia internacional de Creative Commons Attribution 4.0.

  • Last updated on