§ Posté le 05/07/2012 à 17h 45m 34
Salut à tous !
Encore une fois, désolé pour le silence un peu prolongé de ces derniers temps. Boulot, troll et manque de motivation, pour l'essentiel, et puis aussi quelques nouvelles plus graves… je tâcherai de me rattraper. Sans grand succès. Comme d'hab…
Bref, reprenons, par un autre petit article sur l'informatique que je vous doit depuis un bon moment. Le sujet du jour : la navigation sécurisée. Une petite présentation, très rapide, mais qui, comme à l'ordinaire dans mes articles, va s'efforcer de vous présenter de façon abordable les aspects importants du système.
La notion de base est celle de chiffrement. Le sujet (comme beaucoup d'autres) me plaît, donc j'y reviendrai probablement dans un futur article en vous faisant un petit historique des principales techniques employées ; mais pour l'instant, concentrons-nous sur le concept : il s'agit de transformer un message de telle sorte qu'il ne soit lisible que par son destinataire.
Dans le langage courant, on appelle parfois aussi ça « cryptage », mais ç'n'est pas un terme correct en français (on peut en justifier l'usage en introduisant une légère différence de sens(1), mais ç'n'est pas le propos ici).
Il s'agit donc de faire en sorte que les échanges entre votre navigateur web(2) et le site avec lequel vous parlez ne soient pas écoutés par n'importe qui, mais que seul le site en question et vous puissiez accéder aux infos.
C'est super important notamment sur les sites sur lesquels vous effectuez des paiements (histoire que n'importe qui ne puisse pas récupérer vos identifiants de carte bancaire, par exemple), mais également, d'une manière plus générale, sur tous les sites sur lesquels vos utilisez des mots de passe (ce n'est pas parce que le navigateur ne l'affiche pas à l'écran que le mot de passe est invisible en temps normal, loin de là).
Alors comment ça marche ? Un certain suédois en train de devenir finlandais vous expliquera sans doute les détails mieux que moi, mais le principe est ici d'utiliser un couple clef publique/clef privée.
L'algorithme utilisé pour faire le travail permet à l'un des deux intervenants (en l'occurrence, le site web) de diffuser une certaine clef, qui permettra à l'autre intervenant (votre navigateur) de transformer, avant de les envoyer, vos messages en une sorte de bouillie de données absolument incompréhensible.
Le seul moyen de récupérer un message lisible à partir de cette bouillie est de lui appliquer un traitement utilisant une autre clef, que le site web aura précieusement gardé pour lui et n'aura diffusé à personne.
N'importe qui utilisant la clef publique est capable de concevoir une bouillie adaptée pour que le site en question ; mais seul le site en question (à condition qu'il ne partage pas sa clef privée, bien sûr) sera capable de comprendre les bouillies conçues avec sa clef publique à lui.
Pour autant, ça ne permet pas une sécurité absolue. En effet, la circulation de l'information est à peu près sûre, mais il reste possible que le site web avec lequel vous communiquez ne soit pas celui qu'il prétend être : il arrive que certains sites contrefaits réussissent à se faire passer pour le site original, et donc, vous envoient leur clef publique à eux et récupèrent vos messages à la place de leur destinataire réel.
Ç'n'est pas si fréquent, je vous rassure, mais c'est techniquement possible.
Pour contourner ce problème, le principal protocole de sécurisation utilisé actuellement (« Transport Layer Security », ou « TLS » ; anciennement « Secure Sockets Layer » ou « SSL ») prévoit la présence d'autorités de certification, qui sont d'autres sites chargés vérifier l'identité de celui avec lequel vous communiquez.
Ça nécessite que le site qui veut communiquer de cette manière se soit enregistré auprès de l'autorité de certification (moyennant finance, généralement), afin que celle-ci dispose des informations requises pour pouvoir faire son boulot, à savoir dire à votre navigateur « oui oui, vous causez bien avec la bonne personne ».
Notez qu'il est tout-à-fait possible, pour un site donné, d'utiliser TLS sans s'inscrire auprès d'une autorité de certification ; mais dans ce cas, l'échange sera considéré comme moins sécurisé.
Comme rien n'est jamais parfait, ce système ne l'est pas non plus.
L'un des problèmes majeurs de ce système de certification, est que ça ne fait que décaler le problème, puisqu'il faut que vous ayez confiance en l'autorité de certification. Les navigateurs considèrent généralement un certain nombre d'autorités comme fiables par défaut, et il est possible que vous ne soyiez pas forcément d'accord si vous allez voir dans le détail.
Un célèbre blogueur a publié à ce sujet il y a quelques temps.
Toutefois, même s'il est évidemment problématique de ne pas s'adresser à la bonne personne, le faire avec ou sans TLS ne changera pas grand chose ; et quand (ce qui arrive le plus souvent, en tout cas me semble-t-il), vous communiquez avec la bonne personne, c'est largement mieux de le faire de façon sécurisée.
Lorsque c'est possible (car tous les sites ne proposent pas l'option), activer la sécurisation est donc de toute façon une bonne idée.
…malheureusement, ce n'est pas l'avis de tout le monde. J'ai beaucoup de respect pour le navigateur Web Mozilla Firefox, mais on touche là à un des points sur lesquels je le trouve très mal conçu.
En effet, si vous essayez de vous connecter de manière sécurisée à un site auto-signé (donc, dont l'identité n'est pas garantie par une autorité de certification), il va purement et simplement vous bloquer l'accès en vous disant que c'est super louche et en vous demandant d'ajouter manuellement une « exception de sécurité » pour pouvoir accéder au site.
Personnellement, je trouve ce comportement nuisible pour deux raisons : d'abord, le logiciel n'a pas à penser à ma place. Qu'il m'avertisse est une chose, qu'il m'empêche (même s'il me laisse heureusement moyen de contourner ça) de faire ce que je veux en est une autre, beaucoup moins chouette. Ensuite, ça aurait tendance à décourager les gens d'utiliser TLS, puisque le même site en accès non-sécurisé n'est pas bloqué. Ce qui est simplement contre-productif en matière de sécurité.
Les autres navigateurs que j'ai essayé jusque là ont un comportement qui me semblent largement plus appréciable : laisser accéder au site, mais prévenir simplement que la sécurisation n'est pas absolue (Midori vous colore la barre d'adresse en rouge, par exemple).
Et pour Mozilla Firefox, il existe bien sûr une extension permettant de contourner automatiquement le problème (celle-ci ; qu'il est intéressant d'utiliser avec une autre vous indiquant le niveau de sûreté de la connexion, comme par exemple celle-ci).
Voilà, c'est à peu près tout pour la présentation de la chose, et de ses avantages et inconvénients.
Ceci étant dit, parlons un peu de l'endroit où nous nous trouvons : mon site est disponible en version sécurisée. Seulement, je ne suis pas particulièrement fan du principe des autorités de certifications, alors ma sécurisation à moi est auto-signée, et donc considérée comme non-sûre.
Ça n'me semble pas particulièrement grave, vu le peu de messages que vous avez à envoyer à mon serveur ; je n'demande, après tout, aucune donnée sensible pour vous, et heureusement.
Donc, si vous voulez accéder à mon site de façon sécurisée (et d'ailleurs à n'importe quel autre, à condition qu'il vous offre cette possibilité), remplacez simplement, dans son adresse, le « http:// » par « https:// », et le tour sera joué.
Enjoy
Modifié le 02/11/2012 à 23h 12m 01
Mise à jour :
J'ai modifié quelque peu le système depuis la rédaction de cet article, et si vous suivez simplement l'instruction ci-dessus, vous aurez la surprise de voir s'ouvrir une fenêtre vous demandant un login et un mot de passe. Pas d'inquiétude, c'est simplement une autre manière de gérer les droits d'accès. Vous aurez de plus amples informations dans cet article.
Par ailleurs, j'aimerais repréciser un point par rapport au contenu de cet article : l'intérêt du TLS/SSL est, comme je l'ai dit, de s'assurer que personne d'autre que le site avec lequel vous conversez n'écoute vos conversations. Cela s'arrête là : le principe des autorités de certifications servant à garantir l'authenticité de votre interlocuteur est une étape supplémentaire, pas toujours nécessaire : il est évident que les systèmes de paiement en ligne, par exemple, doivent s'en servir ; mais un petit blog perso comme le mien n'en a généralement pas besoin.
En termes de degré de sécurisations, donc, le « bas de l'échelle », c'est la navigation non-chiffrée, en http ordinaire, que l'on utilise par défaut. Dans ce mode-là, tout le monde peut écouter vos échanges. La navigation chiffrée en https, c'est l'étape du dessus : seul votre destinataire peut vous comprendre. La navigation chiffrée et certifiée, c'est (pour l'instant) le « haut de l'échelle » : seul votre destinaire peut vous comprendre, et une personne indépendante supposée fiable vous assure que votre destinataire est bien le bon.
Quel que soit le site sur lequel vous naviguez, donc, une sécurisation par chiffrement non-certifié sera toujours mieux que pas de sécurisation du tout, d'où l'absurdité de bloquer le chiffrement non-certifié en laissant passer les messages non-chiffrés.