Prise en charge du proxy dans Microsoft Edge

Ce document établit la terminologie de proxy de base et décrit les comportements de proxy spécifiques à Edge.

Contenu

Identificateurs de serveur proxy

Un serveur proxy est un intermédiaire utilisé pour les requêtes réseau. Un serveur proxy peut être décrit à l’aide de son adresse, ainsi que du schéma de proxy qui doit être utilisé pour communiquer avec lui.

Cet identificateur peut être écrit sous forme de chaîne à l’aide du « format PAC » ou du « format URI ».

Le format PAC est la façon dont on nomme un serveur proxy dans Scripts de configuration automatique proxy . Par exemple :

PROXY foo:2138 SOCKS5 foo:1080 DIRECT

À la place, le « format URI » encode les informations sous la forme d’une URL. Par exemple :

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

Le numéro de port est facultatif dans les deux formats. En cas d’omission, une valeur par défaut par schéma est utilisée.

Consultez la section Schémas de serveur proxy pour plus d’informations sur les schémas pris en charge par Edge et sur la façon de les écrire dans les formats PAC et URI.

La plupart des surfaces d’interface utilisateur dans Edge (y compris les lignes de commande et la stratégie) attendent des identificateurs de serveur proxy au format URI. Toutefois, en dehors de Edge, les serveurs proxy sont identifiés avec moins de précision lors de l’utilisation d’une seule adresse : le schéma de proxy est supposé en fonction du contexte.

Dans les paramètres de proxy de Windows, il existe des champs hôte et de port pour le proxy « HTTP », « Sécurisé », « FTP » et « SOCKS ». À l’exception de « SOCKS », il s’agit de tous les identificateurs des serveurs proxy HTTP non sécurisés (le schéma de proxy est supposé http).

Résolution du proxy

Le proxy dans Edge s’effectue au niveau de l’URL.

Lorsque le navigateur est invité à extraire une URL, il doit décider du point de terminaison IP auquel envoyer la requête. Il peut s’agir d’un serveur proxy ou de l’hôte cible.

C’est ce qu’on appelle la résolution de proxy. L’entrée pour la résolution du proxy est une URL et la sortie est une liste ordonnée d’identificateurs de serveur proxy.

Les proxys à utiliser peuvent être décrits à l’aide de :

Paramètres de proxy manuels : la résolution de proxy est définie à l’aide d’un ensemble déclaratif de règles. Ces règles sont exprimées sous la forme d’un mappage entre le schéma d’URL et les identificateurs de serveur proxy, et une liste de règles de contournement de proxy pour quand passer à DIRECT au lieu d’utiliser le proxy mappé.

Script PAC : la résolution de proxy est définie à l’aide d’un programme JavaScript, qui est appelé chaque fois que vous extrayez une URL pour obtenir la liste des identificateurs de serveur proxy à utiliser.

Détection automatique : le protocole WPAD est utilisé pour sonder le réseau (à l’aide de DHCP/DNS) et éventuellement découvrir l’URL d’un script PAC.

Schémas de serveur proxy

Lors de l’utilisation d’un proxy explicite dans le navigateur, plusieurs couches de la requête réseau sont affectées, en fonction du schéma utilisé. Voici quelques implications du schéma de proxy :

La communication avec le proxy s’effectue-t-elle via un canal sécurisé ? La résolution de noms (par exemple, DNS) est-elle effectuée côté client ou côté proxy ? Quels schémas d’authentification sur le serveur proxy sont pris en charge ? Quel trafic réseau peut être envoyé via le proxy ? Edge prend en charge les schémas de serveur proxy suivants :

Schéma de proxy DIRECT

Port par défaut : N/A (ni l’hôte ni le port ne sont applicables) Exemple d’identificateur (PAC) : DIRECT exemple d’identificateur (URI) : direct:// il s’agit d’un schéma de pseudo proxy qui indique au lieu d’utiliser un proxy que nous envoyons la requête directement au serveur cible.

Il est imprécis d’appeler cela un « serveur proxy », mais il s’agit d’une abstraction pratique.

