Sécurisation des données sur le Web

L’installation d’OwnCloud est l’occasion de reparler de la sécurisation des échanges sur le Web. Je me suis renseigné sur ce qui est faisable dans notre cas, faisons le point!

Https://

La sécurisation sur le web se fait avec le protocole TLS, son ancêtre mieux connu étant SSL. Ce protocole est basé sur l’utilisation de deux clés: une pour signer ou chiffrer les données (publique), et une autre pour vérifier la signature ou déchiffrer (privée). C’est ce qu’on appelle le chiffrement asymétrique. Quand on voit « https » dans la barre d’adresse de son navigateur, c’est qu’on utilise ce protocole.

Le principe du chiffrement asymétrique

Ainsi, Bob souhaite voir un article sur Wikipedia, de manière chiffrée. Bob dispose d’une paire de clés SSL: une clé privée et une clé publique. Son navigateur va envoyer la clé publique au serveur de Wikipedia. Wikipedia va s’en servir pour chiffrer la page avant de la lui renvoyer.

À l’aide de sa clé privée, Bob pourra déchiffrer la page. Il est le seul à détenir la clé privée pour faire cela. L’échange semble sécurisé, mais il reste un problème…

MITM

Imaginons que Alice écoute les communications de Bob, et puisse capter tout ce qui se passe sur sa connexion Internet. Elle ne peut logiquement pas déchiffrer ce que Wikipedia envoie à Bob, puisqu’elle ne dispose pas de sa clé privée. Mais elle peut mettre en œuvre une technique que l’on appelle « attaque de l’homme du milieu » (MITM).

Quand Bob va envoyer sa clé publique à Wikipedia, Alice va intercepter la clé, et envoyer sa propre clé publique à Wikipedia. Lorsque Wikipedia répondra à Bob, Alice interceptera les données et pourra les déchiffrer avec sa clé privée. Elle va ensuite chiffrer ces données avec la clé publique de Bob, pour renvoyer à celui-ci les données qu’il a demandées. Bob ne se rendra ainsi compte de rien.

Authentification

L’attaque MITM fonctionne parce-que Bob ne sais pas à qui il parle: il croit parler à Wikipedia, alors qu’en fait il parle à Alice. Pour contrer cette attaque, il faut alors pouvoir authentifier les interlocuteurs.

Dans la réalité, lorsque Wikipedia répond à Bob, il lui envoie également son certificat. Ce certificat dit à Bob qu’il est sur Wikipedia… jusque là Bob doit faire une confiance aveugle à son interlocuteur (pourquoi devrait-il croire ce certificat?). Pour que ce certificat ait une vraie valeur, il doit être signé par une autorité de certification.

tls_wikipedia

Wikipedia paie un organisme (GlobalSign dans ce cas, mais cela pourrait être VeriSign, Symantec…) pour lui fournir un certificat signé numériquement. De son coté, le système informatique de Bob, ainsi que son navigateur, possède une liste de certificats de toutes les autorités de certifications (dont celui de GlobalSign). Quand Bob reçoit le certificat de Wikipedia, le navigateur va vérifier la signature de ce certificat grâce aux certificats qu’il possède déjà. Si la signature est bonne, Bob est certain1 qu’il parle à la bonne personne.

Mise en pratique

Pour proposer à nos visiteurs des pages sécurisées, il faut donc à la fois chiffrer les pages avec TLS, mais aussi pourvoir prouver notre identité. Cela est possible si nous sommes administrateurs de notre hébergement, ou bien si notre hébergeur propose cette fonctionnalité, et si nous faisons appel à une autorité de certification pour nous fournir un certificat signé.

L’acquisition d’un certificat n’est pas gratuite : les autorités sont des entreprises qui vous vendent des certificats relativement cher, qu’il faut renouveler tous les ans… Enfin, ça, c’était avant, car la fondation Mozilla et l’EFF ont lancé un projet de fourniture de certificats gratuits: Let’s Encrypt. Le projet vient tout juste de sortir de sa phase de tests, et est pleinement fonctionnel.

Il reste le souci de l’hébergement. Nous sommes actuellement hébergés sur un serveur Web mutualisé chez 1and1. Cela signifie que nous avons un espace pour déposer nos fichiers et programmes PHP, mais que nous ne sommes pas maîtres du serveur. Ainsi, 1and1 nous interdit d’utiliser un certificat fourni par un tiers, nous incitant à passer par lui pour acquérir un certificat annuel.

Heureusement, notre hébergeur nous permet d’acquérir un certificat gratuitement chez Symantec, permettant de sécuriser notre nom de domaine. Pour davantage d’options, par exemple pour protéger également les sous-domaines, il faudra commander un autre certificat, ce qui est bien entendu payant.

Suivant l’évolution de l’utilisation de notre hébergement, il faudra voir si cela nous convient toujours, ou si nous devons chercher d’autres offres plus adaptées (par exemple chez OVH, hébergeur français mondialement connu, qui va bientôt proposer les certificats Let’s Encrypt sur ses hébergements mutualisés).


Notes:

1. Bob devra néanmoins avoir confiance dans l’autorité de certification qui a signé le certificat de Wikipedia.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Blue Captcha Image
Refresh

*