J'ai vérifié la transmission des données d'un site Web HTTPS (gmail.com) à l'aide de Firebug. Mais je ne vois aucun chiffrement de mes données soumises (nom d'utilisateur et mot de passe). Où le cryptage SSL a-t-il lieu?
Le protocole SSL est implémenté comme un wrapper transparent autour du protocole HTTP. En termes de modèle OSI , c'est un peu une zone grise. Il est généralement implémenté dans la couche application, mais à proprement parler dans la couche session.
Pensez-y comme ceci:
Notez que SSL se situe entre HTTP et TCP.
Si vous voulez le voir en action, saisissez Wireshark et parcourez un site via HTTP, puis un autre via HTTPS. Vous verrez que vous pouvez lire les demandes et les réponses sur la version HTTP en texte brut, mais pas celles HTTPS. Vous pourrez également voir les couches dans lesquelles le paquet est divisé, de la couche de liaison de données vers le haut.
Mise à jour : Il a été souligné (voir commentaires) que le modèle OSI est une généralisation excessive et ne correspond pas très bien ici. C'est vrai. Cependant, l'utilisation de ce modèle est de démontrer que SSL se situe "quelque part" entre TCP et HTTP. Il n'est pas strictement précis et est une vague abstraction de la réalité.
Avec HTTPS, le chiffrement se produit entre le navigateur Web et le serveur Web. Firebug fonctionne sur le navigateur lui-même, donc il voit les données en clair; le chiffrement a lieu lorsque quitte le navigateur.
Utilisez un outil de surveillance du réseau (tel que Microsoft Network Monitor ou Wireshark ) pour observer le trafic chiffré. Utilisez un attaque Man-in-the-Middle comme Fiddler pour avoir un aperçu de ce qu'un attaquant peut faire (à savoir: intercepter la connexion et récupérer les données est possible si l'utilisateur peut être persuadé "d'ignorer les avertissements du navigateur" concernant les certificats non approuvés - alors n'ignorez pas les avertissements!).
HTTPS est HTTP sur TLS (ou sur SSL, qui est le nom de versions précédentes de TLS ).
SSL/TLS, lorsqu'il est configuré correctement, assure la confidentialité et l'intégrité des données entre deux applications communicantes (voir spécification TLS ), via un transport fiable, généralement TCP.
Bien que TCP ne soient pas mentionnés dans la spécification TLS, SSL et TLS ont été conçus dans le but de fournir un modèle qui pourrait être utilisé presque comme des sockets simples TCP sockets par les programmeurs d'applications. Outre quelques cas Edge (par exemple, pour fermeture des sockets ou si vous voulez que votre application connaisse les renégociations), c'est en effet le plus souvent le cas. SSL/TLS les piles fournissent souvent des wrappers qui rendent les sockets SSL/TLS programmables de la même manière que les sockets TCP sockets (une fois configurés); par exemple, Java SSLSocket
étend Socket
.
La plupart des applications s'appuient sur des bibliothèques existantes pour utiliser SSL/TLS (par exemple JSSE en Java, SChannel, OpenSSL, la bibliothèque NSS de Mozilla, CFNetwork d'OSX, ...). Avec peu de modifications du code TCP (généralement, tout ce qui concerne la gestion des certificats et de la confiance, et les paramètres des suites de chiffrement/chiffrement si nécessaire), les sockets SSL/TCP (ou les flux, selon le type de API) sont utilisés pour échanger du texte brut en ce qui concerne l'application. C'est la bibliothèque sous-jacente qui a tendance à faire le travail de chiffrement, de manière transparente.
Lorsque vous regardez le trafic dans les outils du développeur du navigateur, c'est ce qui est échangé au-dessus de ces bibliothèques que vous voyez. Pour voir le trafic crypté, vous devez regarder le trafic réel (par exemple en utilisant Wireshark).
Bien que tous les modèles de réseau soient imparfaits, cette question ne peut être résolue qu'en regardant ce que fait SSL (TLS vraiment). (1) En plus d'un flux réseau fiable (TCP au niveau de la couche 4 OSI), il fournit un flux bidirectionnel chiffré et (presque toujours) garantit l'identité du serveur et (éventuellement) du client. Le client d'authentification peut être un processus, un utilisateur ou une autre entité qui peut répondre correctement aux défis d'authentification requis.
TLS signifie Transport Layer Security. Cependant, puisqu'il met en œuvre l'identité, l'intégrité, le démarrage, le démontage et la gestion de la session, il appartient en grande partie à la couche session. La page Wikipedia indique que cela appartient à la couche de présentation OSI. C'est probablement faux. La couche de présentation se préoccupe davantage de rassembler les données dans des formats non dépendants du réseau et de les interpréter du côté de l'hôte via l'application appropriée.
Le chiffrement au repos (par exemple dans un champ de base de données ou un e-mail) pourrait être un candidat pour la couche de présentation, mais je dirais qu'il est plus proche d'une forme de sécurité du système d'exploitation ou des applications.
Donc, en réalité, TLS est principalement une couche session car il fournit une sécurité de session point à point pour le transport (TCP). À d'autres égards, il fournit des fonctions d'authentification qui sont clairement une couche d'application (OS, utilitaire ou application utilisateur).
C'est donc beaucoup de couche 5 et un peu de couche 7.
Bonne chance.
Bien qu'il soit possible de lire/écrire des données sur les canaux SSL/TLS comme avec les sockets TCP/IP Vanilla, en Java ou C ou autre), SSL vous propose le concept de session SSL, qui peut être maintenue sur plusieurs connexions TCP/IP. Ainsi, à mon humble avis, cela fait de SSL un protocole de couche session (je me demande pourquoi quelqu'un a proposé le nom TLS ...).
SSL fonctionne au niveau de la couche de présentation dans le modèle OSI (Layer6). Voir référence Le guide TCP/IP, M. Kozierok, page 111. "Les protocoles de cette couche prennent en charge les tâches de manipulation qui transforment les données d'une représentation en une autre, telles que la traduction, la compression et le chiffrement. L'un des schémas de chiffrement les plus populaires est généralement associé à la couche de présentation est le protocole Secure Socket Layer (SSL). " HTTPS est le protocole de couche application utilisant SSL à la couche 6 à des fins de chiffrement.
C'est une couche au-dessus de la couche de transport, généralement TCP.
Vous pouvez voir les données chiffrées entrer et sortir avec Wireshark.