Schéma de proxy HTTP

Port par défaut : 80 Exemple d’identificateur (PAC) : PROXY proxy:8080, proxy (non standard ; n’utilisez pas) Identificateurs d’exemple (URI) : http://proxy:8080, proxy:8080 (peut omettre le schéma) En règle générale, quand on fait référence à un « serveur proxy » ou à un « proxy web », ils parlent d’un proxy HTTP.

Lors de l’utilisation d’un proxy HTTP dans Edge, la résolution de noms est toujours différée au proxy. Les proxys HTTP peuvent proxyer http://des URL , https://et ws://wss:// .

La communication avec les serveurs proxy HTTP n’est pas sécurisée, ce qui signifie que les requêtes proxiées http:// sont envoyées en clair. Lors du proxy des https:// demandes via un proxy HTTP, l’échange TLS est transféré via le proxy à l’aide de la méthode CONNECT, de sorte que le chiffrement de bout en bout n’est pas interrompu. Toutefois, lors de l’établissement du tunnel, le nom d’hôte de l’URL cible est envoyé au serveur proxy en clair.

Les proxys HTTP dans Edge prennent en charge les mêmes schémas d’authentification HTTP que pour les serveurs cibles : De base, Digest, Negotiate, NTLM.

Schéma de proxy HTTPS

Port par défaut : 443 Exemple d’identificateur (PAC) : HTTPS proxy:8080 Exemple d’identificateur (URI) : https://proxy:8080

Cela fonctionne comme un proxy HTTP, sauf que la communication avec le serveur proxy est protégée par TLS et peut négocier HTTP/2 (mais pas QUIC).

Étant donné que la connexion au serveur proxy est sécurisée, https:// les requêtes envoyées via le proxy ne sont pas envoyées en clair comme avec un proxy HTTP. De même, étant donné que les requêtes CONNECT sont envoyées sur un canal protégé, les noms d’hôte des URL par https:// proxy ne sont pas non plus révélés.

En plus des méthodes d’authentification HTTP habituelles, les proxys HTTPS prennent également en charge les certificats clients.

Les proxys HTTPS utilisant HTTP/2 peuvent offrir de meilleures performances dans Edge qu’un proxy HTTP standard en raison de limites de connexion plus élevées (les proxys HTTP/1.1 dans Edge sont limités à 32 connexions simultanées sur tous les domaines).

Edge, Firefox et Opera prennent en charge les proxys HTTPS ; Toutefois, la plupart des piles HTTP plus anciennes ne le font pas.

La spécification d’un proxy HTTPS n’est pas possible via les paramètres de proxy système. Au lieu de cela, vous devez utiliser un script PAC ou un paramètre de proxy Edge (ligne de commande, extension ou stratégie).

Schéma de proxy SOCKSv4

Port par défaut : 1080 Exemples d’identificateurs (PAC) : SOCKS4 proxy:8080, SOCKS proxy:8080 Identificateur d’exemple (URI) : socks4://proxy:8080 SOCKSv4 est un proxy de couche de transport simple qui encapsule un socket TCP. Son utilisation est transparente pour le reste de la pile de protocoles ; après une négociation initiale lors de la connexion du socket TCP (au proxy), le reste de la pile de chargement reste inchangé.

Aucune méthode d’authentification de proxy n’est prise en charge pour SOCKSv4.

Lors de l’utilisation d’un proxy SOCKSv4, la résolution de noms pour les hôtes cibles est toujours effectuée côté client et doit en outre être résolue en adresse IPv4 (SOCKSv4 encode l’adresse cible en quatre octets, de sorte que les cibles IPv6 ne sont pas possibles).

Il existe des extensions à SOCKSv4 qui autorisent la résolution de noms côté proxy et IPv6, à savoir SOCKSv4a. Toutefois, Edge n’autorise pas la configuration ou ne revient pas à la version v4a.

Une meilleure alternative consiste à utiliser simplement la version la plus récente du protocole, SOCKSv5 (qui date encore de plus de 20 ans).

Schéma de proxy SOCKSv5

