Les sites HTTPs : pourquoi sont-ils sécurisés ?

Les sites HTTPs deviennent de plus en plus courants.
Quel est l’intérêt des sites HTTPs ? Pourquoi les sites HTTPs ?
Cette entée vous explique le fonctionnement des sites sécurisés HTTPs, pourquoi parfois, vous pouvez obtenir des erreurs de connexions HTTPs.

https_logo

Les sites HTTPs : pourquoi sont-ils sécurisés ?

Introduction

Avant de commencer, je rappelle qu’il existe sur le forum un long dossier sur les sites HTTPs : Comprendre le HTTPs et à quoi sert le HTTPs
Les sites HTTPs faisant appels à différents mécanismes (algorithme de cryptage, certifications etc), j’ai essayé de simplifier au maximum afin que ce soit le plus compréhensible possible.
Donc voici les grandes lignes.

Pourquoi les sites HTTPs ?

Lorsque vous surfez des échanges sont effectuées entre le serveur WEB et votre ordinateur.
Ces échanges se font à travers divers équipements réseaux :

  • votre routeur ou box
  • les routeurs du fournisseurs d’accès
  • des routeurs intermédiaire
  • les routeurs et autres équipements réseaux de l’hébergeur où se situe le site WEB

La commande trace permet de visualiser ces derniers (Les commandes réseau utiles de Windows).

L’autre élément qu’il faut comprendre est que les données ne sont pas chiffrées, c’est à dire, qu’elles sont échangées en clair entre votre ordinateur et le serveur WEB.
Ainsi, une attaquant peut éventuellement se mettre entre votre ordinateur et le serveur WEB ou usurper ce dernier pour récupérer les données qui transitent (voir les attaques de type Man in the Middle).
Ceci pose des problèmes puisque vous pouvez échanger des données sensibles avec le site en question : mot de passe, voir informations bancaires.

C’est là que les sites HTTPs ont leur utilité, car

  • ils permettent un échange de données chiffrées entre votre navigateur WEB et le serveur WEB.
  • La seconde utilité est que les sites HTTPs permettent de vérifier l’identité du site et éviter l’usurpation d’identité. Cette vérification de l’identité se fait à travers un certificat électronique délivré par une autorité de certification (on en parle plus bas).

Les sites HTTPs et les attaques

En résumé donc :
  • Les sites HTTP sont non sécurisés et les données passent en clair.
  • Les sites HTTPs sont dit sécurisés et les données sont chiffrées. De plus, l’identité du site est validé pour éviter des usurpation.

Ces derniers sont identifiés par un cadenas qui peut prendre différentes couleurs.
Vérifiez donc bien, dans la barre d’adresse si vous êtes en HTTPs, surtout lors de la phase de paiements.

site_https

Bien entendu, on parle de sécurité, si tous les équipements sont sécurisés. Si l’ordinateur source est infecté par des virus informatiques, il y a toujours possibilité de récupérer les données qui transitent.
Le S signifie Secure.
Beaucoup de protocoles ont leurs versions « S », FTP avec FTPs, POP3 avec POP3s etc dont les données transitent en versions chiffrées.

Les sites HTTPs protègent ou rendent les attaques MITM plus complexes, pour mieux comprendre ces attaques, lire : Attaque Man in the Middle (MITM)
Ainsi par exemple, si votre fichier HOSTS a été Hijacké pour provoquer des redirections, une erreur « La connexion n’est pas sécurisée » peut s’afficher. 

La certification SSL

Il existe un article sur le site autour des certificats électroniques : Les certificats et signatures électroniques : A quoi cela sert et comment cela fonctionne

La certification est en réalité un peu plus complexe car il peut exister tout une chaîne de certification.
Par exemple avec le certificat de malekal.com :

  • USERTrust est l’autorité de certification racine (Autorité de certification racine)
  • Gandi est l’autorité de certificat intermédiaire (Autorité de certificat intermédiaire)
  • puis le certificat malekal.com (Certificat du site)

site_https_certificat_malekal

Il peut aussi arriver que le certificat du site d’une société soit généré par une autorité de certificat intermédiaire qui est la même entité.
Si vous allez sur le site de Gandi en HTTPs…. vous verrez que le certificat est généré par Gandi.

