Afin d’assurer la sécurité des informations échangées entre le visiteur que vous êtes et ce blog, le site vient de passer en connexion sécurisée à travers le protocole SSL (Transport Layer Security).

Vous pouvez le constater par :

• l’URL dans la barre d’adresse commence par https et non http (https://…) ;
• affichage d’une clé ou d’un cadenas, dont l’emplacement varie selon le navigateur : généralement à gauche de la barre d’adresse mais aussi dans la barre inférieure de la fenêtre ;
• les navigateurs peuvent ajouter d’autres signes, comme le passage en jaune de la barre d’adresse.

Lorsque vous vous connectez, les étapes suivantes ont lieu :

1. le navigateur du client envoie au serveur une demande de mise en place de connexion sécurisée par TLS.
2. le serveur envoie au client son certificat, contenant sa clé publique, ses informations (nom de la société, adresse postale, pays, e-mail de contact…) ainsi qu’une signature numérique sous forme de texte chiffré. Optionnel : si le serveur nécessite que le client s’authentifie, il lui envoie également à ce moment une demande d’authentification.
3. le navigateur du client tente de déchiffrer la signature numérique du certificat en utilisant les clés publiques contenues dans les certificats des autorités de certifications (AC) intégrés par défaut dans le navigateur.
   1. si l’un d’entre eux fonctionne, le navigateur web en déduit le nom de l’autorité de certification qui a signé le certificat envoyé par le serveur. Il vérifie que celui-ci n’est pas expiré puis envoie une demande OCSP à cette autorité pour vérifier que le certificat du serveur n’a pas été révoqué.
   2. si aucun d’entre eux ne fonctionne, le navigateur web tente de déchiffrer la signature numérique du certificat du serveur à l’aide de la clé publique contenue dans celui-ci.
      1. en cas de réussite, cela signifie que le serveur web a lui-même signé son certificat. Un message d’avertissement s’affiche alors sur le navigateur web, prévenant l’utilisateur que l’identité du serveur n’a pas été vérifiée par une autorité de certification et qu’il peut donc s’agir potentiellement d’un site frauduleux.
      2. en cas d’échec, le certificat est invalide, la connexion ne peut aboutir.
4. le navigateur du client génère une clé de chiffrement symétrique (à la différence des clés privés et publiques utilisés par les certificats qui sont asymétriques), appelée clé de session, qu’il chiffre puis envoie ce message chiffré au serveur :
   1. si le serveur ne nécessite pas que le client s’authentifie, le client chiffre la clé symétrique à l’aide de la clé publique contenue dans le certificat du serveur.
   2. si le serveur nécessite que le client s’authentifie,
      1. le client envoie son certificat au serveur
      2. le client signe le message avec sa clef privée et l’envoie au serveur (permet de vérifier que l’on possède bien la clef privée associée au certificat que l’on vient d’envoyer)
      3. on chiffre la clef symétrique avec la clef publique du serveur
5. le serveur déchiffre la clé de session envoyée par le client :
   1. soit grâce à sa propre clé privée si le serveur ne nécessite pas que le client s’authentifie (le client n’envoie donc pas de certificat au serveur),
   2. soit grâce à la clé publique contenue dans le certificat du client si le serveur nécessite que le client s’authentifie. Le serveur utilise alors le même procédé décrit au point n°3 pour authentifier le client.
6. le serveur en déduit alors la clé de session du client qu’il utilisera à partir de ce moment pour chiffrer et envoyer les donnés au client à la place de sa clé publique auparavant.
7. le client et le serveur échangent des données qu’ils chiffrent et déchiffrent uniquement à l’aide de la clé de session. La connexion TLS est établie.
8. Une fois la connexion terminée (déconnexion volontaire de l’utilisateur ou si durée d’inactivité trop élevée), le serveur révoque la clé de session.

Cependant, le passage d’un site qui comprend de nombreux liens externes susceptibles de s’afficher ici , à ce protocole nécessiterait que l’intégralité du contenu passe par des connections sécurisées.
Il n’est pas possible de demander à tous les sites concernés de passer à ce protocole, ce qui explique qu’il peut y avoir des alertes sur du contenu non sécurisé.
Ce contenu non sécurisé peut entrainer, selon votre navigateur et votre système d’exploitation, une alerte.

Comme il ne s’agit pas de transactions financières, vous ne risquez rien.

Veuillez noter que les grands acteurs du Web ( Google, par exemple ) tendent à faire migrer l’ensemble des sites vers des protocoles sécurisés afin de renforcer la confiance des internautes lorsqu’ils naviguent à travers le web. En outre, les échanges étant chiffrés , il devient très difficile d’écouter ces communications et quasiment impossible de les décrypter, et qui s’en plaindrait ?