Comment faire de HTTPS la première requête via un VPN

Un navigateur qui tape http:// en premier et atterrit sur https:// après une redirection a déjà envoyé une requête en clair, et un VPN n'y change rien. Le tunnel protège le tronçon allant du client au nœud de sortie ; il ne chiffre rien au-dessus de la couche de transport, donc un observateur entre la sortie et l'origine voit toujours le saut en texte brut. Faire de HTTPS la première requête est un changement côté client en trois parties : une véritable adresse HTTPS, le mode de mise à niveau du navigateur et la propre politique du site. Les étapes ci-dessous sont l'ordre que j'utilise, chacune avec le chèque qui vous indique si cela a pris.

Étape 1 : confirmer la nature réelle de la première requête

Avant de modifier quoi que ce soit, regardez ce que le navigateur envoie. Ouvrez le panneau réseau avec la page rechargée depuis un cache froid et lisez la première ligne : si le schéma est http et que le statut est 301 ou 308, tout ce qui suit cette ligne est une deuxième requête. curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com reproduit la même séquence en dehors du navigateur et imprime l'URL sur laquelle vous vous êtes retrouvé.

Deux résultats sont possibles et nécessitent des correctifs différents. Si le site sert HTTPS sur le même hôte, la solution consiste à arrêter de publier le formulaire HTTP : mettez à jour le signet, le lien wiki, le raccourci sur le bureau et le modèle d'e-mail sur lequel les gens cliquent. Si le site ne sert pas du tout HTTPS, aucun paramètre du navigateur ne le créera, et la réponse honnête est que la destination est le problème. Ne couvrez pas le deuxième cas avec une exception, car une exception de certificat sur une page de compte convertit un problème de transport en un problème d'informations d'identification. Notez dans quel cas vous vous trouvez avant de toucher un paramètre.

Étape 2 : activez le mode HTTPS uniquement du navigateur

Le mode de mise à niveau est la deuxième partie et les modes ne sont pas interchangeables. Vérifiez ce que fait le vôtre avant de l'activer : effectuez une mise à niveau silencieuse, effectuez une mise à niveau avec un avertissement ou refusez de charger.

Dans Firefox, les contrôles se trouvent derrière about:config et dans la page des paramètres de confidentialité, avec dom.security.https_only_mode comme commutateur et exceptions par site gérées à partir du menu du cadenas. Dans Chrome et Edge, la même idée se trouve sous Paramètres, Confidentialité et sécurité, Sécurité, intitulée Toujours utiliser des connexions sécurisées. Quelle que soit l'étiquette, vérifiez le comportement par rapport à un hôte qui répond uniquement sur le port 80, car un mode qui se met à niveau puis revient silencieusement n'est pas la protection que vous pensez avoir activée. La documentation Firefox HTTPS uniquement décrit le comportement de mise à niveau, d'avertissement et d'exception pour ce navigateur.

Étape 3 : réparer les ressources, pas seulement la barre d'adresse

Lorsqu'une mise à niveau échoue, lisez l'erreur exacte au lieu de la barre d'adresse. Un hôte sans écouteur HTTPS, un nom d'hôte qui ne correspond pas au certificat et une chaîne expirée produisent des messages différents et appartiennent à des propriétaires différents. Seule la première est une lacune côté serveur ; le second est généralement un signet qui n’a jamais été mis à jour ; le troisième est un problème de renouvellement pour lequel la connexion VPN n'a aucun rapport.

N'ajoutez pas d'exception de certificat à un site de compte car le VPN est activé. L'exception désactive la vérification qui aurait détecté exactement l'interception qu'un VPN est censé empêcher.

La troisième partie se trouve à l'intérieur de la page, et c'est celle qui manque aux gens. Une page chargée via HTTPS peut toujours extraire des images, des polices ou des scripts d'une URL http, et le navigateur les bloquera ou dégradera l'indicateur de sécurité pour l'ensemble de la page. Inspectez les requêtes ayant échoué dans le panneau réseau et corrigez les références de ressources chez leur propriétaire plutôt que de supposer que la barre d'adresse décrit chaque requête. Sur un site que vous exécutez, cela signifie corriger les URL stockées dans le CMS ou le modèle au lieu de les réécrire dans le navigateur. Si vous ne pouvez pas modifier la source, enregistrez le contenu mixte comme une lacune connue, car un cadenas sur une page qui extrait des ressources en texte brut est un faux signal.

Étape 4 : ce que HSTS ajoute et ce qu'il n'ajoute pas

HSTS est une politique du site plutôt qu'une préférence du navigateur, et c'est le seul mécanisme ici qui survit à un http:// tapé sur un nouveau profil. Une fois qu'un navigateur a vu un en-tête Strict-Transport-Security pour un hôte, il réécrit les requêtes ultérieures en https avant de les envoyer, ce qui correspond exactement à la propriété souhaitée. Il ne fait rien pour un hôte que le navigateur n'a jamais visité, ni pour un nom d'hôte différent qui dessert la même application.

Vérifiez ce que l'origine envoie avec curl -sSI https://example.com | grep -i strict-transport-security. Un en-tête manquant est un changement de serveur et non quelque chose qu'un client peut installer. S'il est présent, lisez max-age et si includeSubDomains est défini, car un court âge maximum expire entre les visites et un includeSubDomains manquant laisse chaque sous-domaine non protégé. La RFC 6797 définit comment un agent utilisateur applique la politique et ce qu'il peut ignorer. Le préchargement est un engagement distinct, alors vérifiez l'état via l'API hstspreload.org avant de promettre à quiconque qu'un domaine figure sur la liste.

Vérification et restauration

La restauration est peu coûteuse pour les paramètres client et coûteuse pour HSTS. La désactivation du mode HTTPS uniquement rétablit immédiatement le comportement précédent ; un âge maximum long ne le fait pas, et les visiteurs qui l'ont déjà reçu continuent de se mettre à niveau jusqu'à son expiration.

Vérifiez donc l'ordre avant de dire que c'est terminé. Rechargez à partir d'un cache froid et confirmez que la première requête dans le panneau réseau est https sans redirection précédente. Vérifiez ensuite un sous-domaine, car c'est dans includeSubDomains que ces politiques s'avèrent généralement plus étroites que prévu. Vérifiez ensuite une page qui extrait des ressources tierces, car le contenu mixte est l'échec qui survit à toutes les autres corrections.

Si la première requête est toujours http après tout cela, le client n'est plus la variable : le lien sur lequel les gens cliquent l'est. Recherchez les emplacements que vous contrôlez pour la forme http du nom d'hôte, mettez-les à jour et testez à nouveau avec le même rechargement du cache froid. Gardez la question VPN séparée tout au long, car le tunnel change qui peut voir la demande et ne change jamais si la demande est cryptée. La ligne à mettre dans le ticket est que la première requête est celle qui compte, et une redirection n'est qu'un récépissé d'une requête déjà envoyée.