Vous devriez considérer les couches OSI comme un emballage.

Disons que je veux vous envoyer un verre. J'ai choisi un emballage original à des fins publicitaires, montrant à quel point mon produit est beau et ce que vous pouvez acheter pour ajouter à votre expérience «verre». C'est la couche supérieure de mon protocole.

Ensuite, j'ai mis ce paquet dans une boîte remplie de trucs souples parce que je ne veux pas qu'il soit cassé par le transport. Ceci est une deuxième couche.

Ensuite, mon service d'expédition enferme cette boîte dans un emballage plus grand, avec une étiquette à expédier à votre domicile. Encore une fois, une autre couche.

Ensuite, le transporteur a mis cette boîte dans un camion avec de nombreuses autres boîtes et a demandé au chauffeur de se rendre dans un autre centre de livraison, encore une autre couche.

Pour ce que nous savons, le chauffeur de camion n'a pas besoin de savoir:

• où vont les boîtes exactement chez vous, il a juste besoin de connaître votre adresse
• quelle protection y a-t-il dans les boîtes, il doit juste conduire de manière aussi sûre que cela est indiqué dans son contrat
• ce qui se trouve exactement dans les boîtes

Allons dites maintenant que je souhaite assurer la confidentialité de mon envoi. Parce qu'un conducteur curieux pourrait essayer de falsifier les paquets pour savoir ce qu'il y a à l'intérieur, ou le voler et le revendre.