Port par défaut : 1080 Exemple d’identificateur (PAC) : SOCKS5 proxy:8080 Exemples d’identificateurs (URI) : socks://proxy:8080, socks5://proxy:8080

SOCKSv5 est un proxy de couche de transport qui encapsule un socket TCP et permet de reporter la résolution de noms au proxy.

Dans Edge, lorsque le schéma d’un proxy est défini sur SOCKSv5, la résolution de noms est toujours effectuée côté proxy (même si le protocole autorise également le côté client). Dans Firefox, la résolution de noms côté client et côté proxy peut être configurée avec network.proxy.socks_remote_dns; Edge n’a aucune option équivalente et utilise toujours la résolution côté proxy.

Aucune méthode d’authentification n’est prise en charge pour SOCKSv5 dans Edge (bien que certaines existent pour le protocole).

Un moyen pratique de créer un proxy SOCKSv5 est avec ssh -D, qui peut être utilisé pour tunneliser le trafic web vers un hôte distant via SSH.

Dans Edge, SOCKSv5 est utilisé uniquement pour proxyer les demandes d’URL basées sur TCP. Il ne peut pas être utilisé pour relayer le trafic UDP.

Paramètres de proxy manuels

Le moyen le plus simple de configurer la résolution du proxy consiste à fournir une liste statique de règles composées des éléments suivants :

Un mappage de schémas d’URL aux identificateurs de serveur proxy Liste des règles de contournement de proxy Nous faisons référence à ce mode de configuration en tant que « paramètres de proxy manuels ».

Les paramètres de proxy manuels peuvent décrire succinctement des configurations telles que :

Utiliser le proxy http://foo:8080 pour toutes les demandes Utilisez le proxy http://foo:8080 pour toutes les demandes, à l’exception de celles adressées à un contoso.com sous-domaine, utilisez le proxy http://foo:8080 pour toutes les https:// demandes et le proxy socks5://mysocks:90 pour tout le reste Bien que les paramètres de proxy manuels soient un moyen omniprésent de configurer des proxys sur plusieurs plateformes, il n’existe pas de représentation standard ni d’ensemble de fonctionnalités.

Les paramètres de proxy manuels de Edge ressemblent le plus à ceux de WinInet. Mais il prend également en charge les idiomes d’autres plateformes - pour instance la notion de KDE d’inverser la liste de contournement, ou l’interprétation de Gnome des modèles de contournement en tant que correspondance de suffixe.

Lors de la définition de paramètres de proxy manuels dans Edge, nous spécifions trois listes (éventuellement vides) d’identificateurs de serveur proxy :

proxys pour HTTP - Liste des identificateurs de serveur proxy à utiliser pour http:// les demandes, si les proxys non vides pour HTTPS - Liste des identificateurs de serveur proxy à utiliser pour https:// les requêtes, si aucun autre proxy n’est pas utilisé - Liste des identificateurs de serveur proxy à utiliser pour tout le reste (non mis en correspondance par les deux autres listes). Il existe de nombreuses façons de se retrouver avec des paramètres de proxy manuels dans Edge (abordés dans d’autres sections).

Les exemples suivants utilisent la méthode de ligne de commande. Lancement d’Edge avec --proxy-server=XXX (et éventuellement --proxy-bypass-list=YYY)

Exemple : Pour utiliser le proxy http://foo:8080 pour toutes les demandes, nous pouvons lancer Edge avec --proxy-server="http://foo:8080". Cela se traduit par :

proxys pour HTTP - proxys vides pour HTTPS - autres proxys vides - http://foo:8080 Avec la configuration ci-dessus, si le serveur proxy était inaccessible, toutes les requêtes échouent avec ERR_PROXY_CONNECTION_FAILED. Pour résoudre ce problème, nous pourrions ajouter un secours à DIRECT en lançant à l’aide --proxy-server="http://foo:8080,direct://" de (notez la liste séparée par des virgules). Cette ligne de commande signifie :

