Comment remplacer SSL / TLS?
Je dois créer un site Web pour une ONG (organisation non gouvernementale), et ils ont les options minimales de leur fournisseur, donc ils ne peuvent pas avoir SSL/TLS (à peine seulement HTML/PHP/MySQL/JS)
Les données qui vont de et vers le serveur ne sont pas très sensibles, mais je ne veux pas que leurs mots de passe, nom et adresse soient envoyés clairement sur le web.
J'ai pensé au chiffrement des données à l'intérieur du JavaScript qui appelle les fonctions API avec RSA (je ne suis pas un expert, mais cette bibliothèque semble assez efficace), mais je rouge n article qui déconseille fortement utiliser JavaScript pour la cryptographie (je suis français et je n'ai peut-être pas tout bien compris, mais j'ai compris l'essentiel).
Alors, que dois-je utiliser pour chiffrer les données sur le réseau?
Si JS n'est pas vraiment une mauvaise idée, que puis-je faire pour assurer une sécurité maximale avec la technologie que je peux utiliser sur ce serveur (encore une fois, pas de HTTPS, malheureusement), à part importer la bibliothèque sur mon serveur et ne pas compter sur l’importation d’un serveur différent?
Pas de SSL, pas de sécurité. Les choses dans le monde réel sont rarement simples, mais ici c'est le cas. Cela se voit facilement comme suit: quoi que vous fassiez en Javascript, cela se fera en Javascript envoyé par le serveur . Tout attaquant qui est en mesure de consulter les données peut également les modifier à volonté (par exemple, le moyen le plus simple d'espionner le WiFi est d'exécuter votre propre faux point d'accès, puis vous pouvez naturellement modifier toutes les données au fur et à mesure) ; ainsi, un tel attaquant peut simplement supprimer ou modifier n'importe quelle solution basée sur Javascript que vous pourriez trouver et la désactiver. Ou ajoutez simplement un crochet pour également envoyer le mot de passe en clair comme paramètre supplémentaire.
Maintenant, même si vous pouviez obtenir du "Javascript sûr" sur le navigateur du client, alors vous rencontriez tous les problèmes que le crypto Javascript implique, et qui sont détaillée dans l'article auquel vous accédez. Mais ce n'est qu'une considération secondaire, par rapport à la faille fondamentale expliquée ci-dessus: sans SSL, vous ne pouvez pas vous assurer que ce qui fonctionne sur le navigateur client est votre code.
Essayer de gérer le mot de passe en toute sécurité sur un site Web non SSL revient à essayer d'effectuer une chirurgie cérébrale en toute sécurité avec seulement une cuillère à thé et un pied de biche rouillé. Ne le fais pas. S'il y a des données sensibles qui circulent sur le site Web (par exemple, noms et adresses), vous DEVEZ alors appliquer des mécanismes de protection raisonnables. Si les données ne sont pas sensibles, pourquoi auriez-vous besoin de mots de passe?
À mon humble avis, le générateur de nombres aléatoires est le moindre de vos soucis. Puisque le code pour invoquer l'enception est envoyé en clair, il est trivial pour quelqu'un de MITM l'interaction.
Si le service nécessite le niveau de sécurité fourni par le cryptage et est fourni par un site Web, il DOIT utiliser HTTPS (et idéalement tous les éléments de sécurité associés comme secure + httponly cookies et HSTS).
La seule façon de contourner ce problème serait d'écrire une application HTML5 (où le code est rarement téléchargé) - mais même cela présente des inconvénients importants.
La meilleure solution, comme cela a été dit, est d'obtenir un véritable plan d'hébergement Web qui autorise https. Cela ne devrait pas être trop cher, en fait, il devrait même être possible de trouver un fournisseur gratuit pour fournir cela.
A défaut, quel est votre cas d'utilisation? Il semble que vous ayez à l'esprit un groupe d'utilisateurs défini pour votre site Web. Si tel est le cas et que vous ne proposez pas uniquement un service de notification d'événements par abonnement à des personnes aléatoires sur Internet, envisagez de fournir la base d'une connexion `` sécurisée '' sur un autre canal.
Il me semble qu'obtenir le code sur leur machine par une autre source fiable (poster des CD via snail-mail et les informer par e-mail, simplement envoyer le logiciel en pièce jointe à un e-mail signé numériquement, etc.) vous permet de pré -charger le logiciel avec une clé publique cryptographique.
Vous pouvez ensuite négocier une connexion sécurisée via une méthode de connexion non sécurisée (telle que http) car le code déterminant si le serveur a décrypté de manière satisfaisante les détails chiffrés avec sa clé publique vit sur le client. Il en résulte un flux de données d'application http en "texte clair", avec la ride que les données d'application elles-mêmes sont cryptées.
C'est beaucoup de problèmes et une méthode non standard. Vous rencontrez des problèmes d'implémentation car peu de gens l'auront essayé pour vous conseiller, et de sécurité puisque peu de gens ont vérifié sa fiabilité *.
Le canal alternatif peut lui-même avoir des problèmes de sécurité. Le courrier pourrait-il être intercepté? Les fraudeurs pourraient-ils usurper l'identité de votre organisation et envoyer leur propre version "sécurisée" de votre logiciel? Vos utilisateurs sont-ils suffisamment avertis pour vérifier les signatures numériques des e-mails que vous envoyez? Ce sont toutes des préoccupations que vous devrez considérer et accepter comme des risques ou tenter d'atténuer avec de nouvelles solutions, car vous avez moins de conseils non seulement sur la façon de mettre en œuvre, mais même sur les questions que vous devez poser (vous devrez poser bien plus que ces trois!).
Lorsque vous parlez à la direction d'une ONG, pensez à décrire la situation en ces termes:
- Cette dernière méthode implique un risque important et finira par leur coûter plus de temps à mettre en œuvre que le simple paiement de l'hébergement - le programme doit être mis à jour, surtout si le serveur (ou la paire de clés du serveur) change, et continuellement distribué aux nouveaux utilisateurs après le déploiement initial.
- Ne rien faire du tout et utiliser un mot de passe sur http avec des adresses et des noms (et potentiellement des adresses e-mail) pourrait être un désastre de relations publiques si des informations fuyaient (et ce serait), un risque important. Cela est aggravé par le fait que les gens réutilisent les mots de passe et que votre mauvaise pratique pourrait être liée à des violations ultérieures.
- En tant que tel, vous avez réfléchi à la situation et vous n'allez pas simplement suggérer la solution décrite à l'étape 4 parce que `` tout le monde le fait '' (même si, dans le cas où tout le monde le fait parce que c'est la meilleure pratique, ce n'est guère une mauvaise chose ). Être en mesure de proposer la solution alternative (si compliquée et excessive) décrite dans les étapes 1 et 2 est la preuve que cette diligence raisonnable est menée.
- Sur cette base, l'hébergement https avec un coût continu faible (ou nul) est à la fois l'approche la moins coûteuse ET la moins risquée.
* Jonathan Gray explique pourquoi vous rencontrerez des problèmes de codage d'un système sécurisé dans sa réponse , regardez la section commençant " TLS est aussi un système beaucoup plus intrinsèque "
Remplacez d'abord votre hôte.
Obtenir des certificats SSL est plus facile que jamais grâce aux autorités de certification gratuites. LetsEncrypt , par exemple, offre des certificats de validation de domaine SSL/TLS gratuits de manière automatisée à condition que vous soyez propriétaire du nom de domaine. Il y a plus d'explications dans réponse de StackzOfZtuff sur ses capacités.
Il y a des instructions sur la façon de le configurer sur leur site communautaire avec FAQ et un forum d'aide.
Le problème avec JS est la génération de nombres aléatoires (ce qui est vital pour la sécurité du cryptage moderne). Il existe des bibliothèques existantes qui permettent de résoudre ce problème, mais vous devez vous assurer que la bibliothèque utilise crypto.getRandomValues ainsi que la possibilité de gagner l'entropie à partir des entrées humaines (telles que l'activité de la souris ou du clavier). Cela est particulièrement lourd pour les appareils mobiles, surtout si l'on considère le fait que le matériel lui-même est moins capable de générer des nombres aléatoires sécurisés.
Je voudrais également ajouter un point supplémentaire sur RSA. Vous ne pouvez crypter que de petites quantités de données avec, et la quantité de données est relative à la longueur de clé utilisée. Non seulement cela, mais RSA est lent. Si vous avez besoin d'une quantité décente de données ou faites plusieurs demandes au serveur, je recommande de crypter une clé aléatoire (CSPRNG) avec JS côté client en utilisant la clé publique du serveur, et en utilisant cette clé pour le cryptage symétrique.
Edit: TLS est également un système beaucoup plus intrinsèque qui travaille très dur pour se protéger contre toutes sortes d'attaques. Le seul type d'attaque contre lequel TLS ne protège pas efficacement est une déconnexion forcée. Tout, de l'authentification du serveur à la protection de l'homme du milieu en passant par la protection contre les attaques par relecture, est géré automatiquement par TLS sur une couche qui n'est même pas vue par le programmeur de haut niveau moyen. Dans votre situation, vous signalez que vous ne pouvez pas utiliser les connexions TLS/(SSL) réelles, ce qui est regrettable. Mais je tiens à préciser que je recommande fortement contre toute implémentation personnalisée conçue pour remplacer TLS.
Potentiellement en dernier recours, car cela ne sera pas aussi bon que TLS de bout en bout ... mais vous pourriez peut-être mettre quelque chose comme CloudFlare devant pour avoir au moins TLS à le point de terminaison client?
Une autre option consiste à écrire un plugin de navigateur ou un script Tampermonkey (pour réduire les maux de tête multiplateformes) et à faire livrer le code JS au navigateur. Je mentionne cela uniquement comme une mesure de dernier recours.
L'inconvénient évident est que vos utilisateurs sont limités à utiliser les ordinateurs qui ont déjà le plugin, ou à le télécharger à nouveau chaque fois qu'ils utilisent un nouvel appareil. Il serait également difficile d'utiliser des appareils mobiles avec.