Je peux utiliser un protocole où votre verre à revêtement souple emballé est également placé dans une boîte en métal avec un casier. Cela le protégera contre toute altération par le chauffeur du camion, car il ne pourra pas jeter un coup d'œil à l'intérieur ou prendre la marchandise. Il ne protège pas les couches inférieures, il pourrait encore jeter toute la frette dans un lac, c'est un déni de service. De plus, mon casier ne se soucie pas de ce qu'il contient. Ce pourrait être votre verre, ce pourrait être des fleurs ou il pourrait être vide. Mais cela sert toujours à éviter que quiconque autre que vous (et l'expéditeur ofc) ne sache ce qu'il y a à l'intérieur.

Il en va de même pour les protocoles de l'OSI. Les couches inférieures ne se soucient pas de ce qui se passe dans les couches supérieures. Ceci est laissé à un autre agent pour le décoder / le gérer.

Modifier pour clarification: lorsque nous disons "laissé inchangé", cela ne signifie pas que les informations ne sont pas traitées. Pour SSL en particulier, la charge utile de la couche SSL est un chiffrement du paquet de la couche supérieure. Mais lorsque SSL opère de l'autre côté, il décrypte le paquet d'origine sans aucune modification.

Alors que OSI n'est qu'un modèle et qu'en réalité les couches peuvent être floues ou inexistantes, le concept de protocoles de couches est spécifiquement de permettre à un changement dans une couche particulière de laisser les couches au-dessus et en dessous d'elle seules.

À titre d'exemple:

• Physique - un paquet de base se soucie-t-il s'il circule sur cuivre, fibre ou sans fil? Il pourrait voyager sur les trois à un moment donné de son voyage. Vous ne voulez pas avoir à réécrire http dans des saveurs spécifiques pour chacun de ces supports physiques, donc vous le faites une fois.

Les éléments importants sont donc la manière dont chaque couche s'interface avec les autres. .

La métaphore de @ M'vy du transport d'un objet physique est ici très appropriée.

TCP fournit aux applications une interface de flux. Il y a quelques exceptions où les détails fuient, mais généralement un socket TCP est ouvert, puis chaque côté envoie une série d'octets à l'autre. Ces octets seront livrés intacts et dans l'ordre, jusqu'au moment où l'extrémité distante ferme la connexion (dont vous serez informé). Les applications doivent uniquement connaître l'interface de flux. Ils n'ont pas besoin de connaître les détails du matériel réseau sous-jacent, ils n'ont pas besoin de connaître le contrôle de la congestion, la taille des fenêtres, la retransmission des paquets, ou même qu'il y a sont des paquets.

TLS se trouve au-dessus de TCP, et fournit des services d'authentification et de chiffrement, et il aussi fournit aux applications une interface de flux. Il y a un tas de choses supplémentaires sous le capot, un tas de nouvelles conditions d'erreur potentielles et un tas de nouvelles métadonnées pour lesquelles une application interroge un socket (par exemple, des informations sur le certificat distant et son problème), mais le les opérations de base sont les mêmes - se connecter à une adresse donnée, envoyer des octets, recevoir des octets, fermer la connexion et être informé d'une fermeture à distance.

Le fait est que tout protocole de niveau application qui peut fonctionner au-dessus des flux fournis par TCP peut également fonctionner au-dessus des flux fournis par SSL, sans aucune modification fondamentale du l'application elle-même. En fait, dans les cas où il n'est pas considéré comme important que l'application reçoive des informations sur le cryptage utilisé, ou le certificat de la partie distante, ou quoi que ce soit d'autre, vous pouvez utiliser un proxy comme stunnel pour traduire entre un TLS - une connexion TCP cryptée et une connexion non cryptée. Par exemple, stunnel sur une machine cliente pourrait permettre à un client de messagerie normal (non compatible TLS) pointé sur le serveur IMAP localhost: 143 de se connecter au serveur IMAPS mymailserver: 993 ; ou stunnel sur une machine serveur pourrait écouter les connexions HTTPS sur externalip: 443 et les envoyer par proxy vers internalserver: 80 , autorisant internalserver (un serveur HTTP ) pour avoir des communications sécurisées avec le monde même s'il n'implémente pas TLS lui-même.

C'est comme déplacer des véhicules sur la route. Comme la route est le support fixe et sur elle de nombreux types de véhicules peuvent rouler et donc si vous fabriquez un nouveau véhicule pour qu'il puisse rouler sur route, le véhicule doit avoir des pneus qui pourraient rouler sur cette route.

De même, si vous considérez Ethernet comme un support, il pourrait transporter divers protocoles réseau comme IPv4 ou IPv6. Le point ici est donc que le modèle de réseau est conçu de manière si modulaire que vous pouvez remplacer les éléments à votre guise, à condition qu'ils soient conformes à certaines spécifications d'interface.

Donc, la conception modulaire spécifie que quel que soit votre travail interne, peu importe ce qui compte, on vous donne une entrée d'une certaine manière sur celui-ci et génère une sortie compréhensible par le module suivant.

Après avoir établi une connexion sécurisée, un navigateur Web posera toujours le même type de question telle que

  GET /som/page.html HTTP / 1.1host: www.example.com  

et le serveur Web répondra toujours de la même manière

  200 OKContent-Type text / html ...  

La seule différence est que sous cette conversation, nous n'avons pas de connexion TCP directe mais plutôt un cryptage. Tout comme les couches supérieures ne sont "pas conscientes" de ce que TCP fait normalement (comme la retransmission de paquets, l'accusé de réception, l'ajustement de fenêtre, ...), elles ne sont pas non plus conscientes du cryptage sous-jacent en cours.

Eh bien, à proprement parler, il y a une certaine interdépendance: la couche de chiffrement est construite sur l'utilisation d'un certificat appartenant spécifiquement au FQDN www.example.com, dont le serveur ne connaît pas traditionnellement jusqu'à ce qu'il reçoive le hôte: en-tête. C'est aussi pourquoi les implémentations plus anciennes pouvaient gérer plusieurs http-vhosts sur une seule ip, mais un seul https-vhost par ip. Ce problème a été résolu par SNI.

Les protocoles de haut niveau peuvent ne pas être sécurisés lorsqu'ils sont utilisés, inchangés, avec SSL. Il y a une possibilité d'attaques de canaux secondaires.

Comme d'autres l'ont bien expliqué, SSL vous permet d'envelopper un flux non chiffré dans un flux chiffré. En théorie, aucune information sur les données transmises ne doit être divulguée. En pratique, il y a une donnée qui fuit toujours - la quantité de données transmises.

Cela ressemble à une fuite acceptable, et dans certains cas, c'est le cas. Cependant, il existe un certain nombre d'attaques, telles que l'attaque CRIME, et cette attaque sur VOIP, qui tirent parti du fait que les données sont compressées et que les taux de compression varient. en fonction du contenu du message, pour glaner des informations sur le contenu des messages.

D'autres attaques de canal secondaire peuvent également être possibles en utilisant d'autres éléments de données divulguées, comme le moment précis des demandes et des réponses.

  Http Https + ------------------ + + ------------------ + | 7 http méthodes | | Méthodes http | < --- idem Aucun changement nécessaire + ------------------ + + ------------------ + | 6 données : ex) "1 000 $" | | données: ex) "kf4d3s1" | < --- données cryptées + ------------------ + + ------------------ + | 5 Sock: | | Chaussette: | + ------------------ + + ------------------ + | 4 TCP: | | TCP: | + ------------------ + + ------------------ + | 3 IP: | | IP: | + ------------------ + + ------------------ + | 2 PPP: | | PPP: | + ------------------ + + ------------------ + | 1 RJ45: | | RJ45: | + ------------------ + + ------------------ + 7. Couche d'application -> Http6. Couche de présentation -> MIME SSL TLS XDR < ---- C'est ce que vous voulez5. Couche de session -> Sockets 4. Couche de transport -> TCP UDP SCTP DCCP3. Couche réseau -> IP IPsec ICMP IGMP OSPF RIP2. Couche de liaison de données -> PPP, SBTV, SLIP1. Couche physique -> FDDI, B8ZS, V.35, V.24, RJ45.  

Seules les méthodes de négociation / prise de contact changent pour un cryptage supplémentaire.