proxys pour HTTP - proxys vides pour HTTPS - autres proxys vides - http://foo:8080, direct:// si au lieu de cela nous voulions proxy uniquement http:// des URL via le proxy https://foo:443HTTPS , et que tout le reste utilise le proxy socks5://mysocks:1080 SOCKSv5, nous pourrions lancer Edge avec --proxy-server="http=https://foo:443;socks=socks5://mysocks:1080". Cela s’étend maintenant à :

proxys pour HTTP - https://foo:443 proxys pour HTTPS - autres proxys vides - socks5://mysocks:1080 La ligne de commande ci-dessus utilise le format de carte de proxy de WinInet, avec quelques fonctionnalités supplémentaires :

Au lieu de nommer les serveurs proxy par un hostname:portsimple , vous pouvez utiliser le format d’URI d’Edge pour les identificateurs de serveur proxy. En d’autres termes, vous pouvez préfixer le schéma de proxy afin qu’il ne soit pas défini par défaut sur HTTP. Le socks= mappage est compris plus largement comme « autres proxys ». La liste de proxys suivante peut inclure des proxys de n’importe quel schéma, mais si le schéma est omis, il sera compris comme SOCKSv4 plutôt que HTTP.

Mappage d’URL WebSocket à un proxy

Les paramètres de proxy manuels n’ont pas de mappages pour ws:// les URL ou wss:// .

La sélection d’un proxy pour ces schémas d’URL est légèrement différente des autres schémas d’URL. L’algorithme utilisé par Edge est :

Si « autres proxys » n’a pas de valeur, utilisez-le Si « proxys pour HTTPS » n’est pas utilisé, utilisez-le Sinon, utilisez « proxys pour HTTP » Ceci est conformément à la recommandation de la section 4.1.3 de la RFC 6455.

Il est possible d’acheminer ws:// et wss:// séparément à l’aide d’un script PAC.

Informations d’identification du proxy dans les paramètres de proxy manuels

Les paramètres de proxy manuel de la plupart des plateformes permettent de spécifier un nom d’utilisateur/mot de passe en texte clair pour la connexion au proxy. Edge n’implémente pas cela et n’utilise pas d’informations d’identification incorporées dans les paramètres du proxy.

L’authentification proxy passe plutôt par le flux ordinaire pour rechercher les informations d’identification.

Règles de contournement du proxy

En plus de spécifier trois listes d’identificateurs de serveur proxy, les paramètres de proxy manuels d’Edge vous permettent de spécifier une liste de « règles de contournement de proxy » à l’aide de modèles d’URL.

Cet ensemble de règles détermine si une URL donnée doit ignorer l’utilisation d’un proxy ensemble, même lorsqu’un proxy est défini pour elle.

Ce concept est également connu sous des noms tels que « liste d’exceptions », « liste d’exclusion » ou « aucune liste de proxy ».

Les règles de contournement du proxy peuvent être écrites sous la forme d’une liste ordonnée de chaînes. Le classement n’a généralement pas d’importance, mais peut être utilisé lors de l’utilisation de règles soustractives.

Lorsque des paramètres de proxy manuels sont spécifiés à partir de la ligne de commande, le --proxy-bypass-list="RULES" commutateur peut être utilisé, où RULES est une liste de règles de contournement séparées par des points-virgules ou des virgules.

Consultez Modèles d’URL de configuration du proxy pour connaître le format des modèles d’URL pris en charge par Edge pour les règles de contournement de proxy.

Lorsque vous utilisez des paramètres de proxy système, vous devez utiliser le format de règle de la plateforme et non celui d’Edge.

Modèles d’URL de configuration du proxy

Cette section décrit les constructions de chaînes qu’Edge prend en charge pour spécifier des modèles d’URL dans le contexte de la configuration du proxy, par exemple, des règles de contournement de proxy ou pour la DestinationMatchers valeur de la ProxyOverrideRules stratégie. Ces modèles peuvent être utilisés lors de la définition d’un paramètre de proxy manuel Edge à partir d’indicateurs de ligne de commande, d’extensions ou de stratégie.

Modèles d’URL de configuration du proxy : nom d’hôte

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

