SSL est-il sûr?
Si j'ai obtenu un certificat SSL pour mon site Web et que j'utilise une connexion sécurisée SSL (HTTPS), est-ce suffisamment sûr pour envoyer mes données de connexion et de mot de passe ou dois-je ajouter un chiffrement ou un hachage?
Et dans quelle mesure SSL est-il sûr contre les attaques de Man In The Middle? Peuvent-ils saisir ou même modifier les données envoyées et reçues via HTTPS?
Et qu'en est-il de GET et POST, les deux sont-ils cryptés ou est-ce que la réponse du serveur est cryptée ou même rien?
J'ai lu Wikipédia et beaucoup de résultats Google sur SSL et HTTPS mais je ne comprends pas vraiment. J'espère vraiment que vous pourrez répondre à mes questions de manière simple afin que je puisse enfin comprendre à quel point SSL et HTTPS sont vraiment sûrs.
Principe de fonctionnement HTTPS
Le protocole HTTP est construit sur TCP. TCP garantit que les données seront livrées ou impossibles à livrer (cible non accessible, etc.). Vous ouvrez une connexion TCP et envoyez HTTP messages à travers elle.
Mais TCP ne garantit aucun niveau de sécurité. Par conséquent, une couche intermédiaire nommée SSL est placée entre TCP et HTTP et vous obtenez le soi-disant HTTPS. De cette façon de travail s'appelle le tunneling - vous videz les données dans une extrémité du tunnel (SSL) et les collectez à l'autre. SSL reçoit les messages HTTP, les chiffre, les envoie par-dessus TCP et les déchiffre à nouveau à l'autre extrémité. Le cryptage vous protège contre les écoutes et les attaques MITM transparentes (altération des messages).
Mais SSL ne fournit pas seulement le cryptage, il fournit également l'authentification. Le serveur doit avoir un certificat signé par une autorité de certification bien connue qui prouve son identité. Sans authentification, le cryptage est inutile car une attaque MITM est toujours possible. L'attaquant pourrait vous faire croire qu'il est le serveur auquel vous souhaitez vous connecter. Le chat privé avec le diable n'est pas ce que vous voulez, vous voulez vérifier que le serveur auquel vous vous connectez est bien celui auquel vous souhaitez vous connecter. L'authentification vous protège du MITM.
Points faibles
Alors, où sont les points faibles?
- Points de terminaison d'une connexion sécurisée. Le transfert pourrait être sécurisé, mais qu'en est-il du serveur lui-même? Ou le client? Ils ne le peuvent pas.
- Ne pas utiliser HTTPS. Les utilisateurs peuvent être incités à ne pas utiliser le schéma de différentes manières.
- Autorités de certification non fiables. Ils cassent la partie d'authentification, permettant une attaque MITM.
- Mécanisme de cryptage faible. Les technologies de cryptographie vieillissent de deux manières: de graves failles peuvent être trouvées dans leur conception, conduisant à des attaques beaucoup plus efficaces que la force brute, ou leurs paramètres et la puissance de traitement augmentée en raison de la loi de Moore pourraient permettre une attaque par force brute réalisable.
- Mise en œuvre du programme. Eh bien, si vous spécifiez A et implémentez B, les propriétés de A peuvent ne pas être valables pour B.
Réponses directes
Vous semblez dire que vous avez sécurisé le transfert (en utilisant SSL). Cela ne suffit pas, la sécurité de votre serveur peut être compromise - vous ne devez pas y stocker de mots de passe en texte brut, utiliser leur forme hachée, avec du sel ajouté,…
SSL crypte les données lors de l'envoi et de la réception. Les attaques MITM ne sont pratiquement possibles que si l'attaquant dispose d'un certificat signé par une autorité de confiance du client. Sauf si le client est amené à ne pas utiliser HTTPS, personne ne peut lire ni modifier les messages envoyés.
GET et POST ne sont que deux méthodes pour effectuer une requête HTTP. Il en existe plusieurs autres également. La méthode n'est qu'une propriété de la requête HTTP. Tous les messages sont sécurisés, à la fois les requêtes et les réponses, indépendamment de HTTP méthode utilisée.
SSL protège les données en transit en les chiffrant. Il garantit uniquement à un client que les données parviendront de leur ordinateur à votre serveur sans être interceptées ou modifiées (les données cryptées pourraient être interceptées mais n'ont aucune signification sans décryptage). Cela dit, il est de la responsabilité du client de s'assurer que SSL fonctionne correctement avant d'envoyer des données ou de faire confiance au serveur. Il existe des attaques qui supprimeront SSL de la connexion, mais pas qui intercepteront ou modifieront les données envoyées via une connexion SSL sécurisée.
SSL ne fournit aucune sécurité une fois que les données sont sur le serveur. Il est toujours nécessaire d'utiliser le hachage et le chiffrement côté serveur si vous souhaitez protéger les données au repos contre les violations du serveur lui-même.
HTTPS est HTTP envoyé via une connexion cryptée SSL. Il couvre à la fois GET et POST et toutes les autres actions HTTP car le flux HTTP entier se produit sans être modifié mais est transmis via un tunnel SSL au navigateur client.
SSL sécurise uniquement la connexion entre le client et le serveur. En théorie, il le fait assez bien (ok, il y a des problèmes - mais ils sont mineurs par rapport à tous les autres problèmes :) tant qu'aucune des 150 autorités de certification auxquelles vous faites confiance dans votre navigateur n'est compromise ou fonctionne avec certaines agences et leur donne une autorité de certification intermédiaire pour effectuer des attaques de type homme du milieu.
Et, comme je l'ai dit, il sécurise uniquement la connexion entre le client et le serveur. Ainsi, tous les problèmes dans votre application Web tels que Cross-Site-Scripting, Cross-Site-Request-Forgery, SQL-Injection, Session-ID non sécurisés, etc. fonctionneront pour la plupart, même si la connexion est cryptée. En outre, le serveur peut être compromis, etc.
En résumé, SSL est un peu nécessaire pour sécuriser les données, mais ce n'est pas la seule chose que vous devez faire pour sécuriser les données.
De qui essayez-vous de sécuriser la communication? S'il s'agit du NSA ou de toute autre agence de sécurité au niveau de l'État, la réponse est non: ils ont les ressources et la technologie nécessaires pour mettre en œuvre avec succès des attaques man-in-the-middle contre SSL. Si c'est réseaux criminels à grande échelle, la réponse est toujours non: ils ne peuvent pas compromettre les autorités de certification comme le NSA et al. peuvent, mais ils peuvent facilement compromettre les machines elles-mêmes et jeter un œil à les données sortantes avant et les données entrantes après, le cryptage. Si vous hébergez simplement un serveur, cependant, cela vous inquiète moins, car il est beaucoup plus probable que le compromis se produise sur la machine de l'utilisateur final et que c'est son problème Si ce sont des renifleurs de paquets aléatoires qui tentent de voler et d'exploiter des données, alors oui - et malgré ce qui précède, c'est toujours une menace suffisante que vous devriez utiliser SSL autant que possible.
Un détail important que les autres réponses n'ont pas mentionné est que SSL ne crypte pas l'URL de la demande. Notez que sous le schéma GET, les données sont généralement codées en tant que paramètres dans l'URL. Cela signifie que si vous soumettez un formulaire avec un champ de mot de passe via GET, le mot de passe ne sera PAS crypté.