Nous mettrons à jour notre Politique de confidentialité prochainement. En voici un aperçu.

L'essentiel de IIS

Comprendre le protocole SSL

Testez gratuitement nos 1343 formations

pendant 10 jours !

Tester maintenant Afficher tous les abonnements
Vous allez aborder théoriquement le chiffrement du trafic HTTP. Découvrez également la nature de l'infrastructure de clé publique de SSL (Secure Sockets Layer).
09:20

Transcription

Notre association nanipabulophiles a de plus en plus de succès, de plus en plus d'adhérents bien entendu, c'est une association d'utilité publique. Et pour couvrir ses frais elle décide de faire de l'e-commerce. Pour vendre bien entendu des nains de jardin, mais aussi des accessoires, des photos, des cartes postales, des petites charrettes, etc. Bien entendu pour ce faire, elle va faire du commerce électronique sur son site nanipabulophiles.site et il va être indispensable de faire du SSL. C'est-à-dire de sécuriser la connexion entre le client qui est ici et le serveur. D'abord, pourquoi sécuriser la connexion ? Parce que du client vers le serveur on passe par Internet. Et en passant par Internet, le risque est que quelqu'un puisse intercepter la communication et s'empare par exemple du numéro de carte de crédit qui est envoyé par le client vers le serveur simplement en faisant ce qu'on appelle du « sniffing » du réseau c'est-à-dire en récupérant les paquets qui passent. Parce que par défaut le protocole http est un protocole purement texte qui envoie ces informations en clair. Il va donc falloir trouver une méthode de chiffrement pour chiffrer la communication entre le client et le serveur. Cette technique de chiffrement utilise un principe « Public Key Infrastructure ». Infrastructure de clé publique. Pourquoi de clé publique ? Et bien parce que historiquement, si vous voulez chiffrer il vous faut une clé de chiffrement. D'où la clé. Le problème, c'est le même que dans la vie réelle d'ailleurs, si vous, vous avez une maison et que vous avez la clé de votre porte et que vous l'envoyez par la Poste, comme ceci par exemple, à travers Internet, à quelqu'un, et bien cette personne elle peut vous prendre la clé. Quel est l'intérêt, à travers Internet, de s'envoyer une clé en clair pour pouvoir ensuite chiffrer avec la clé ? Évidemment, si au premier mouvement j'envoie la clé, elle est récupérée, et bien j'ai plus aucun intérêt à chiffrer puisque le pirate qui serait ici a la clé et peut donc déchiffrer les messages. Donc ça n'a plus aucun sens. Il faut que je m'assure que la clé que je vais envoyer ici soit une clé qui soit incapable de déchiffrer. En d'autres termes, au lieu d'utiliser une infrastructure de clé symétrique, c'est-à-dire la même clé qui va être utilisée ici pour chiffrer et ici pour déchiffrer le message. Si j'envoie mon numéro de carte de crédit ici et bien il faut que ce soit chiffré ici et déchiffré ici. Et bien pour empêcher ça, il faut que j'aie deux clés. Ce qu'on appelle une paire de clés. Ça va fonctionner comme ça. On va, au niveau du serveur, créer ce qu'on appelle un certificat. Un certificat c'est une norme X509, c'est quelque chose qui est composé de : une clé privée qui reste totalement secrète, que le serveur garde bien cachée dans son coffre-fort ou dans sa poche, et en plus comme c'est un certificat, cette clé privée a des informations d'authentification qui permettent à tout le monde sur Internet de bien vérifier que ce serveur et sa clé appartiennent bien à un nom de domaine reconnu. C'est-à-dire que ce système qui s'appelle SSL, « Secure Sockets Layers », je vais y revenir dans une seconde, doit non seulement assurer le chiffrement mais aussi l'authentification. Je vous en reparle dans un instant. Et pour ça, ça veut dire que le certificat doit non seulement avoir des clés mais une identité, c'est le principe du certificat. Il y a une identité qui est liée ici et qui fait que si vous, vous vous connectez à un site d'e-commerce, qui s'appelle par exemple nanipabulophiles.shop, vous voulez vous assurer que vous donnez votre numéro de carte de crédit à nanipabulophiles et pas à quelqu'un qui a fabriqué un faux site pour se faire passer pour nanipabulophiles. On est bien d'accord. Donc un, clé privée. Deux, identité de la clé privée. Trois, clé publique. Donc une paire de clés. Et en fait, la clé publique, elle, elle peut être envoyée n'importe où, à n'importe qui, ça n'a pas d'importance. Pourquoi ? Parce que cette clé publique ne peut servir qu'à une chose : le chiffrement. Elle ne peut pas déchiffrer les messages. Ici mon client va envoyer son numéro de carte de crédit qui va être chiffré par la clé publique, ça passe totalement chiffré à travers le réseau, ici, la clé privée qui est restée secrète, qui n'a jamais été envoyée à personne peut déchiffrer le message de la clé publique parce que c'est elle et elle seule qui arrive à déchiffrer des messages de cette clé publique. Toute la sécurité repose sur ça. D'où Infrastructure de clé publique. En fait, dans ces deux sens, la clé publique peut chiffrer les messages et la clé privée peut les déchiffrer. La clé privée peut également signer un message qui va être envoyé, et la clé publique peut vérifier la signature. Ça permet d'aller dans les deux sens. Si je veux chiffrer quelque chose pour quelqu'un, lui envoyer quelque chose de secret, j'ai sa clé publique, tout le monde peut l'avoir, mais je ne peux envoyer qu'à quelqu'un qui a la clé privée. Ce qui veut dire que mon message, j'ai la garantie de l'authenticité du message. Puisque quelqu'un qui se fait passer pour nanipabulophiles au milieu de tout ça, sera incapable de déchiffrer. Deuxième chose, les messages qui sont renvoyés ici ils peuvent être vérifiés par la clé publique parce qu'ils peuvent être signés par la clé privée. Et dans tout ça, on a une identité qui prouve que les messages qu'on envoie arrivent au bon endroit. Donc c'est parfait. Donc le système s'appelle simplement SSL. Le SSL assure donc l'authentification, l'intégrité et la sécurité. L'authentification via un certificat et une identité liée au certificat, l'intégrité parce qu'il y a un « hand check », il y a une communication entre le client et le serveur qui fait que d'un côté la clé publique chiffre quelque chose qui ne peut être déchiffré que par le serveur, qui a la clé privée, et d'un autre côté la communication, dans l'autre sens, elle est garantie venir du bon serveur parce que le serveur signe avec sa clé privée et au niveau de la clé publique on vérifie simplement que la signature est bonne. Donc des deux côtés on sait qui on est. On sait aussi, et c'est le principe de l'intégrité, que les messages puisqu'ils sont signés, chiffrés d'un côté, signés de l'autre, sont intègres. Personne n'a pu les modifier au passage. Puisque la signature est une vérification sous forme de hash en fait, du message qui est envoyé du serveur vers le client. Et en termes de sécurité et bien on l'a vu, on a une clé publique, une clé privée, et donc on a une sécurisation : tout est complètement chiffré. Au niveau du protocole lui-même, et bien on a juste trois noms à connaitre. On a le protocole SSL lui-même qui s'appelle donc « Secure Sockets Layers ». Il y a eu une évolution de ce protocole qui s'appelle TLS mais on parle en général le plus souvent de SSL. Mais on veut dire TLS parce que le protocole SSL au départ était un petit peu simpliste, et que TLS l'a nettement amélioré. C'est donc, comme vous le voyez, une couche, « Secure Socket Layer », qui va s'ajouter par-dessus HTTP, on n'a pas eu besoin de modifier le protocole HTTP pour faire du SSL, on a simplement fait une surcouche pour chiffrer le contenu du HTTP. Et le mélange de ces deux choses c'est le protocole HTTPS. Et donc TLS, SSL, ont encore un léger problème, c'est qu'il est difficile d'héberger sur un site web avec une adresse IP, plusieurs domaines. Alors c'est possible parce que dans le certificat lui-même, puisqu'il y a identification au niveau du certificat, et bien dans le certificat lui-même vous pouvez, lorsque vous prenez un certificat, indiquer les différents noms de domaines par exemple www.nanipabulophiles.site ou nanipabulophiles.site, etc. Mais après coup c'est plus difficile. Donc c'est pas très souple en fait. Vous devez dès le départ savoir sur quels noms de domaines vous voulez placer votre certificat. Le ou les noms de domaines lorsque vous achetez votre certificat vous devez le préciser. Parce que c'est vraiment fixé dans le certificat et lorsque le client se connecte, et bien évidemment s'il se connecte sur un nom de domaine qui n'est pas le même, et bien son navigateur va envoyer un message en disant : attendez, c'est pas la même adresse là, il y a un problème. Donc il y a une extension qui est supportée, je vous le disais au début, dans IIS qui s'appelle SNI « Server Name Indication » qui permet de rajouter dynamiquement des informations de noms de serveurs pour avoir par exemple différentes IP et différents certificats sur la même machine. Ça c'est pas très important. On va voir comment fonctionne SSL en pratique sur IIS.

L'essentiel de IIS

Administrez IIS (Internet Information Server) en toute confiance. Abordez les notions de site, d'application, l’attribution de permissions sur les répertoires de l'espace web, etc.

3h45 (43 vidéos)
Aucun commentaire n´est disponible actuellement
 
Logiciel :
IIS IIS 8.5
Spécial abonnés
Date de parution :10 mai 2016

Votre formation est disponible en ligne avec option de téléchargement. Bonne nouvelle : vous ne devez pas choisir entre les deux. Dès que vous achetez une formation, vous disposez des deux options de consultation !

Le téléchargement vous permet de consulter la formation hors ligne et offre une interface plus conviviale. Si vous travaillez sur différents ordinateurs ou que vous ne voulez pas regarder la formation en une seule fois, connectez-vous sur cette page pour consulter en ligne les vidéos de la formation. Nous vous souhaitons un excellent apprentissage avec cette formation vidéo.

N'hésitez pas à nous contacter si vous avez des questions !