Chiffres HTTPS un message HTTP (données) avant la transmission et le déchiffre à l'arrivée

Les protocoles de couche supérieure ne se soucient pas des détails des couches inférieures . Ils supposent simplement que les couches inférieures ont été implémentées d'une manière ou d'une autre et partent de là. Si nous utilisons le modèle TCP / IP, il existe quatre de ces couches:

OSI définit une couche physique, qui gère la connexion de deux machines ensemble; TCP / IP ne le fait pas, mais il est utile de réfléchir ici . Les paires torsadées, coaxiales, CAT6 et les ondes radio sont des moyens courants de connecter des machines, mais vous pouvez utiliser presque tout, y compris les faisceaux laser, les ondes sonores et, oui, pigeons voyageurs. >

La couche Lien, qui gère la réception d'un signal sur deux machines directement connectées . La famille 802.11 (Wi-Fi), la famille 802.3 (Ethernet) et PPP (modems) sont probablement les protocoles de couche liaison les plus populaires aujourd'hui, mais il en existe d'autres.

La couche Internet , qui reçoit un signal sur deux machines qui ne sont pas directement connectées via une chaîne de machines qui sont . C'est là que réside l'IP, à la fois en IPv4 et IPv6.

La couche Transport, qui gère la logistique de la transformation des signaux en un flux de données utilisable . TCP et UDP vivent tous les deux ici, tout comme certains protocoles moins connus.

La couche Application, qui interprète les données assemblées par la couche Transport . C'est là que la plupart des protocoles que nous entendons communément parler de -HTTP, FTP, POP, IMAP, etc. sont en direct.

HTTP réside dans la couche Application . Cela suppose que vous disposez déjà d'un moyen significatif d'obtenir un flux de données sur des machines qui ne sont peut-être pas directement connectées les unes aux autres. Tant que vous l'avez, HTTP ne se soucie pas de l'origine du flux de données. Techniquement, vous n'avez même pas besoin d'utiliser TCP / IP dans le transport sous-jacent, bien qu'en pratique presque tout le monde le fasse.

Pour les besoins de tous les jours, SSL / TLS vit dans la couche Transport (la vérité technique est plus compliquée, mais elle n'affecte pas les utilisateurs finaux). C'est-à-dire que vous lui donnez un flux de données à envoyer et que vous récupérez un flux de données lorsque vous recevez, tout comme TCP / IP. Notamment, SSL / TLS ne se soucie pas du contenu de son flux de données: vous pouvez lui transmettre ce que vous voulez, et il fera son travail.

Parce qu'aucune des couches ne se soucie de ce que l'autre fait, vous pouvez les échanger librement . HTTP est heureux tant qu'il obtient les flux qu'il veut, et ne se soucie pas de ce que les protocoles sous-jacents font à ces flux entre-temps, vous pouvez donc utiliser n'importe quel protocole de couche de transport en dessous. TCP / IP (et SSL / TLS) ne se soucient pas du contenu des données, sauf si nécessaire pour vous assurer que les données résultantes à l'autre extrémité ont exactement la même apparence que ce que l'utilisateur a envoyé, vous pouvez donc utiliser n'importe quelle application -layer protocole avec eux

Je connais les couches OSI

OK, première erreur - mais comme vous l'avez vu dans les autres réponses, c'est une idée fausse courante. TCP / IP n'est pas OSI. Il est antérieur à l'OSI mais un certain nombre d'années. Et ce n'est même pas destiné à être la même chose. TCP / IP est (certaines des couches de) un protocole réseau, OSI est un modèle de conception d'un protocole réseau complet. Essayez d'expliquer TCP / IP en termes d'OSI et vous allez vous décoller très bientôt, par exemple. HTTP / 2 sur TCP / IP? 4 couches de session différentes, compression effectuée dans au moins 2 couches séparées de la pile.

SSL ou TLS est une méthode d'implémentation d'une communication asymétrique sur n'importe quelle interface de flux bidirectionnel. Cela signifie qu'il peut fonctionner sur TCP / IP, IPX / SPX, sockets de domaine Unix, canaux nommés (duplex intégral), RS-232 ... Mais à quand remonte la dernière fois que vous avez utilisé un réseau de données autre que TCP / IP?

Luc n'a pas tort de dire que SSL / TLS peut fonctionner sur UDP, il ne raconte tout simplement pas toute l'histoire - pour une telle architecture, il y a une couche supplémentaire entre les parties TLS et UDP qui implémente le réassemblage de flux, récupération d'erreur et gestion de la bande passante.

Dans sa première phrase, il dit que les protocoles sur les couches supérieures peuvent rester inchangés.

C'est faux, point final.

Couches supérieures besoin d'indiquer d'une manière ou d'une autre que SSL / TLS doit être utilisé; sur le Web, cela se fait avec le schéma HTTPS: URL, avec le drapeau sécurisé sur les cookies HTTP et avec une politique HSTS (HTTP Strict Transport Security).