Comment un pays bloque / censure un site Web crypté (HTTPS)?
Étant donné que le site [~ # ~] x [~ # ~] utilise HTTPS, comment peut-il être bloqué par un pays?
Mon navigateur affiche: cryptage 128 bits | ECDHE_RSA comme échange de clés.
Je dis que c'est bloqué car quand j'utilise Tor, ça marche bien.
Une chose importante à souligner est qu'il n'est pas bloqué dans le sens typique que nous avons l'habitude de voir, qui montre clairement une page qui dit qu'il est bloqué, à la place, site [~ # ~] x [ ~ # ~] est bloqué de manière à ce que mon navigateur ne charge tout simplement pas la page et affiche l'erreur:
Cette page Web n'est pas disponible, Code d'erreur: ERR_CONNECTION_RESET
pour la version HTTPS, et cette page "page bloquée" lors de la demande de la version HTTP.
Notez que aucun autre site HTTPS n'est bloqué! Juste celui-là! Je suppose que c'est une preuve qui exclut le blocage de port et le blocage de protocole. Cependant, il quitte DPI; mais il existe d'autres sites Web bloqués par HTTP dont la version HTTPS fonctionne toujours! S'ils peuvent bloquer le site DPI [~ # ~] x [~ # ~] , pourquoi ne peuvent-ils pas bloquer les autres sites HTTPS de la même manière ?
TL; DR: TLS sécurise uniquement le contenu d'un message. Pas les métadonnées.
Lorsque vous communiquez sur un réseau clair, il est important de se rappeler que certaines parties d'une communication donnée ne peuvent pas être sécurisées à l'aide de technologies standard. À moins que vous n'utilisiez quelque chose comme TOR, votre FAI pourra déterminer à qui vous parlez même si vous utilisez TLS.
Pour utiliser une analogie, imaginez envoyer une enveloppe via le service postal. Le contenu de l'enveloppe est totalement inaccessible à toute personne autre que le destinataire. Même si un facteur devait en quelque sorte voir le contenu, il ne serait pas en mesure de le comprendre (peut-être l'avez-vous d'abord parcouru un chiffre César?.
Cependant, pour que le service postal l'envoie à la bonne adresse, l'extérieur de l'enveloppe doit être marqué d'une représentation clairement lisible de l'adresse de destination. Si le service postal ne voulait pas que quelqu'un puisse envoyer des lettres à "Joe Schmoe, 123 Fake street", alors il ne pourrait tout simplement pas livrer de lettres avec cette adresse.
Étant donné que le service postal ne peut pas lire le contenu du message, il n'a aucun moyen d'identifier l'intention de la lettre. La seule information dont ils disposent est le fait que le destinataire prévu est Joe Schmoe. Ils ne peuvent pas filtrer uniquement les lettres qu'ils jugent malveillantes; c'est tout ou rien.
De même, le protocole IP (le protocole de routage qui TCP s'exécute en haut)) a clairement marqué les champs "expéditeur" et "récepteur". TLS ne peut pas crypter cela pour deux raisons:
- TLS s'exécute au-dessus de TCP/IP et ne peut donc pas modifier des parties des paquets qui appartiennent à ces protocoles.
- Si la section IP était cryptée, le service opérateur (routeurs ISP) ne serait pas en mesure d'identifier où les paquets doivent aller.
Le pare-feu que votre FAI ou votre pays force à traverser tout votre trafic ne peut pas inspecter le trafic TLS. Ils ne connaissent que les métadonnées fournies par le protocole TCP/IP. Ils ont également estimé que le site auquel vous souhaitez accéder était plus mauvais que bon, ils ont donc abandonné tout le trafic vers et depuis le site, quel que soit le contenu.
Il existe une méthode pour sécuriser même les métadonnées des communications en ligne, mais elle est lente et peu évolutive. Les services cachés TOR sont une tentative de mise en œuvre de cela. Bien sûr, les services cachés ne fonctionnent qu'au sein du réseau TOR, auquel on ne peut accéder qu'en se connectant d'abord à une machine via le net net. Cela signifie que le FAI ou le pare-feu sait toujours que vous transférez vos données via l'oignon. Peu importe comment vous essayez, vous fuierez toujours certains métadonnées. S'ils le voulaient, ils pourraient réinitialiser toutes les connexions aux nœuds TOR en plus du site qu'ils bloquent actuellement.
Si vous essayez d'établir une connexion directe à une adresse IP spécifique via un pare-feu et que le pare-feu a des règles explicites pour tuer tout trafic vers ou depuis cette adresse IP donnée, la connexion directe à cette adresse IP sera toujours infructueuse. Vous devrez vous y connecter indirectement, soit via TOR, un VPN ou un autre service proxy.
De nombreux filtres Web gouvernementaux sont mis en œuvre via le filtrage DNS.
Afin de vous connecter à https://www.example.com, Votre navigateur se connecte d'abord au serveur DNS de votre fournisseur de services Internet et demande l'adresse IP de www.example.com. Il établit ensuite une connexion cryptée à l'adresse IP qu'il obtient. Le gouvernement demande donc aux FAI de configurer leurs serveurs DNS pour qu'ils ne renvoient aucune ou une fausse adresse IP pour les sites Web qu'ils souhaitent bloquer.
Pour tester cela, vous pouvez configurer vos paramètres réseau pour utiliser un autre serveur DNS, comme 8.8.8.8 De Google. La procédure à suivre dépend de votre système d'exploitation, mais un guide devrait être facile à trouver.
Une autre méthode de filtrage Web consiste à utiliser l'adresse IP elle-même. Les FAI configurent simplement leurs pare-feu pour bloquer tout le trafic vers l'adresse IP de example.com. Un tel filtre est plus difficile à contourner qu'un filtre DNS, mais cause beaucoup plus de dommages collatéraux. Les grands hébergeurs Web hébergent souvent des milliers voire des millions de sites Web complètement indépendants sur la même adresse IP. Lorsque les FAI bloquent par IP, ils ne peuvent pas bloquer un site spécifique sans bloquer également tous les autres qui partagent l'IP.
Lorsque vous vous connectez à un site Web HTTPS, le nom d'hôte du site Web auquel vous vous connectez est transmis sur le réseau en texte clair dans le cadre de Prise de contact TLS . Le serveur certificat contient toujours le nom d'hôte, car c'est ainsi que le serveur s'authentifie auprès du client: "Je suis le serveur qui est autorisé à diffuser du contenu pour www.foo.example, selon Jim-Bob's Bait Shop and Certificate Authority. "Navigateurs modernes1 envoyez également le nom d'hôte en texte clair du client au serveur , dans le message " Server Name Indication " qui permet d'héberger de nombreux sites HTTPS sur une même adresse IPv4.
Cela est nécessaire en raison de la façon dont fonctionne la configuration d'un canal sécurisé. Fondamentalement, le serveur doit faire une affirmation cryptographiquement infalsifiable de son nom d'hôte (et d'autres éléments, surtout sa "clé publique"), en texte clair, avant que le processus de "l'accord de clé" ne commence, sinon le client ne peut pas être sûr que il n'y a pas homme au milie interceptant les communications.
Mais l'inconvénient est qu'un pare-feu "d'inspection approfondie des paquets" peut apprendre que vous essayez de vous connecter à un site Web spécifique et bloquer l'accès (par exemple en forgeant TCP paquets RST) même s'il ne pouvait pas '' Je n'ai pas écouté le contenu de vos communications avec ce site, et même si vous ne révélez jamais le nom d'hôte du site avec lequel vous souhaitez communiquer dans un autre façon.
1 dans ce cas, "tout ce que vous êtes susceptible de rencontrer de nos jours, à l'exception flagrante de IE sur Windows XP et du stock Android navigateur avant 3.0; malheureusement, ces deux éléments sont plus courants que nous ne le souhaiterions ".
HTTPS ne masque pas et ne peut pas masquer l'IP et le nom d'hôte d'un site Web ou le fait que vous vous y connectez. Il ne crypte que le trafic envoyé sur cette connexion ne fois qu'il est établi.
Compte tenu de cela, il est trivial pour quelqu'un qui contrôle la ligne de mettre fin aux connexions pour un site particulier. Ce que HTTPS (espérons-le) les empêche de faire, c'est de surveiller ou de modifier les informations échangées avec le site, mais le fait que vous vous y connectiez est toujours visible.
Institutions et entreprises [par exemple. fournisseurs de points d'accès] traitent généralement cela de deux manières:
- Demander aux serveurs DNS de pointer vers d'autres IP: c'est un obstacle faible, car les utilisateurs techniquement avertis peuvent facilement changer leur service DNS, et utilisé lorsqu'il n'est pas vraiment important de bloquer un site. Je pense que c'est ce que fait, par exemple, le gouvernement italien: les FAI nationaux sont invités à changer leurs serveurs DNS afin que les demandes de site interdit soient redirigées vers une page hébergée par le gouvernement.
- Blocage des connexions sur une base IP plutôt que sur une base de domaine: cela nécessite normalement un proxy transparent (en particulier utilisé par les fournisseurs de hotspot et autres) ou un pare-feu avec une inspection approfondie des paquets (par exemple, le pare-feu chinois). Pour empêcher l'utilisateur de se connecter à des adresses IP interdites, quelques techniques sont ensuite utilisées - parmi elles, l'injection de TCP réinitialisation des paquets, la redirection des paquets ou simplement leur suppression).
Il est possible que le site cible lui-même vous empêche d'y accéder à partir de la plage IP source en question.
Je connais de nombreuses grandes organisations qui bloquent les pays pour aucune autre raison que de minimiser l'exposition aux pirates informatiques provenant de cette région.