JavaScript / Flash peut-il vérifier la connexion SSL pour empêcher la "inspection SSL"?
Je voudrais déterminer si une page Web SSL est débogué par Fiddler , ou si elle va à travers un Proxy SSL .
Ainsi, certaines personnes peuvent demander
Quel est le point de revalidation SSL à l'aide javascript?
Mon but est de savoir quand une connexion est soumise à l'interception 3ème partie comme mentionné dans this réponse. La vulnérabilité est que les mots de passe peuvent être exposés, et les sessions utilisateur sont exposés aussi bien. Tout cela est possible lorsque des logiciels malveillants, ou la politique d'entreprise dicte l'interception de SSL et de surveillance.
Que peut-on faire si une connexion SSL est intercepté?
En fonction de la sensibilité de l'application, et si l'authentification à deux facteurs est utilisé, je peux bloquer l'accès programatically connexion ou limite à certaines parties du site. Je peux également placer une notification bannière indiquant le risque de sécurité de l'utilisation de ce kiosque. ... Ou je peux permettre à l'utilisateur d'ajouter une " exception ", ils comprennent les accordai risques.
Ma question :
Javascript peut vérifier les détails du certificat SSL en cours, y compris la chaîne de CA?
Je pense que la bonne façon de procéder est de regarder l'émetteur du certificat, et de regarder le reste de la chaîne de certificats. L'étape suivante serait à la liste à travers chaque cert dans la chaîne et si l'une de ces de CA sont égaux à ce qui sont publiquement confiance de CA racine. Je veux exclure précisément ce que les certificats supplémentaires que l'utilisateur peut avoir s'ajouter à leur ordinateur local.
J'espère que les gens sur security.stackexchange.com offrira des idées sur la façon d'aborder ce sujet.
Si Javascript ne peut pas valider la connexion SSL actuelle, quelles sont les alternatives?
Étant donné que cela peut ou peut ne pas être possible dans une solution pure JavaScript, je tagged cette question avec Flash, car il devrait être en mesure d'y arriver, et envoyer un retour de réponse à Javascript.
Si quelqu'un a Java expérience ME, s'il vous plaît mentionner si cela est possible. Même chose pour tout autre plug largement déployée dans.
Le code source de la technologie concernée est appréciée.
Non - le DOM n'expose pas l'accès au certificat SSL pour la page en cours, tout ce que vous avez accès à IS location.protocol qui vous permet de vérifier si vous êtes livré sur https
Dans le contexte du navigateur Web, il existe deux types de connexions SSL: celles que le navigateur gère, et celles que votre code (soit Java, JavaScript ...) se gère.
Pour le premier type, vous êtes surtout de chance, car le navigateur ne vous donnera pas de détails sur la chaîne de certificats de serveur. Le navigateur vous dit "C'est tout Dandy" mais ne vous donne aucun moyen de vérifier que le navigateur n'est pas égaré.
Pour le deuxième type, cela signifie que votre code ouvrira la connexion au serveur et exécutera la poignée de main SSL complète elle-même. À ce stade, bien sûr, le code sera voir la chaîne de certificat du serveur et pourra le valider de manière arbitraire, qui comprend " Direct Trust "(le code client déjà" connaît déjà "la clé publique du serveur) ou au moins à l'aide d'une racine de racine spécifique et attendue. Cette approche présente plusieurs problèmes pratiques pouvant être traités à un coût:
- Vous devez intégrer une implémentation complète SSL. Ce n'est pas nécessairement énorme, mais cela peut être délicat. Vous pouvez le rendre plus petit car vous contrôlez le code client et du serveur, vous pouvez donc vous concentrer sur la version et les algorithmes de protocole exacts que vous avez l'intention d'utiliser.
- Les performances peuvent être un problème si vous utilisez un interprète sans un compilateur JIT .
- Tout cela n'a aucun sens que si vous pouvez vous assurer que le code client n'a pas été modifié. Il est inutile de vérifier n'importe quoi avec JavaScript sur la connexion SSL via laquelle le code JavaScript a été téléchargé: a Man-in-thidge peut modifier le code JavaScript pour supprimer le chèque.
- L'ouverture d'une connexion RAW au serveur à partir du code client est délicate dans certains réseaux, notamment en ce qui concerne les proxies .
Pour la performance, vous voudrez utiliser Java Me . La plupart Java moi impliquent des interprètes de base afin que cela ne soit pas plus rapide que JavaScript ou Flash, sauf que la norme Java La bibliothèque comprend Java.math.BigInteger, une mise en œuvre d'arithmétiques sur des nombres entiers arbitrairement importants, qui seront généralement mis en œuvre comme code natif, donc très vite. Vous aurez besoin de cela pour les calculs RSA ou DH impliqués par la poignée de main SSL.
Pour vous assurer que le bon code est en cours d'exécution sur le client, là encore Java ME peut venir à la rescousse, car Java moi applets peut être signé . Cela ne résout pas vraiment votre problème, car un attaquant qui peut diriger Fiddler est un attaquant qui pourrait insérer son propre faux ca dans le magasin Trust local; Le même attaquant aurait pu ajouter son propre faux CA à l'autre magasin de fiducie local, celui de validation des certificats de signature d'applet. Pourtant, cela ajoute une belle torsadement: si La connexion client est interceptée, puis, des examens de la criminalisation après-les-facteurs peuvent découvrir l'applet signé en cache, puis Il sera évident que l'applet est faux et vous, en tant que responsable du serveur, n'est pas le méchant. Vous ne pouvez pas avoir ce genre de protection juridique de l'authentification, mais les signatures peuvent aider. Ceci, bien sûr, dépend beaucoup sur le contexte.
Le problème avec les proxies est grave. Beaucoup de réseaux locaux, en particulier de sociétés, ne font pas NAT ; Au lieu de cela, tout le trafic externe doit passer par des proxies. Le navigateur Web de l'utilisateur sait où sont les proxies, mais pas votre code JavaScript ou Java. De plus, les mandataires peuvent nécessiter une authentification, pouvant être liée aux informations d'identification de la session locale; Là encore, le navigateur traverse de manière transparente, pas votre code. Pour faire face à ce type de problème, vous pouvez envisager de tunneler votre trafic SSL via des demandes HTTP, qui seront remises au code HTTP fournies par le cadre. C'est possible (je l'ai fait il y a environ une décennie) mais pas facile.
Pourtant, tout ça sent mal. Les attaques du type que vous parlez de travail que si l'attaquant pouvait percer le modèle de fiducie X.509, par ex. En installant son propre CA rogue comme une CA de confiance dans le système du client. Depuis les mises à jour logicielles du système d'exploitation également Utilisez ce modèle de confiance, il faut supposer que le système client est, à ce moment-là, sous contrôle complet de l'attaquant, à au moins potentiellement. D'une certaine manière, le violoniste n'est pas quelque chose qui est utilisé par des personnes diaboliques, car les conditions qui permettent à Fiddler d'opérer permettent également aux maladies malvoyés d'adopter de la perturbation d'une échelle beaucoup plus large et plus complète.
Ce qui peut être résumé comme suit: vérifier les choses sur les connexions SSL à partir de JavaScript ou Java le code côté client est aussi inutile qu'une belle note sur votre table de séjour, demandant des cambrioleurs potentiels de téléphoner à bien servir la police eux-mêmes.
(Pourrait travailler au Canada, cependant.)
Compte tenu de votre modèle de menace (détecter un proxy que les proxy SSL, mais n'essayent pas d'altérer votre code de chèque), vous pouvez incorporer un code JavaScript dans toutes vos pages qui vérifient le contenu et la compare à une checksum codée en papier calculé par le serveur, Déterminer si la page qui a atteint le client correspond à ce que le serveur envoyé. Cependant, je soupçonne qu'il y a probablement des défis techniques non triviaux ici, et je ne suis pas convaincu que cela vous achète beaucoup (garder à l'esprit qu'un proxy malveillant peut toujours supprimer votre code de contrôle).
Vous pourriez être intéressé à apprendre Suisse et travaillez à l'Université de Washington sur "Tripwires Web" .
Ce n'est pas en contact actuellement (autant que je puisse dire) par n'importe lequel des navigateurs.
Il y a un insecte exceptionnel sur Firefox pour introduire une sorte de support pour cela, mais elle n'a pas été résolue.
Vous pouvez supporter cela en JavaScript à l'aide de OpenSSL compilé avec EMSCRIPTEN Bien que ce lien ne fournit que les os, vous devrez créer la liaison JS à votre application.
Vous pouvez le supporter en Flash en utilisant OpenSSL compilé avec Adobe Alchemy (recherchez-la) mais vous devez refaire le travail du nouveau moteur Flash et OpenSSL.
Aussi loin que Silverlight & .Net Go, j'utiliserais généralement le ServicePointManager pour intercepter des appels pour valider le certificat SSL, mais il semble que cela n'est pas possible dans le SL4.
Il y a un poste à Microsoft Connect à ce sujet, mais Microsoft dit que c'est par conception. Je vais encourager tous ceux qui pensent que cette fonctionnalité devrait être disponible pour les développeurs de Silverlight pour poster une réponse là-bas.