La JVM permet les propriétés proxy http.proxyHost et http.proxyPort pour spécifier un serveur proxy HTTP et https.proxyHost et https.proxyPort pour spécifier un serveur proxy HTTPS.
Je me demande s'il y a des avantages à utiliser un serveur proxy HTTPS par rapport à un serveur proxy HTTP ?
Est-ce que l'accès à une URL https via un proxy HTTPS est moins contraignant que de l'accéder depuis un proxy HTTP ?
Le proxy HTTP reçoit une requête en texte clair et [dans la plupart des cas, mais pas tous] envoie une requête HTTP différente au serveur distant, puis renvoie des informations au client.
Le proxy HTTPS est un relais, qui reçoit une requête HTTP spéciale (verbe CONNECT) et établit un tunnel opaque vers le serveur de destination (qui n'est pas nécessairement même un serveur HTTPS). Ensuite, le client envoie une requête SSL/TLS au serveur et ils continuent avec l'handshake SSL puis avec HTTPS (si demandé).
Comme vous le voyez, ce sont deux types de proxy complètement différents avec des comportements et des objectifs de conception différents. Le proxy HTTPS ne peut pas mettre en cache quoi que ce soit car il ne voit pas la requête envoyée au serveur. Avec le proxy HTTPS, vous avez un canal vers le serveur et le client reçoit et valide le certificat du serveur (et éventuellement vice versa). Le proxy HTTP, en revanche, voit et contrôle la requête qu'il a reçue du client.
Alors que la requête HTTPS peut être envoyée via un proxy HTTP, cela est presque jamais fait car dans ce scénario le proxy va valider le certificat du serveur, mais le client ne pourra recevoir et valider que le certificat du proxy, et comme le nom dans le certificat du proxy ne correspondra pas à l'adresse à laquelle la socket est connectée, dans la plupart des cas une alerte sera donnée et l'handshake SSL ne réussira pas (je ne rentre pas dans les détails de comment essayer de résoudre cela).
Enfin, comme le proxy HTTP peut examiner la requête, cela invalide l'idée de sécurité fournie par le canal HTTPS, il est donc normalement utilisé uniquement à des fins de débogage (encore une fois, nous omettons les cas de politiques de sécurité paranoides de l'entreprise qui exigent la surveillance de tout le trafic HTTPS des employés de l'entreprise).
Remarque: consultez également ma réponse sur un sujet similaire ici.
Il n'y a ni avantages ni inconvénients. Et il n'y a pas de serveur "proxy HTTPS".
Vous pouvez indiquer aux gestionnaires de protocole quel serveur proxy utiliser pour différents protocoles. Cela peut être fait pour http, https, ftp et socks. Pas plus, pas moins.
Je ne peux pas vous dire si vous devriez utiliser un proxy différent pour les connexions https ou non. Cela dépend. Je peux juste expliquer la différence entre une demande http et https à un proxy.
Puisque le Proxy HTTP (ou proxy web) comprend HTTP (d'où le nom), le client peut simplement envoyer la requête au serveur proxy au lieu de la destination réelle. Cela ne fonctionne pas pour HTTPS. Cela est dû au fait que le proxy ne peut pas réaliser le handshake TLS, qui se produit au départ. Par conséquent, le client doit envoyer une requête CONNECT au proxy. Le proxy établit une connexion TCP et envoie simplement les paquets d'avant en arrière sans les toucher. Ainsi, le handshake TLS se produit entre le client et la destination. Le serveur proxy HTTP ne voit pas tout et ne valide pas le certificat des serveurs de destination.
Il peut y avoir une certaine confusion avec tout cet aspect http, https, proxy. Il est possible de se connecter à un proxy HTTP avec https. Dans ce cas, la communication entre le client et le proxy est chiffrée.
Il existe également des serveurs proxy dits terminaux TLS ou d'interception comme Squid's SSL Peek and Splice ou burp, qui voient tout. Mais cela ne devrait pas fonctionner immédiatement, car le proxy utilise ses propres certificats qui ne sont pas signés par des AC de confiance.
Malheureusement, "proxy HTTPS" a deux significations distinctes :
Dans le cas où le navigateur tente de se connecter à un site Web en utilisant HTTPS, le navigateur enverra une demande CONNECT au proxy, et le proxy établira une connexion TCP avec le site Web et reflétera tout le trafic TCP envoyé sur la connexion du navigateur vers le proxy sur la connexion entre le proxy et le site Web, et reflétera de manière similaire la charge utile des paquets TCP de réponse du site Web vers la connexion avec le navigateur. En théorie, le même mécanisme utilisant CONNECT pourrait être utilisé avec le trafic HTTP, mais en pratique, les navigateurs ne le font pas. Pour le trafic HTTP, ils envoient la demande HTTP réelle au proxy, y compris le chemin complet dans la commande HTTP (ainsi que la définition de l'en-tête Host) : https://stackoverflow.com/a/38259076/10026
Ainsi, selon cette définition, un proxy HTTPS est un proxy qui comprend la directive CONNECT et peut prendre en charge le trafic HTTPS allant entre le navigateur et le site Web.
Dans ce mode (parfois appelé "proxy sécurisé"), le navigateur utilise le certificat du proxy pour effectuer un handshake TLS avec le proxy, puis envoie du trafic HTTP ou HTTPS, (y compris des demandes CONNECT), sur cette connexion conformément à (1). Ainsi, la connexion entre le navigateur et le proxy est toujours protégée par une clé TLS dérivée en utilisant le certificat du proxy, indépendamment de savoir si le trafic lui-même est chiffré avec une clé négociée entre le navigateur et le site Web. Si le trafic HTTPS est relayé via un proxy sécurisé, il est doublement chiffré sur la connexion entre le navigateur et le proxy.
Par exemple, le plugin Chrome Proxy Switcher propose deux paramètres séparés pour contrôler chacune de ces fonctionnalités :
En 2022, l'option d'utilisation d'un proxy sécurisé n'est pas disponible dans l'interface de configuration manuelle du proxy pour MacOS et Windows. Mais un proxy sécurisé peut être spécifié dans un fichier PAC utilisé dans la configuration automatique du proxy en utilisant la directive proxy HTTPS. Il revient à l'application consommatrice de prendre en charge la directive HTTPS ; la plupart des navigateurs majeurs, à l'exception de Safari, et de nombreuses applications de bureau la prennent en charge.
REMARQUE : Les choses deviennent un peu plus compliquées car certains proxies qui relayent le trafic HTTPS ne transfèrent pas simplement la charge utile des paquets TCP, comme décrit en (1), mais agissent comme des Proxies Intercepteurs. En utilisant un certificat de site Web falsifié, ils effectuent effectivement une attaque de l'homme du milieu (eh bien, ce n'est pas nécessairement une attaque car c'est un comportement attendu). Alors que le navigateur pense utiliser le certificat du site Web pour établir un tunnel TLS avec le site Web, il utilise en réalité un certificat falsifié pour établir un tunnel TLS avec le proxy, et le proxy établit le tunnel TLS avec le site Web. Ensuite, le proxy a une visibilité sur les demandes/réponses HTTPS. Mais tout cela est complètement orthogonal à la question de savoir si le proxy agit en tant que proxy sécurisé selon (2).
Si vous entendez par connexion à un serveur proxy HTTP via TLS en disant proxy HTTPS, alors
Je me demandais s'il y a des avantages à utiliser un serveur proxy HTTPS par rapport à un serveur proxy HTTP ?
L'avantage est que la connexion de votre client au serveur proxy est chiffrée. Par exemple, un pare-feu ne peut pas voir à quel hôte vous utilisez la méthode CONNECT pour vous connecter.
Accéder à une URL https via un proxy HTTPS est-il moins contraignant que l'accès depuis un proxy HTTP ?
Tout est pareil sauf qu'avec un proxy HTTPS, la connexion du navigateur au serveur proxy est chiffrée.
Mais vous devez déployer un certificat sur votre serveur proxy, comme le fait un site web https, et utiliser un fichier pac pour configurer le navigateur afin d'activer la connexion à un proxy via SSL.
Pour plus de détails et un exemple pratique, consultez ma question et ma réponse ici Le serveur proxy HTTPs ne fonctionne que dans SwitchOmega
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
