La sécurisation des sites Web avec HTTPS les rendait moins accessibles

Au milieu du mois de juillet – juillet 2018, je me suis retrouvé à regarder un écran de projecteur, attendant encore une fois de voir si Wikipedia se chargerait. Si j'ai eu de la chance, la page a commencé à afficher 15 à 20 secondes après avoir envoyé la demande.

Sinon, il pourrait être plus proche de 60 secondes, en supposant que le navigateur ne soit pas simplement expiré sur la connexion. J'ai vu beaucoup de "le serveur a cessé de répondre" au cours de quelques jours.

CNN International a connu des temps de chargement similaires. La page de recherche principale de Google a fait de même. Même ce site ici, avec des ressources minimales à charger, a pris au moins 10 secondes pour démarrer le rendu. Habituellement plus long.

En 2018? Oui. Dans les zones rurales de l’Ouganda, où je improvisais une introduction au développement Web pour une classe d’étudiants de la formation professionnelle, c’est la réalité.

Ils peuvent installer un laboratoire d’ordinateurs Dell ou Windows de Raspberry Pis exécutant Ubuntu ou quelle que soit la configuration, mais lorsque les satellites en orbite géosynchrone sont votre seule source d’internet, vous attendez. Et attendre. Et attendez.

Je voudrais expliquer pourquoi – et surtout, comment nous avons rendu cette expérience encore pire et plus coûteuse au nom de notre confort et de notre sécurité.

Premièrement, considérez la nature extrêmement limitée de accès internet par satellite. Si vous connaissez déjà ce monde, passez quelques paragraphes en avant; mais si non, permettez-moi une brève description des défis.

Pour un accès Internet par géosynchronisme par satellite, la vitesse de la lumière devient un facteur de ping: le simple fait que les signaux se propagent

Si toute cette distance était du vide, votre plancher absolu pour la latence de ping est d'environ 506 millisecondes.

C'est juste le temps pour que les signaux fassent deux tours. voyages en orbite géosynchrone et retour. En réalité, il y a des moments pour acheminer les paquets à chaque extrémité et le temps de retransmission sur le satellite lui-même. Après tout, ces paquets vont en orbite et en arrière. Beaucoup de choses le long de ces chemins de signaux longs et solitaires peuvent entraîner la perte des paquets. 50% de perte de paquets n'est pas rare; 80% n'est pas inattendu.

Donc, vous perdez la moitié de vos paquets (ou plus), et les paquets qui ne sont pas perdus ont des temps de latence d'environ deux tiers de seconde (ou plus). Chacun .

C'est une raison suffisante pour configurer un serveur de mise en cache local. Une autre raison encore plus pressante est que pratiquement toutes les connexions satellites commerciales sont associées à des plafonds de données.

Où j'étais, leur plafond était de 50 Go par mois. Au-delà de cela, ils pourraient soit payer des excédents, soit simplement ne pas avoir de données jusqu'au mois suivant.

Donc, si vous pouvez mettre en cache localement les URL afin qu'elles ne comptent que dans votre utilisation de données la première fois qu'elles sont chargées.

Et quelqu'un, pour l'école où j'enseignais.

Mais là, j'espérais que mes demandes de chargement de pages web simples porteraient leurs fruits et je pourrais continuer à enseigner les principes du web à un groupe d'étudiants en formation professionnelle. .

Parce que Wikipedia ne met pas en cache. Google ne mettrait pas en cache Meyerweb ne mettrait pas en cache Presque rien ne mettrait en cache.

Pourquoi?

HTTPS .

Un serveur de cache local, destiné à accélérer les sites fréquemment demandés et réduire l'utilisation de la bande passante, est un "homme au milieu". HTTPS, qui par conception empêche les attaques de type man-in-the-middle, rompt complètement les serveurs de cache locaux.

J'ai donc attendu et attendu des ressources distantes, rentrant à chaque requête dans le plafond de données du mois. forcer chaque site sur le Web à HTTPS a poussé le Web plus loin du prochain milliard d'utilisateurs – sans parler de beaucoup des demi-milliards précédents. J'ai vu un article qui disait: "Investir dans HTTPS le rend plus rapide, moins cher et plus facile pour tout le monde." Peut-être que c'est même vrai pour la plupart de ceux dont le dernier kilomètre est le cuivre. Mais pour les personnes hors de portée du verre et du fil de fer, chaque mot de cette affirmation était erroné.

Si cela vous surprend, vous n'êtes nullement seul. Je n'avais rien entendu à ce sujet, alors j'ai demandé à plusieurs collègues s'ils étaient au courant du problème. Non seulement ils n'avaient pas réagi de la même manière que moi: cela ne devait pas être un problème réel, ou nous en aurions entendu parler! Mais non

Peut-on faire quelque chose? Pour les utilisateurs de navigateurs à jour, oui: les travailleurs du service créent un "bon" homme au milieu qui évite le problème HTTPS, pour autant que je sache.

Donc, si vous diffusez du contenu via HTTPS, la création d’un agent de service devrait être l’une de vos priorités dès maintenant, même s’il ne s’agit que de mettre en place une mise en cache locale simple et rien de plus sophistiqué. Je ne l'ai pas encore fait pour meyerweb, mais je le ferai très bientôt.

C'est parfait pour les navigateurs modernes, mais tout le monde n'a pas la possibilité d'être moderne. Parfois, ils sont contraints par d'anciens systèmes d'exploitation d'exécuter des navigateurs plus anciens, sans prise en charge des agents de maintenance: un laboratoire rempli de machines Windows XP limitées à IE8, par exemple.

systèmes d'exploitation de cette époque. Ceux qui sont le plus susceptibles d'être ceux qui se trouvent dans des situations où ils sont limités à Internet par satellite ou à d'autres services aussi lents avec des limites de données impitoyables.

Même dans le monde très câblé, systèmes et navigateurs: bibliothèques publiques, pour ne citer qu’un exemple. La sécurisation du Web l'a littéralement rendu moins accessible à de nombreuses personnes à travers le monde.

Au-delà du déploiement de travailleurs des services et de l'espoir que ceux qui luttent pour réduire la fracture numérique traversent, je n'ai pas de solution.

Je pense que le HTTPS est probablement globalement positif, et je ne sais pas ce que nous aurions pu faire de mieux. Tout ce que je sais, c'est que j'ai vu de mes yeux l'externalité négative qui a été transmise aux personnes éloignées de nos centres de données et de nos pensées.

Mes remerciements à Tim Kadlec et Ethan Marcotte pour leurs commentaires et idées pendant que je rédigeais ce message, et pour Lara Hogan et [19659046] Aaron Gustafson pour leur aide précieuse dans mes recherches.

Cet article a été publié par Eric A. Meyer conférencier, blogueur, parfois enseignant et consultant et chef technique à Rebecca's Gift . Vous pouvez lire l'article original sur meyerweb et suivre meyerweb sur Twitter .