De nos jours, la plupart des sites utilisent HTTPS et définissent des en-têtes HSTS, de sorte que les chances que quelqu'un puisse écouter la connexion de quelqu'un d'autre sont très faibles
Cette hypothèse est effrayante. Le nombre de sites qui définissent les en-têtes HSTS n'a pas d'importance si l'on ne peut pas compter sur HTTPS lui-même pour fournir une sécurité de point final à point final. Et ça ne peut pas. Malheureusement.
Avez-vous entendu parler d'un proxy d'interception TLS? Ils sont monnaie courante. Déployés dans les écoles, les universités et les bibliothèques et utilisés par les employeurs et les cafés, ces proxys matériels (tels que WebTitan Gateway ou Cisco ironPort WSA) rendent le HTTPS nul et non avenu, car lors de la connexion «sécurisée», ils introduisent un certificat dynamique prétendant être le certificat officiel du site Web de destination. Mon navigateur ne connaît pas la différence, et si je ne savais pas mieux, je ferais confiance à chaque connexion HTTPS sur son visage.
Au départ, HTTPS a été conçu pour empêcher les attaques MiTM. Aujourd'hui, le proxy TLS EST l'attaque MiTM! Que vous lisiez vos e-mails ou que vous vérifiiez le solde de votre compte bancaire, vous ne devriez pas vous faire d'illusions sur le fait que HTTPS fait réellement quoi vous vous attendez à ce qu'il fasse, c'est-à-dire sécuriser votre connexion contre les écoutes clandestines. Et à moins que vous ne vous connectiez via votre routeur WIFI domestique &, ou à moins que vous n'utilisiez un VPN décent, habituez-vous au fait que votre connexion est probablement décryptée et rechiffrée à la volée, à votre insu ou sans votre consentement.
Il n'y a guère besoin de considérer les "autres menaces" suggérées par l'OP jusqu'à ce que des connexions cryptées de bonne foi soient la norme. Actuellement, ils ne le sont pas, et HTTPS est une farce. (Pour éviter les écoutes clandestines, utilisez un VPN fiable géré par une entreprise qui ne stockera ni ne publiera aucun enregistrement. Utilisez TOR pour améliorer encore la connexion.)
Pourquoi est-ce que j'affirme que HTTPS / HSTS n'est pas vraiment la couverture de sécurité d'un navigateur Web? Parce que 3 ans avant que OP ne pose la question, elle était déjà exploitée et vaincue. Et juste 2 ans auparavant, il a été subverti. En outre, certaines implémentations populaires de SSL se sont avérées défectueuses dès 1998. Même les autorités de certification (CA) ne sont pas dignes de confiance. Une brève chronologie:
- 1998 - Daniel Bleichenbacher décrit une attaque réussie sur PKCS # 1 v1.5, le (alors) RSA Encryption Standard (à CRYPTO 98); une attaque supposée nécessiter un million de messages d'attaque pour être exploitée
- 2009 - Moxie Marlinspike crée SSLStrip pour attaquer HTTPS ( démo à Black Hat DC 2009)
- 2012 - L'IETF nous donne la RFC 6797, qui implémente le HSTS, conçu pour contrecarrer le stripping SSL
- 2012 - Graham Steel publie un article (au CRYPTO 2012) démontrant que l'attaque d'oracle de remplissage de Bleichenbacher nécessite moins de 15 000 messages - pas un million comme on le supposait à l'origine
- 2014 - Leonardo Nve crée SSLStrip + pour éviter le HSTS ( démo à Black Hat Asia 2014)
- 2015 - Sam Greenhalgh présente les Super Cookies HSTS, montrant comment le mécanisme de sécurité HSTS est facilement contourné être une atteinte à la vie privée
- 2015 - Google se rend compte que Symantec et ses filiales ont frauduleusement émis plus de 30 000 certificats de sécurité sans audits ni divulgations appropriés
- 2016 - Google institue une liste noire publiée de certificats non fiables les autorités, surnommé Submariner
- 2017 - Ars Technica a rapporté que des sites majeurs tels que Facebook et PayPal ont été testés positifs pour la critique de Bleichenbacher, âgée de 19 ans vulnérabilité permettant aux attaquants de déchiffrer les données chiffrées et de signer des communications en utilisant la propre clé de chiffrement secrète des sites
- 2018 - Google met à jour Chrome vers la version 70, afin de déprécier la confiance dans l'autorité de certification Symantec (y compris les marques appartenant à Symantec comme Thawte, VeriSign, Equifax, GeoTrust & RapidSSL); et Mozilla emboîte le pas
- 2018 - Adi Shamir publie un article détaillant que les implémentations modernes de PKCS # 1 v1.5 sont tout aussi peu sûres contre le padding oracle attaques; affectant les protocoles Les services & comme AWS, WolfSSL et la dernière version de TLS 1.3 publiée en août 2018
Actuellement, pour lutter contre des problèmes tels que la "confiance transitive", les sous-CA et les manigances des CA qui les émettent, par exemple GeoTrust, etc., nous avons le protocole DANE, conçu pour "sécuriser" le certificat de sécurité - l'ironie est à ne pas manquer ici - via DNSSEC en permettant aux administrateurs de domaine de créer un TLSA Enregistrement DNS.
Si DANE était largement mis en œuvre, je serais peut-être plus enclin à être d'accord avec l'évaluation de la faible menace du PO, mais l'utilisation de DANE signifie qu'un site doit signer DNSSEC sa zone, et à partir du 2016, seulement environ 0,5% des zones en .com sont signées.
Comme alternative au DANE mal adopté, il existe des enregistrements CAA, conçus pour faire la même chose, mais ce dernier mécanisme n'est pas plus ancré que le premier.
C'est la fin de 2017, et les chances sont extrêmement bonnes quelqu'un peut espionner votre Connexion protégée HTTPS / HSTS.
MISE À JOUR DÉC 2018: Qu'il s'agisse de protocoles non sécurisés, de protocoles sécurisés mal mis en œuvre hors de la portée de l'utilisateur, d'une technologie sécurisée en attente d'adoption par le grand public, d'autorités frauduleuses délivrant des certificats non vérifiés, ou goo d ancienne écoute assistée par le matériel, nous sommes à la fin de 2018 et je maintiens toujours les chances sont extrêmement bonnes que votre connexion HTTPS ne vous protège pas.