Correspond à un nom d’hôte à l’aide d’un modèle générique et d’un schéma facultatif et d’une restriction de port.

Exemples :

foobar.com- Correspond à l’URL d’un schéma et d’un port, dont l’hôte normalisé est foobar.com*foobar.com - Correspond à l’URL de tout schéma et port, dont l’hôte normalisé se termine par foobar.com (pour instance blahfoobar.com et foo.foobar.com) *.org:443 - Correspond aux URL de n’importe quel schéma, à l’aide du port 443 et dont le domaine de niveau supérieur est .orghttps://x.*.y.com:99 - Correspond aux https:// URL sur le port 99 dont le nom d’hôte normalisé correspondx.*.y.com

Modèles d’URL de configuration du proxy : Sous-domaine

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

Les modèles de nom d’hôte qui commencent par un point sont casés spéciaux pour signifier qu’un sous-domaine correspond. .foo.com est effectivement une autre façon d’écrire *.foo.com.

Exemples :

.contoso.com - Correspond outlook.contoso.com à et foo.bar.contoso.com, mais pas contoso.comhttp://.contoso.com - Correspond uniquement http:// aux URL qui sont un sous-domaine de contoso.com

Modèles d’URL de configuration du proxy : littéral IP

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

Correspond aux URL qui sont des littéraux d’adresse IP et des restrictions de schéma et de port facultatives. Il s’agit d’un cas particulier de correspondance de nom d’hôte qui prend en compte la canonisation littérale IP. Par exemple, les règles [0:0:0::1] et [::1] sont équivalentes (les deux représentent la même adresse IPv6).

Exemples :

127.0.0.1 http://127.0.0.1 [::1] - Correspond à n’importe quelle URL de l’adresse [0:0::1] de bouclage IPv6 - Identique à celle ci-dessus http://[::1]:99 - Correspond à n’importe quelle http:// URL du bouclage IPv6 sur le port 99

Modèles d’URL de configuration du proxy : Plage d’adresses IPv4

IPV4_LITERAL "/" PREFIX_LENGTH_IN_BITS

Correspond à toute URL dont le nom d’hôte est un littéral IPv4 et se situe entre la plage d’adresses donnée.

Notez que cela s’applique uniquement aux URL qui sont des littéraux IP.

Exemples :

192.168.1.1/16

Modèles d’URL de configuration du proxy : Plage d’adresses IPv6

IPV6_LITERAL "/" PREFIX_LENGTH_IN_BITS

Correspond à toute URL qui est un littéral IPv6 qui se trouve entre la plage donnée. Les littéraux IPv6 ne doivent pas être placés entre crochets.

Notez que cela s’applique uniquement aux URL qui sont des littéraux IP.

Exemples :

fefe:13::abc/33 [fefe::]/40 --ERREUR! Les littéraux IPv6 ne doivent pas être placés entre crochets

Modèles d’URL de configuration du proxy : noms d’hôte simples

<local>

Correspond aux noms d’hôte sans point, et qui ne sont pas des littéraux IP. Il s’agit d’une recherche de chaîne naïve, ce qui signifie que les points apparaissant n’importe où comptent (y compris les points de fin !).

Cette règle correspond à la case à cocher « Exclure les noms d’hôte simples » sur macOS et à la case « Ne pas utiliser le serveur proxy pour les adresses locales (intranet) » sur Windows.

Le nom de la règle provient de WinInet et peut facilement être confondu avec le concept de localhost. Toutefois, les deux concepts sont orthogonaux. Dans la pratique, il n’est pas possible d’ajouter des règles pour contourner localhost, car c’est déjà fait implicitement.

Modèles d’URL de configuration du proxy : soustraire des règles implicites

<-loopback>

Soustrait les règles de contournement de proxy implicites (localhost et les adresses locales de liaison). Cela n’est nécessaire que pour les configurations de test. Méfiez-vous des implications de sécurité pour le proxy localhost.

Alors que les règles de contournement régulières indiquent au navigateur les URL qui ne doivent pas utiliser le proxy, cette règle a l’effet inverse et indique au navigateur d’utiliser le proxy à la place.

