Versions
29/11/2011: correction d'une erreur soulevée par @JEDI_BC sur la validation du certificat
29/11/2011: un peu plus explicite
21/11/2011: draft
Contactez-nous
Kitpages
17 rue de la Frise
38000 Grenoble
tel : 04 58 00 33 81
Principes de HTTPS
Introduction
Pour comprendre ce chapitre, je vous conseille d'aller voir auparavant la page "Chiffrement" qui explique notamment les principes d'un chiffrement symétrique, asymétrique et d'un tiers de confiance.
Les 2 étapes de chiffrement
Il faut bien comprendre qu'il y a 2 étapes de chiffrement :
- HTTPS utilise un chiffrement assymétrique pour établir une connexion et échanger une clé symétrique
- Ensuite les échanges utilisent un chiffrement symétrique
L'intérêt de ce système est que le chiffrement symétrique est beaucoup moins gourmand en ressources. Une fois la connexion établie, l'HTTPS consomme des ressources CPU assez raisonnables. (notons par contre que l'établissement de la connexion est très consommatrice en ressources).
Schéma général
Le schéma suivant donne une vue d'ensemble du processus
Le certificat
Un certificat est délivré par une entreprise comme Thawte ou Verisign. Son role est de garantir que la clé publique envoyée par le serveur HTTPS correspond bien au site demandé.
Le navigateur dispose d'une ribambelle de certificats racine correspondant aux organismes de certifications. Ces certificats racine permettent de valider le certificat du serveur HTTPS. Une fois le certificat validé, les échanges peuvent commencer.
Certificat autosigné et alertes de sécurité
Un navigateur peut décider d'accepter un certificat "non validé" par une autorité de certification. Dans ce cas normalement il demande une confirmation à l'internaute avant de continuer. Les cas les plus courants sont les suivants :
- Le certificat a expiré
- Le serveur https a un certificat autosigné
Un certificat autosigné est un certificat généré artificiellement et qui n'est relié à aucune autorité de certification => les navigateurs avertissent l'internaute que le certificat n'est pas sur.
Pourquoi un certificat ? attaque "man in the middle"
Dans un cas standard, il n'est pas si simple d'intercepter des communications. Si vous êtes chez vous, connecté à une freebox ou une livebox, votre FAI peut lire vos communications. Après ça se perd dans les "grands routeurs" d'Internet. En clair si votre voisin de palier veut lire vos communications, ça n'est pas si simple.
Le cas à problème, c'est par exemple le cas d'une entreprise. Si vous êtes connectés au réseau local d'une entreprise, l'entreprise peut décider de mettre en place un Firewall qui peut lire tout ce qui passe sur le réseau.
Si vous avez un certificat non signé, le firewall de l'entreprise peut décider de renvoyer son propre certificat à la place du certificat du serveur (et établir une nouvelle connexion avec le serveur HTTPS). De votre coté, vous voyez une exception de sécurité que vous allez accepter parce que vous savez que votre certificat et bidon, et ça y'est, votre entreprise peut lire en clair tout ce que vous échangez avec le site alors que vous pensiez que tout était sécurisé par HTTPS.
C'est je pense la menace la plus importante et la vraie justification des certificats. Cette attaque se nomme "man in the middle", parce que le firewall s'insère au milieu de la communication de la façon la plus discrête possible.
Conclusion et cas concrêts
De futurs tutoriels montreront :
- Comment interroger un serveur HTTPS avec curl (en PHP)
- Avec vérification du certificat
- Sans vérification du certificat
- Comment configurer un serveur Apache en HTTPS
- Avec un certificat acheté
- Avec un certificat autosigné
Commentaires
Note : on ne peut plus ajouter de commentaire sur ce site