Il se passe exactement la même chose avec Google :

  • GeoTrusted Global CA (Autorité de certification racine)
  • Google Internet Authorité G2 (Autorité de certificat intermédiaire)
  • Le certificat pour les adresses .google.com (Certificat du site)

site_https_certificat_google

site_https_certificat_google_2

La confiance se fait donc sous la forme une chaîne, où UserTrust doit vérifier continuellement que la certification intermédiaire de Google est bien valide.
Même chose avec UserTrust et Gandi.
L’infrastructure d’une AC est composée d’éléments opérationnels essentiels, tels que les équipements et les logiciels, les réglementations et les déclarations de pratiques de sécurité, les rapports d’audit, le matériel de sécurité et le personnel. Ensemble, ces éléments forment une PKI de confiance (infrastructure de clé publique de confiance).
Un schéma d’un PKI de GlobalSign :

ca-structure

Ces derniers fournissent aux sites internet :

  • Un certificat électronique afin de pouvoir vérifier l’identité du site visité et s’assurer qu’on se connecte sur le bon site.
  • Une clé publique et privée lié au certificat électronique afin de pouvoir chiffrer les communications.

Exemple de certification SSL

Dans le cas de Gandi et c’est vrai pour d’autres autorités de certification intermédiaires, cela permet de vendre des certificats à des clients (webmaster, société d’hébergement, etc).
Oui parce que tout ça, c’est aussi un business =)

Chaque navigateur WEB possède une liste des certificats racines pour valider la chaîne.
Cette liste est présente dans un magasin de certificats interne ou externe au navigateur WEB.

Par exemple, Firefox a son propre de magasin de certificats, celui-ci est accessible depuis le menu d’options => Avancé et Certificat => Afficher les certificats.

site_https_gestionnaire_certificats

Sur Windows, Google Chrome, Internet Explorer et Edge utilise le magasin de certificat de Windows (certmgr.msc).
On retrouve alors les certificats d’autorités racines :
site_https_gestionnaire_certificats_2

Windows stocke aussi les certificats d’autorités intermédiaires

site_https_gestionnaire_certificats_3

Sur Linux, la liste des certificats racines (CA) se trouvent :

site_https_gestionnaire_certificats_4

Lire les informations des certificats

Tous les navigateurs WEB permettent de lire le certificat d’un site WEB.

Sur Internet Explorer, cliquez simplement sur le cadenas à droite :

site_https_ie_voir_certificats Sur Google Chrome, cliquez sur le cadenas à gauche de l’adresse HTTPs.
Dans la nouvelle fenêtre, cliquez sur le bouton « View certificate« .site_https_chrome_voir_certificatsSur Firefox, cliquez sur le cadenas puis la flèche vers la droite.



site_https_firefox_voir_certificats

Puis « plus d’informations ».site_https_firefox_voir_certificats_2

Dans la nouvelle fenêtre, cliquez sur « Afficher le certificat » afin d’ouvrir la fenêtre avec les informations du certificat.
site_https_firefox_voir_certificats_3

Fonctionnent des sites HTTPs

Clés et certificats SSL

Le fonctionnement de HTTPs pour les sites publiques fonctionnement avec un chiffrement asymétrique et un chiffrement symétrique.
Pour le chiffrement asymétrique, le serveur WEB possède une clé publique et privée.
La clé publique est utilisée pour établir la communication sécurisée, seule la clé privée permet de lire les données durant cette phase.
Ainsi le serveur WEB peut « distribuer » sa clé publique, seul le serveur WEB pourra lire ces données avec sa clé privée en retour.

Un certificat électronique est aussi utiliser pour s’assurer de l’identité du site lors de la connexion HTTPs. Ce certificat est donc unique pour chaque domaine.
Les certificats sont délivrés par des autorités de certificat qui sont en charge de ces vérifications.
Ce mécanisme permet donc d’assurer l’identité du site WEB avec lequel vous communiquez afin d’éviter les usurpations.

SujetNom distinctif, Clé publique
FournisseurNom distinctif, Signature
Période de validitéPas avant, Pas après
Informations de gestionVersion, Numéro de série
ExtensionsContraintes de base, Drapeaux Netscape, etc.

