HTTPS, qui utilise SSL, fournit de la sécurité et la vérification d’identité pour que vous sachiez que vous êtes connectés au bon site web et que personne ne vous espionne. C’est la théorie, de toute façon. En pratique, SSL n’est pas aussi efficace.
Ceci ne veut pas dire que HTTPS et le cryptage SSL ne servent à rien car ils sont beaucoup mieux qu’utiliser une connexion http non-encryptée. Dans le pire des cas, une connexion HTTPS compromise sera aussi non-sécurisé qu’une connexion http.
Le grand nombre des autorités de certificat
Votre navigateur a une liste de noms d’autorités dont le certificat est de confiance. Les navigateurs font confiance seulement aux certificats provenant de ces autorités. Si vous visitez https://exemple.com, le web serveur vous donnera un certificat SSL et votre navigateur se mettra sure que le certificat d’exemple.com provient d’une autorité de confiance. Si le certificat a été donné à un autre nom de domaine ou le certificat provient d’une autorité inconnue, vous verrez un avertissement dans votre navigateur.
Un problème majeur est qu’il y a beaucoup d’autorités de certification. Ce qui veut dire qu’un problème avec une autorité peut affecter les autres. Par exemple, vous pouvez obtenir un certificat pour votre domaine de VeriSign, mais quelqu’un peut compromettre ou duper une autorité de certification et obtenir un certificat pour votre nom de domaine.
Les certificats d’autorité n’ont pas toujours inspiré confiance
Des recherches ont trouvé que des autorités de certification n’ont pas été assez diligentes à l’issue de leurs certificats. Ils donnent des certificats SSL pour des adresses qui n’ont pas besoin d’un telles que “localhost,” qui représente l’ordinateur local. En 2011, l’EFF a trouvé plus de 2000 certificats “localhost” donné par des compagnies légitimes de certification SSL.
Si des autorités de confiance ont déjà approuvé un grand nombre de certificats sans jeter un coup d’œil à l’adresse, c’est normal qu’on se demande quelles fautes ils ont commises. Peut-être qu’ils ont donné des certificats aux sites web d’attaqueurs.
Les autorités peuvent être obligées à approuver des certificats illégitimes.
Parce qu’il y a tellement d’autorités de certification, ils sont partout dans le monde et n’importe quel autorité peut donner un certificat à n’importe quel site web, les gouvernements peuvent forcer des autorités de certification à leur donner un certificat pour un site web qu’ils veulent usurper.
Ceci est arrivé dernièrement en France, où Google a découvert qu’un certificat malveillant pour google.com a été donné de la part de l’autorité de certification française, ANSSI. Cette autorité a permis au gouvernement Français ou n’importe qui possède le certificat d’usurper Google avec leur site web, ce qui les laisse accomplir des attaques de troisième partie facilement. ANSSI dit que ce certificat a été utilisé dans un réseau privé pour surveiller l’activité de ses utilisateurs, et non pas par le gouvernement Français. Même si c’est vrai, cela sera une violation des termes d’ANSSI à l’issue des certificats.
“Perfect Forward Secrecy ” n’est pas utilisé partout.
Beaucoup de sites n’utilisent pas “perfect forward secrecy,” une technique qui rend le cryptage plus difficile à craquer. Sans perfect forward secrecy, Un attaqueur peut prendre un large nombre de données encryptés et de les décrypter avec une clé secrète. On sait que la NSA et d’autres compagnies de surveillance à travers le monde le font. S’ils découvrent la clé de cryptage utilisé par le site web quelques années plus tard, ils seront capables de décrypter toutes les données qu’ils ont récolté entre le site web et tous ceux qui se sont connectés à ce site.
Perfect forward secrecy aide contre cette menace par générer une clé unique à chaque session. En d’autres mots, chaque session est encrypté avec une clé différente, alors ils ne seront pas décryptés par une seule clé. Ceci prévient un attaqueur de décrypter une grande quantité de données en un seul coup. Parce que peu de sites web utilisent cette fonctionnalité, c’est possible que les agences de sécurité à travers le monde puissent décrypter ces informations dans les années à venir.
Les attaques de troisième partie et les caractères Unicode
Malheureusement, les attaques de troisième partie sont toujours possibles avec SSL. En théorie, c’est sûr de se connecter à votre site de banque dans un réseau Wi-Fi public. Vous savez que la connexion est sécurisée car elle est HTTPS, et la connexion HTTPS vous fait savoir que vous êtes vraiment connecté au site de la banque.
En pratique, il peut être dangereux de se connecter au site de votre banque via un réseau public. Ils y a des solutions prêtes à utiliser qui permettent à un hotspot malicieux de faire des attaques de troisième partie. Par exemple, un hotspot peut se connecter à votre place au site de votre banque tout en envoyant et recevant des données au milieu. Il peut vous rediriger à une page HTML simple et vous utiliser pour vous connecter en HTTPS à votre banque.
Il peut aussi utiliser des “adresses HTTPS homographes.” Ceci est une adresse qui apparait similaire à votre banque mais utilise des caractères Unicode spéciaux. Cette attaque est la plus effrayante et est connue sous le nom d’attaque par homographe. Examinez l’ensemble des caractères Unicode et vous trouverez des caractères qui ressemblent aux 26 lettres de l’Alphabet utilisé en Latin. Peut-être que les “o” du Google auquel vous vous êtes connecté ne sont pas actuellement des “o”.
Bien sûr, HTTPS marche la plupart du temps. C’est improbable que vous rencontrez ce type d’attaque quand vous vous connectés au réseau public de votre Café. Le point est que, HTTPS souffre de problèmes. La plupart des gens lui font confiance et ne sont pas conscients de ces problèmes.