HTTP encore ouvert : l'attaquant y sert une autre version

Le cadenas de la home n’est pas le port 80

Vous ouvrez le site depuis un favori en https, ou Chrome complète tout seul. Vous voyez le thème propre. Un bot, un vieux lien d’annuaire, un QR code de 2018, un email, Googlebot sur une URL http encore en base : eux frappent le port 80. Si ce port n’envoie pas vers le même contenu propre (via une redirection), ils ont un autre site.

C’est l’une des faces oubliées, avec le nu vs www et l’IPv6. Après incident, on teste https et on déclare victoire. L’inspection Search Console sur http://montre encore le kit ou une home de 2019. Le réexamen échoue.

Le port 80 n’a pas à « rester un site ». Il a à rediriger (301 ou 308) vers l’origine HTTPS canonique, sauf le temps d’un challenge de certificat si vous en dépendez. Tout 200 HTML sur http:// après bascule est une dette, et après piratage une porte d’affichage.

Qui parle encore en HTTP

Google garde des URL http dans l’index pendant longtemps. Les outils d’inspection permettent de les coller telles quelles. Safe Browsing aussi. Un signalement « malware » sur http://domaine.fr/fichier.php survit à un nettoyage https://www.

Les humains : liens dans des PDF, signatures, encarts presse, campagnes Ads mal paramétrées (http en destination — les régies n’aiment pas, mais ça existe encore). Les clients Orange / SFR sur un vieux favori. Ce n’est pas théorique sur une PME française de 15 ans de web.

Les scripts et les crons internes : un wp-cron, un webhook, un prestataire de newsletter qui « ping » l’http. Moins visible, même logique : ils touchent le vhost 80.

Ce que le port 80 peut servir d’autre

Un vhost séparé « :80 » jamais mis à jour, document root différent. Un index.html à la racine HTTP alors que HTTPS passe par WordPress. Un redirect vers un domaine d’affiliation posé dans le .htaccess du vhost 80 seulement. Un générateur qui ne s’active que si la requête n’est pas HTTPS — cloaking pauvre, assez fréquent.

Chez l’hébergeur, « SSL » coche la face 443. La face 80 reste le défaut historique. Après une migration, l’ancien dossier est encore le default_server sur 80. Vous n’y allez jamais. Les bots, si.

Ce n’est pas un mode d’emploi d’attaque : c’est une liste de lieux à ouvrir (vhosts, redirects panel, règles CDN). Comparez le HTML http et https sur la même path. S’ils diffèrent, vous n’avez pas fini.

• Même path, deux schémas, deux HTML → deux sites.
• http 200 + https 301 vers ailleurs → suivez la Location jusqu’au bout.
• http qui reste sur l’IP d’origine alors que https passe au CDN → deux machines.

Redirection : où la poser (et où elle ment)

Le plus fiable : la case de l’hébergeur ou le vhost (Apache/nginx) « http → https », avant PHP. Un plugin WordPress « force SSL » arrive après le chargement : trop tard si le vhost 80 sert autre chose, et inutile si WordPress n’est pas ce vhost.

Cloudflare : règle « Always Use HTTPS » + host www/apex. Vérifiez que l’origine, quand Cloudflare est en Flexible, n’est pas un HTTP sale que vous ne voyez plus. En Full (strict), l’origine doit avoir un cert valide — autre sujet (cert vs trompeur).

Une redirection http → https vers le mauvais hôte (apex sale, www propre) déplace le problème. Une redirection vers un parking ou un spam est le symptôme, pas le correctif : trouvez qui l’a écrite (panel, .htaccess, plugin, CDN).

Tester http:// pour de vrai

Navigateur : désactivez un instant HTTPS-Only si besoin, tapez http://, regardez les outils réseau (premier statut). Téléphone 4G. Inspection Search Console sur l’URL http. Ne vous fiez pas à un raccourci qui ouvre déjà https.

Testez une URL profonde, pas seulement la home : /wp-login.php, une pièce jointe, le chemin du kit s’il est connu. Une home qui redirige et un /paypal/ en 200 HTTP, c’est le dossier phishing 200.

Gardez les captures (URL + code). Elles datent la face 80 pour le constat et pour l’hébergeur (« le vhost :80 servait encore X à telle heure »).

CDN, HSTS et « chez moi ça passe en HTTPS »

HSTS dit au navigateur qui a déjà vu le site : ne plus tenter HTTP. Utile après coup. Inutile pour Googlebot la première fois, inutile pour un client qui n’a jamais reçu l’en-tête, inutile si vous n’avez pas déjà un HTTPS sain. Ne posez pas HSTS preload le soir d’un incident : un mauvais hôte collé en HTTPS casse tout le nom pour des mois.

Votre Chrome a HSTS en mémoire : il ne vous montrera plus le HTTP même si le serveur le sert encore aux autres. D’où le test d’inspection et le téléphone « neuf » / navigation privée, parfois un autre navigateur.

Le guide redirections couvre le mobile. Ici, le piège est l’inverse : pas de redirection visible chez vous, redirection pourrie ou contenu sale pour les autres sur le port 80.

Phishing et spam encore en HTTP

Les kits sont souvent déposés pour être ouverts tels quels, http compris (liens d’email, QR). Tant que http://domaine.fr/chemin-kit répond 200, Safe Browsing a de la matière. 410 sur ce chemin en 80 et 443. Pas de 301 vers la home.

Un générateur « si pas HTTPS » est un détail d’implémentation : vous le voyez à la différence de HTML, vous le retirez comme une backdoor, vous ne le « corrigez » pas en ajoutant un plugin SSL.

Réexamen seulement quand l’inspection http et https sont alignées et propres. Voir premiers gestes.

Fermer sans casser Let’s Encrypt

Le challenge HTTP-01 a besoin d’un chemin précis en HTTP (/.well-known/acme-challenge/). Une redirection globale vers HTTPS le permet en général (Let’s Encrypt suit). Une fermeture brutale du port 80 (firewall) casse le renouvellement si vous n’avez pas de DNS-01. Demandez à l’hébergeur comment leur AutoSSL travaille avant de « fermer 80 pour de bon ».

L’objectif n’est pas « port 80 fermé au monde ». C’est « port 80 ne sert plus de site ». Redirect + exception ACME, ou DNS-01, selon l’hébergeur.

Si le compte est suspendu, le HTTP peut déjà être mort : lisez le motif. Relancer AutoSSL n’est pas un nettoyage (certificat vs trompeur).

Après : une seule origine, port 80 = pont

Documentez : http www et http apex → https canonique, même racine. Retestez après chaque ajout CDN. Trente jours : une URL http encore en `site:` doit au moins rediriger proprement ; les chemins de kit restent 410.

Les campagnes Ads / Meta : mettez à jour les destinations en https. Une régie qui recrawl du http sale suspend. Voir Ads et LSA.

Si le vhost 80 n’est pas le vôtre (voisin, défaut serveur), déclarez. C’est un sujet d’hébergement, pas de thème WordPress.