Le classement peut être important lors de l’utilisation d’une règle soustractive, car les règles sont évaluées dans un ordre de gauche à droite. <-loopback>;127.0.0.1 a un effet subtilement différent de 127.0.0.1;<-loopback>.

Signification des règles de contournement de plage d’adresses IP

La règle de contournement de plage d’adresses IP dans les paramètres de proxy manuels s’applique uniquement aux littéraux d’URL. Ce n’est pas ce à quoi on s’attendrait intuitivement.

Exemple :

Supposons que nous avons configuré un proxy pour toutes les demandes, mais que nous avons ajouté une règle de contournement pour 192.168.0.0.1/16. Si nous accédons maintenant à http://foo (ce qui se résout 192.168.1.5 dans notre configuration), le navigateur se connecte directement (contourner le proxy), car nous avons indiqué une règle de contournement qui inclut cette adresse IP ?

Il passe par le proxy.

Dans ce cas, la règle de contournement n’est pas applicable, car le navigateur n’effectue jamais réellement de résolution de noms pour foo. La résolution de proxy se produit avant la résolution de noms, et selon le schéma de proxy choisi ultérieurement, la résolution de noms côté client peut ne jamais être effectuée.

L’utilité des règles de contournement de proxy de plage d’adresses IP est plutôt limitée, car elles s’appliquent uniquement aux requêtes dont l’URL était explicitement un littéral IP.

Si des décisions de proxy doivent être prises en fonction des adresses IP résolues du nom d’hôte d’une URL, vous devez utiliser un script PAC.

Règles de contournement implicites

Les demandes adressées à certains hôtes ne seront pas envoyées via un proxy et seront envoyées directement.

Nous appelons ces règles de contournement implicites. Les règles de contournement implicites correspondent aux URL dont la partie hôte est un nom localhost ou un littéral d’adresse IP locale de lien. Essentiellement, il correspond à :

localhost *.localhost [::1] 127.0.0.1/8 169.254/16 [FE80::]/10 Les règles complètes sont un peu plus compliquées. Pour instance sur Windows, nous reconnaissons loopbackégalement .

Ce concept de règles de contournement de proxy implicites est cohérent avec la prise en charge du proxy au niveau de la plateforme sur Windows et macOS (bien qu’avec quelques différences en raison de leurs bizarres d’implémentation - voir les notes de compatibilité dans net::ProxyHostMatchingRules::MatchesImplicitRules)

Pourquoi appliquer des règles de contournement de proxy implicites en premier lieu ? Certes, il y a des considérations concernant l’ergonomie et les attentes des utilisateurs, mais le plus grand problème est la sécurité. Étant donné que la plateforme web traite localhost comme une origine sécurisée, la possibilité de proxy lui accorde des pouvoirs supplémentaires. Cela est particulièrement problématique lorsque les paramètres de proxy sont contrôlables en externe, comme lors de l’utilisation de scripts PAC.

Remplacement des règles de contournement implicites

Si vous souhaitez que le trafic vers localhost soit envoyé via un proxy malgré les problèmes de sécurité, vous pouvez ajouter la règle <-loopback>de contournement de proxy spéciale . Cette règle a pour effet de soustraire les règles implicites.

Pour instance, lancez Edge avec l’indicateur de ligne de commande :

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

Il n’existe actuellement aucun mécanisme pour désactiver les règles de contournement implicites du proxy lors de l’utilisation d’un script PAC. Les règles de contournement de proxy s’appliquent uniquement aux paramètres manuels. Cette technique ne peut donc pas être utilisée pour permettre aux scripts PAC de décider du proxy pour les URL localhost.

Licence de contenu

Remarque

Certaines parties de cette page sont des modifications basées sur le travail créé et partagé par Chromium.org et utilisé conformément aux conditions décrites dans la Licence internationale Creative Commons Attribution 4.0. La page Chromium d’origine est disponible ici.

Licence Creative Commons
Ce travail est concédé sous une Licence internationale Creative Commons Attribution 4.0.

  • Last updated on