Si la clé privée du serveur est dévoilée, tout le mécanisme de sécurité est compromis, il faut alors re-générer un nouveau couple clé privée/publique et certificat qui y est associé.
Même chose pour les autorités de certificat qui distribue les certificats… puisque n’importe qui pourra créer son propre certificat/clé publique pour n’importe quel site (on y reviendra plus bas).

Exemple de transaction SSL/TLS

Voici un schéma qui résume une connexion à un site HTTPs de manière très succincte, car c’est en réalité beaucoup plus complexe, si on détaille tout.
Cette négociation repose sur le protocole SSL/TLS (Transport Layer Security).

  • La première phase consiste à négocier la connexion sécurisée : pour cela, le client se connecte à un site WEB, négocie les méthodes de compressions, versions de TLS etc et récupère le certificat et la clé publique (X.509 sur le schéma) du site WEB (1 et 2).
    Puis le navigateur WEB vérifie leurs intégrités.
  • La seconde phase est la création de la connexion sécurisée : le navigateur s’authentifie avec la clé publique. Le client et le serveur négocie un jeu de clé symétrique qui sera utilisée pour chiffrer les données. Le client génère une clé aléatoire qui va être chiffrée par la clé public du serveur WEB. Si l’échange de données est négociée, les données chiffrées peuvent alors être transmises.

ssl-schema

La clé symétrique générée par le client pour chiffrer les données transmises entre le client et le serveur est chiffré avec la clé public du serveur pour lui être transmise.
Seul le serveur possède la clé privée qui permet de lire les données et ainsi obtenir la clé privée pour le chiffrement symétrique.
Ainsi, la clé symétrique n’est connue que du client et du serveur.
L’usurpation est alors impossible.

C’est aussi, lors de ces deux phases que des messages d’erreurs peuvent s’afficher empêchant l’affichage du site WEB HTTPs car la négociation et la connexion HTTPs n’a pu se faire.

Les sites sécurisés fassent aux attaques en vidéo

Dans cette vidéo explique pour les sites sécurisés sont importants surtout dans les attaques de type Man in the Middle.

Erreurs et dysfonctionnement de connexion aux sites HTTPS

Pour toutes les erreurs et problèmes de connexions aux sites HTTPS, se rendre sur l’article : Erreurs et dysfonctionnement de connexion aux sites HTTPS

HTTPs et sécurité

Si l’ordinateur est infecté, il est tout à fait possible d’installer des certificats racines pour manipuler les pages HTTPs.
Certains malwares de type Trojan Banker font cela.

Par le passé, des adwares (logiciels publicitaires) ont aussi utilisé ces mécanismes pour pouvoir injecter des publicités sur les sites HTTPs.

Des exemples et explications sont données dans la seconde partie de la page : Comprendre le HTTPs et à quoi sert le HTTPs

HSTS

HTTP Strict Transport Security (HSTS) est un mécanisme de politique de sécurité proposé pour HTTP, permettant à un serveur web de déclarer à un agent utilisateur (comme un navigateur web), compatible, qu’il doit interagir avec lui en utilisant une connexion sécurisée (comme HTTPS).

Sur Google Chrome, vous pouvez régler le HSTS par site, depuis l’adresse chrome://net-internals/#hsts
La partie Add permet de forcer le HTTPs sur un site en particulier.
Delete permet de supprimer un site.
Query permet de vérifier si le HSTS est activé sur un site.

Ainsi, si adresse passe automatiquement HTTPs par le navigateur WEB, vous pouvez supprimer le site depuis la partie Delete.

Connexion non sécurisée

Dans le but de prévenir les internautes sur ces aspects de sécurité.
Les navigateurs WEB affichent maintenant une alerte lors d’une connexion à un site non HTTPs avec la mention « Connexion non sécurisée ».
Plus de détails, informations sur la page : Connexion non sécurisée

(Visité 1 475 fois, 10 visites ce jour)

Vous pouvez aussi lire...

Les Tags : #Windows10 - #Windows - #Tutoriel - #Virus - #Antivirus - #navigateurs WEB - #Securité - #Réseau - #Internet