Comment ce "portail captif" intercepte et manipule mes requêtes HTTP?
J'utilise parfois un service Wifi gratuit pour accéder à Internet.
Comme la plupart/tous les fournisseurs de services comme celui-ci, ce service utilise un portail captif . Donc, si vous essayez de faire une requête HTTP (demandez une page Web) dans votre navigateur et que vous n'êtes pas autorisé sur le réseau, vous ne verrez que la page qui dit "Welcome to Free -wifi network. voici nos termes etc ... "
Je ne suis pas intéressé à abuser du service pour le wifi gratuit - Je veux savoir quelles informations (transactions HTTP) sont exposées/non sécurisées lorsque j'utilise ce service et quels changements persistants ils apportent à mon système, c'est-à-dire se cacher cookies dans mon navigateur (en utilisant des hôtes anonymes).
Je me suis donc connecté à leur point d'accès wifi, auquel point ils attribuent à mon ordinateur une adresse IP et un service DNS, etc.
$ nmcli device show wlp2s0
IP4.ADDRESS[1]: 192.168.12.199/22
IP4.GATEWAY: 192.168.12.1
IP4.ROUTE[1]: dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000
IP4.DNS[1]: 123.123.xxx.xxx
IP4.DNS[2]: 123.123.xxx.xxx
J'essaie ensuite une demande HTTP - essayez de "naviguer vers une page Web" sans être encore autorisé. (Étant HTTP, cette demande/réponse ne sera pas chiffrée, aucune vérification d'identité sur le serveur traitant la demande [via. Confirmation de l'autorité de certification SSL via des signatures de clés publiques/privées, etc.])
$ curl 'http://placeimg.com/' -H 'Host: placeimg.com'
-H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0'
-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' -v -L
* Trying 216.243.142.217...
* Connected to placeimg.com (216.243.142.217) port 80 (#0)
> GET / HTTP/1.1
> Host: placeimg.com
>
< HTTP/1.1 302 Found
< Location: http://1.1.2.1:80/reg.php?ah_goal=auth-tc.html&ah_login=true&url=E2B8F357812412D8
<
* Ignoring the response-body
* Connection #0 to Host placeimg.com left intact
* Issue another request to this URL:
'http://1.1.2.1:80/reg.php?ah_goal=auth-tc.html&ah_login=true&url=E2B8F35792412D8'
* Connection 0 seems to be dead!
* Closing connection 0
* Trying 1.1.2.1...
* Connected to 1.1.2.1 (1.1.2.1) port 80 (#1)
> GET /reg.php?ah_goal=auth-tc.html&ah_login=true&url=E2B8F8 HTTP/1.1
> Host: 1.1.2.1
> User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-US,en;q=0.5
>
< HTTP/1.1 200 OK
< Date: Mon, 08 Aug 2016 02:50:16 GMT
< Connection: keep-alive
< Transfer-Encoding: chunked
< Content-type: text/html; charset=utf-8
<
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta name="viewport" content="width=device-width"/>
<title>Login</title>
<h1>WiFi - Free Internet Access</h1>
This service is provided primarily for the purposes of accessing Email and light web browsing ..
....
</div>
</body>
</html>
J'ai tronqué et expurgé la sortie, mais il semble que lorsque mon navigateur (curl) demande que le réseau donne accès à un vrai serveur DNS, je l'ai testé davantage en l'exécutant tout en étant connecté au service.
$Dig +short google.com
203.118.141.95
203.118.141.123
... (basically real ip addresses for google.com)
Il semble donc que le service fournit des informations réelles et véridiques sur le DNS,
Mais même si l'adresse IP à laquelle mon navigateur s'adresse semble valide, la réponse HTTP qui revient, ne provient pas du serveur prévu (c'est un serveur qui a été inséré par le service WiFi). La réponse est
302en disant à mon navigateur de faire une nouvelle demande, au1.1.2.1/reg.phpserveur et URL- la réponse de ce serveur/URL est la page "portail captif".
Quand faire une demande HTTPS
$ curl 'https://google.com/' -H 'Host: google.com' -H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' -H 'Accept-Language: en-US,en;q=0.5' -v -L
* Trying 216.58.220.142...
* connect to 216.58.220.142 port 443 failed: Connection refused
* Trying 2404:6800:4006:800::200e...
* Immediate connect fail for 2404:6800:4006:800::200e: Network is unreachable
* Trying 2404:6800:4006:800::200e...
* Immediate connect fail for 2404:6800:4006:800::200e: Network is unreachable
* Failed to connect to google.com port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to google.com port 443: Connection refused
La demande échoue carrément - je suppose que mon ordinateur n'accepte pas une connexion d'un hôte distant qu'il ne peut pas authentifier?
Ma question est donc la suivante: s'agit-il d'une interception de type "homme au milieu" au niveau TCP/IP? en d'autres termes, lorsque la pile réseau de mon ordinateur tente d'établir une connexion TCP avec le placeimg.com serveur, en démarrant une prise de contact à 3 voies, est la passerelle de services Wifi ou le nœud de réseau répondant à mon SYN avec un ACK/SYN et disant oui je suis le serveur avec lequel vous vouliez parler - permet de terminer notre TCP , puis une fois établie sa préprogrammée pour envoyer automatiquement la redirection HTTP, puis, parce que mon navigateur génère réellement la prochaine demande à 1.1.2.1 lui-même - toutes les "affaires drôles" peuvent s'arrêter et son comportement HTTP/HTML normal à partir de ce moment. (c.-à-d. remplir et soumettre un formulaire standard comme vous le feriez sur n'importe quel site Web normal)
Sinon, comment cette passerelle intercepte-t-elle et réachemine-t-elle mes demandes alors que je suis un utilisateur "non authentifié"?
Ma question est donc la suivante: s'agit-il d'une interception de type "homme au milieu" au niveau TCP/IP?
Oui, il s'agit d'un interception de type intermédiaire, ce qui est facile pour le point d'accès car il se trouve en fait au milieu de votre connexion à Internet. De telles redirections vers le portail de capture se font facilement avec un filtre de paquets.
La manière habituelle est qu'une fois que vous avez autorisé (connecté, conditions acceptées, peu importe ...) une règle temporaire sera ajoutée au filtre de paquets du point d'accès qui prend la préférence sur la règle de redirection et permet un accès direct à Internet .
Quand faire une demande HTTPS La demande échoue purement et simplement - je suppose que mon ordinateur n'acceptera pas une connexion d'un hôte distant qu'il ne peut pas authentifier?
Il semble qu'ils n'essaient même pas d'intercepter votre connexion HTTP et la bloquent simplement.
Certains portails captifs tentent d'intercepter la connexion HTTP, ce qui entraîne une erreur de certificat dans votre client.
J'ai également vu des portails captifs qui permettent aux HTTP même pour les utilisateurs non authentifiés.
Ma question est donc la suivante: s'agit-il d'une interception de type "homme au milieu" au niveau TCP/IP? en d'autres termes, lorsque la pile réseau de mon ordinateur tente d'établir une connexion TCP avec le serveur placeimg.com, en démarrant une prise de contact à 3 voies, la passerelle de services Wifi ou le nœud de réseau répond-il à mon SYN avec un ACK/SYN et en disant oui je suis le serveur auquel vous vouliez parler - permet de terminer notre TCP, puis une fois établi son préprogrammé pour envoyer automatiquement la redirection HTTP et ensuite, parce que mon navigateur génère en fait la prochaine demande à 1.1.2.1 lui-même - toutes les "affaires drôles" peuvent s'arrêter et son comportement HTTP/HTML normal à partir de ce moment (c'est-à-dire le remplissage et la soumission de formulaires standard comme vous le feriez sur tout site Web normal)
Oui, c'est la façon normale de le faire. Si le serveur de portail captif est basé sur Linux, les cibles "REDIRECT" ou "DNAT" peuvent être utilisées pour détourner votre trafic vers le serveur Web des portails captifs qui peut ensuite émettre la redirection. D'autres systèmes de pare-feu avec état ont probablement des options similaires.
Ces systèmes sont généralement assez flexibles, donc si l'opérateur du portail souhaite offrir l'accès à des parties particulières d'Internet (par exemple une passerelle de paiement afin que vous puissiez les payer) sans authentification, il peut facilement le faire.
Lorsque vous vous authentifiez avec succès, le portail captif peut mettre en place une règle qui remplace la règle de redirection vous permettant un accès normal à Internet.
Notez que tous les cookies (non sécurisés) définis pour le site Web que vous avez essayé de visiter seront envoyés au serveur Web du portail captif. C'est à l'implémentateur du portail captif qu'il appartient de faire quoi que ce soit avec eux.