HSTS ne vous empêche pas d'utiliser un proxy SOCKS
Distinguez un échec de connexion SOCKS de l'application de HSTS et de la validation du certificat HTTPS.
HSTS n'exige pas de connexion directe. HTTPS peut passer par SOCKS avec son TLS et sa vérification de certificat habituels ; HSTS indique au navigateur d'utiliser HTTPS pour l'hôte et de traiter strictement les échecs de certificat.
Si le navigateur signale un échec de connexion SOCKS, vérifiez d'abord la version de SOCKS sélectionnée, la capacité du proxy à atteindre le port HTTPS de destination et l'endroit où le DNS de destination est résolu. Une négociation échouée ou une connexion de destination refusée se produit avant que le certificat du site puisse être évalué.
Une erreur de certificat après l'ouverture de la connexion relève d'une autre étape. HSTS peut empêcher de contourner cette erreur, mais n'a pas provoqué l'échec de la négociation SOCKS antérieure. Comparez le nom d'hôte du site et la chaîne de confiance plutôt que de désactiver la politique HTTPS pour compenser un problème de transport.
SOCKS ne transforme pas à lui seul le chemin en interception TLS. Un proxy non fiable peut supprimer ou mal acheminer le trafic, tandis qu'un TLS de bout en bout valide vise à détecter une usurpation. Installer un nouveau certificat racine modifie ce dispositif de confiance et n'est pas un correctif courant pour HSTS. Lorsqu'un site fonctionne et qu'un autre échoue, comparez leurs étapes de connexion réelles et les exigences de destination. Pour une comparaison autorisée via un point de terminaison public, la liste de proxys SOCKS fournit des candidats ; faites correspondre la version et la prise en charge de l'authentification au navigateur.