Le cryptage en HTTPS est-il effectué par le navigateur ou par le système?
Cela peut être une question de bon sens, mais je ne trouve aucune documentation à ce sujet après une longue recherche sur google
Lorsque le navigateur fait une requête HTTP, crypte-t-il les données ici et là, et tout proxy (même sur le même système) recevra-t-il les données sous une forme cryptée? Ces données peuvent-elles être falsifiées avec succès via un proxy (sur le même système, pas sur le réseau)?
Si le navigateur effectue le cryptage/décryptage, veuillez me faire savoir s'il existe une documentation qui le dit. Ou si le chiffrement/déchiffrement est pris en charge par le protocole SSL sous-jacent uniquement au niveau du transport (lorsque la demande est dans le réseau).
Le "S" dans HTTPS signifie "sécurisé" (Hypertext Transfer Protocol Secure). Il s'agit d'un protocole de communication pour une communication sécurisée qui utilise la sécurité de la couche de transport ( TLS) et son prédécesseur, Secure Sockets Layer (SSL).
TLS/SSL est initialisé à la couche 5 ( la couche session ) puis fonctionne à la couche 6 ( la couche présentation ). La plupart des applications, comme les navigateurs Web, les clients de messagerie électronique ou la messagerie instantanée, intègrent les fonctionnalités des couches OSI 5, 6 et 7.
Lorsqu'il s'agit de HTTPS, ce sera une implémentation de SSL/TLS dans le contexte du protocole HTTP. SSL/TLS sera ensuite implémenté dans le navigateurs (et serveur Web) pour assurer la confidentialité et l'intégrité du trafic HTTPS (cryptage réel des données).
Chromium et Firefox utilisent une API appelée NSS pour implémenter SSL/TLS dans leur navigateur respectif.
Microsoft Windows par exemple a un package de sécurité appelé SChannel (Secure Channel) qui implémente SSL/TLS afin de fournir une authentification entre les clients et les serveurs. Schannel est par exemple utilisé par les clients/serveurs Microsoft Windows dans un environnement Active Directory.
Quant au proxy et à la falsification des données, cela dépend du protocole avec lequel vous travaillez. Un bon exemple pour vous familiariser dans un contexte HTTP (S) est de jeter un œil à Burp Proxy .
Il y a beaucoup de bonnes réponses ici sur la façon dont HTTPS est géré par le navigateur, mais je ne suis pas sûr que votre vraie question ait été résolue.
Ces données peuvent-elles être falsifiées avec succès via un proxy (sur le même système, pas sur le réseau)?
Ici, la réponse est oui . Cela peut se produire de deux manières:
- Le navigateur lui-même est compromis par un plugin, une extension ou une mise à jour malveillants.
- Le système est compromis par des logiciels malveillants qui ont modifié les certificats racine de confiance utilisés par le navigateur (qui peuvent ou non être les mêmes que ceux utilisés par le système d'exploitation).
La réponse est ... peut-être.
Si vous spécifiez https://, le navigateur prend la responsabilité du chiffrement. Certains navigateurs utilisent des API fournies par le système d'exploitation (en regardant IE ici) tandis que d'autres (par exemple, Firefox) utilisent leur propre crypto et ignorent complètement le crypto fourni par le système d'exploitation.
La résistance à la falsification est garantie par l'ICP. Donc, si le magasin de certificats de confiance de votre système est corrompu, tous les paris sont désactivés. Par exemple, certaines sociétés installeront leur propre certificat d'autorité de certification de signature interne qui leur permet de gérer par proxy toutes les sessions de navigateur sécurisées sans déclencher aucune alarme par le navigateur. Là encore, sous Windows, les certificats d'autorité de certification sont gérés par le système d'exploitation si vous utilisez IE ou Chrome, tandis que Firefox a sa propre liste d'autorités de confiance unique et distincte.
Mais si votre système est compromis, alors vous êtes grillé. Aucune sécurité ne peut être garantie, pas même SSL. En effet, les agents malveillants peuvent s’intégrer n’importe où dans la chaîne; peut-être au niveau du réseau, mais peut-être aussi dans le navigateur, ou dans le pilote d'affichage, ou à l'écoute des touches ... rien n'est sûr. Il y a un classe populaire de logiciels malveillants aujourd'hui qui s'insère dans le navigateur pour lire et modifier les données cryptées avant il est crypté et après il est déchiffré. Un objectif, par exemple, est de modifier légèrement votre expérience sur un site de banque en ligne pour vider les comptes bancaires et transférer tout votre argent à l'attaquant.
Le navigateur crypte les données, à condition qu'il fasse confiance au certificat SSL/clé publique qui lui a été donné par le serveur auquel il accède, qui est ensuite transmis au serveur et décrypté afin de démarrer une "session" cryptée, entre les deux entités.
Excellente explication facile à comprendre ici .
- Le navigateur se connecte à un serveur Web (site Web) sécurisé avec SSL (https). Le navigateur demande au serveur de s'identifier.
- Le serveur envoie une copie de son certificat SSL, y compris la clé publique du serveur.
- Le navigateur vérifie la racine du certificat par rapport à une liste d'autorités de certification approuvées et que le certificat n'est pas expiré, non révoqué et que son nom commun est valide pour le site Web auquel il se connecte. Si le navigateur approuve le certificat, il crée, chiffre et renvoie une clé de session symétrique à l'aide de la clé publique du serveur.
- Le serveur déchiffre la clé de session symétrique à l'aide de sa clé privée et renvoie un accusé de réception chiffré avec la clé de session pour démarrer la session chiffrée.
- Le serveur et le navigateur chiffrent désormais toutes les données transmises avec la clé de session.
Quelques informations précieuses sur les autorités de certification (autorités de certification): https://en.wikipedia.org/wiki/Certificate_authority
Le cryptage SSL est configuré par le navigateur (ou toute application utilisant SSL), même lorsqu'un proxy local réside sur le système. Par exemple, lorsque vous effectuez un pentest, vous devez configurer un proxy local pour avoir votre propre certificat afin de pouvoir décrypter le trafic entre le navigateur et le point de terminaison.
Le navigateur gère le déchiffrement normalement. Il y a cependant quelques exceptions. Les proxys peuvent supprimer SSL (dans ce cas, l'icône de verrouillage ne s'affichera pas normalement) ou ils peuvent être légèrement plus intelligents et résigner le SSL avec un certificat approuvé par le client de telle sorte que le verrou s'affiche toujours, mais les informations sur le cert est changé. Les configurations vraiment avancées peuvent en fait surveiller la connexion SSL si elles ont accès à la clé privée du serveur sans rien changer, bien qu'elles soient utilisées côté serveur, pas côté client (en raison de la façon dont la clé est dérivée pour une session SSL).
Les spécifications SSL/TLS dictent le protocole over-the-wire, mais elles ne disent rien sur la façon dont un client est implémenté. En règle générale, le noyau du système d'exploitation fournit une base non chiffrée de base TCP socket. Pour implémenter la couche SSL, le navigateur appelle des fonctions dans une bibliothèque cryptographique (comme OpenSSL , SSLeay, GNUtls ou NSS ). Ainsi, le La prise en charge SSL se produit généralement dans l'espace utilisateur , dans le même processus que le reste du navigateur.
Quant à savoir si vous considérez que le support SSL est fourni par le "système" - cela dépend. Le navigateur peut se lier à la bibliothèque cryptographique de manière statique ou dynamique. Une bibliothèque dynamique (ou DLL) peut être distribuée avec le système d'exploitation, ou le fournisseur du navigateur peut expédier sa propre copie de la bibliothèque.
Côté serveur, la situation est souvent similaire, où un module de serveur Web fournit une prise en charge SSL (dans l'espace utilisateur, dans le même processus que le reste du serveur Web). Cependant, les configurations alternatives sont également courantes. La prise en charge cryptographique peut être accélérée matériellement . Un proxy inverse , tel qu'un équilibreur de charge, peut s'asseoir devant le serveur Web réel et traduire entre HTTP et HTTPS, auquel cas les données peuvent voyager sans chiffrement dans le réseau du fournisseur de contenu.
Pour répondre au problème d'interception et de falsification des données: Quiconque a accès à la clé privée du serveur peut facilement décrypter la transmission . En corollaire, tout serveur qui présente un certificat signé par une autorité de certification approuvée par votre navigateur peut usurper le site Web, tant que le nom d'hôte sur le certificat correspond au nom d'hôte dans l'URL. (Par exemple, Opera exploite un proxy pour son produit Opera Mini . Le navigateur Opera Mini achemine tout le trafic via le proxy Opera et fait entièrement confiance au certificat présenté par le proxy. Par conséquent, bien que le trafic entre le navigateur et le proxy puisse être chiffré et que le trafic entre le proxy et le serveur Web de contenu puisse être chiffré, Opera a les possibilité de lire toutes les données passant par son proxy.) Enfin, toute personne ayant la possibilité de falsifier le navigateur (par une extension ou un mécanisme de plugin) ou l'éditeur de liens dynamique (en utilisant quelque chose comme LD_PRELOAD) ou la liste de certificats de confiance du navigateur pourrait intercepter également les données, même si à ce stade l'intégrité du client a été si compromise qu'il n'y a aucun espoir de sécurité significative.
Un proxy installé sur la machine cliente peut en effet intercepter un trafic HTTPS décrypté.
Cependant, pour ce faire, il doit placer son propre certificat dans le magasin de certificats racine approuvé. Ce faisant, l'utilisateur sera confronté à plusieurs défis de sécurité, qui ne peuvent pas être facilement contournés. Il est donc peu probable que cette technique soit utilisée par des logiciels malveillants à moins que l'utilisateur ne soit assez idiot pour que cela se produise.
Un excellent exemple de logiciel utilisant cette technique à des fins non néfastes est Fiddler - un outil de débogage HTTP/HTTPS pour les développeurs Web.
Qu'entendez-vous par "système"? Le cryptage devrait se produire dans certaines bibliothèques. Cela peut être considéré comme faisant partie du système à certains égards, et à d'autres égards comme faisant partie du navigateur. (Même le navigateur lui-même fait partie du système, dans le sens où il est installé pour tous les utilisateurs qui partagent l'exécutable.)
La granularité de sécurité est que l'intégralité du navigateur et ses composants sont dans le même contexte de sécurité (par exemple, le processus du système d'exploitation avec son propre espace d'adressage). La cryptographie a lieu dans ce processus.
Pour intercepter les données en clair, le logiciel devrait trouver un moyen de violer le contexte de sécurité du navigateur. Cela est généralement possible dans les systèmes d'exploitation qui n'ont que des politiques de sécurité à granularité grossière, pour le code qui a en quelque sorte acquis des privilèges de superutilisateur.
Par exemple. dans les systèmes d'exploitation de type Unix, nous pouvons utiliser l'appel système ptrace pour attacher à un processus, et faire diverses choses comme suspendre et reprendre son exécution, surveiller les appels système ou examiner/modifier sa mémoire.
Les données entrant dans le navigateur, telles que les frappes que vous entrez dans les formulaires, proviennent d'un autre contexte de sécurité, à savoir celui qui contient le pilote de clavier dans le noyau du système d'exploitation. Cela peut également être attaqué par des programmes privilégiés capables d'accéder aux données transitant par les pilotes.
Cependant, un proxy HTTP/HTTPS (par opposition à un programme superutilisateur malveillant qui jette un œil aux processus) exécuté sur la même machine n'aurait pas accès au trafic en texte brut. Ce qui passe par un proxy est le protocole HTTPS chiffré.