Tout dépend de vos exigences en matière de sécurité, du choix de l'utilisateur et du risque de déclassement implicite. La désactivation des anciens algorithmes de chiffrement côté serveur est en grande partie nécessaire parce que les navigateurs passeront volontiers à des algorithmes de chiffrement absolument horribles côté client au nom de l'expérience et de la commodité de l'utilisateur. S'assurer que rien de ce qui dépend sur un canal sécurisé à l'utilisateur ne peut être atteint par une méthode non sécurisée est, bien entendu, également très judicieuse.
Ne pas me permettre de passer explicitement à un protocole HTTP non sécurisé lorsque j'estime que votre billet de blog expliquant pourquoi vous préférez Python à Ruby (je ne dis pas que c'est le cas, il s'agit juste d'un exemple générique) n'est pas quelque chose que je souhaite que les espions ou le public sachent que j'y ai accédé, c'est me mettre des bâtons dans les roues sans raison valable, en partant du principe que le protocole HTTPS sera trivial pour moi.
Il existe aujourd'hui des systèmes embarqués qui n'ont pas la capacité d'utiliser TLS dès le départ, ou qui sont bloqués sur d'anciennes implémentations (je pense qu'il est terriblement dommage qu'il en soit ainsi, mais en tant qu'utilisateur puissant de [insérer un dispositif embarqué ici], je ne peux parfois pas changer cela).
Voici une expérience amusante : essayez de télécharger une version récente de LibreSSL depuis le site OpenBSD en amont via HTTPS avec une implémentation TLS/SSL suffisamment ancienne. Vous n'y arriverez pas. J'ai essayé l'autre jour sur un appareil avec une ancienne version d'OpenSSL datant d'environ 2012, parce que je voulais mettre à jour ce système embarqué avec un nouveau système plus sûr à partir des sources - je n'ai pas le luxe d'avoir un paquetage préconstruit. Les messages d'erreur lorsque j'ai essayé n'étaient pas vraiment intuitifs, mais je suppose que c'était parce que mon ancien OpenSSL ne prenait pas en charge les bons éléments.
C'est un exemple où le passage au only-HTTPS peut en fait nuire aux gens : si vous n'avez pas le luxe d'avoir des paquets préconstruits récents et que vous voulez résoudre le problème vous-même en construisant à partir des sources, vous êtes bloqué. Heureusement, dans le cas de LibreSSL, vous pouvez vous rabattre sur la demande explicite de HTTP. Bien sûr, cela ne vous sauvera pas d'un attaquant qui réécrit déjà votre trafic, capable de remplacer les paquets sources par des versions compromises et de réécrire toutes les sommes de contrôle dans les corps HTTP décrivant les paquets disponibles au téléchargement sur les pages web que vous parcourez, mais c'est toujours utile dans le cas le plus courant.
La plupart d'entre nous ne sont pas à un téléchargement non sécurisé près d'être la propriété d'un APT (Advanced Persistent Thread : jargon de sécurité pour les agences de renseignement nationales et d'autres cybermenaces extrêmement bien dotées en ressources). Parfois, j'ai juste envie de wget une documentation en texte clair ou un petit programme dont je peux rapidement vérifier les sources (mes propres petits utilitaires/scripts sur GitHub, par exemple) sur une machine qui ne prend pas en charge les suites de chiffrement les plus récentes.
Personnellement, je poserais la question suivante : votre contenu est-il tel qu'une personne pourrait légitimement décider "Je suis d'accord pour que mon accès soit connu du public" ? Existe-t-il un risque plausible de voir des personnes non techniques passer accidentellement au protocole HTTP pour accéder à votre contenu ? Pesez vos exigences en matière de sécurité, de respect de la vie privée de vos utilisateurs et de risque de déclassement implicite par rapport à la capacité des utilisateurs qui comprennent les risques à choisir en connaissance de cause, au cas par cas, de ne pas être sécurisés. Il est tout à fait légitime de dire que pour votre site, il n'y a pas de bonne raison de ne pas appliquer le HTTPS - mais je pense qu'il est juste de dire qu'il existe encore de bons cas d'utilisation du HTTP simple.
