2010-10-20 5 views
5

En raison de la Chine Great Firewall a bloqué le port https de google appengine. Donc, je veux simuler un Secure Socket Layer par javascript et python pour protéger mes informations d'utilisateurs ne seront pas capturées par ces FAI et GFW.Cryptage: simuler SSL en javascript et python

Mon plan:

  • mains Shake:

serveur de requêtes du navigateur, serveur générer un chiffrement k1 clé et décrypter la clé K2, envoyez k1 au navigateur. Le navigateur génère une clé de cryptage k3 et décrypte la clé k4, envoie k3 au serveur.

  • Parcourir:

Au cours de la session, crypter les données du navigateur avec k1 et envoyer au serveur, serveur décrypte une k2. serveur crypter les données avec k3 et la réponse au navigateur, décrypter le navigateur avec k4.

S'il vous plaît comprendre mon erreur.

Si c'est juste, ma question est

  1. comment générer une paire de clés dans javascript et python, sont là des bibliothèques?
  2. comment crypter et décrypter des données dans javascript et python, y a-t-il certaines bibliothèques?

Répondre

0

Il y a un gros problème, si la sécurité est vraiment un gros problème: Votre algorithme va être transféré non sécurisé. Pouvez-vous faire confiance au client? Le client peut-il faire confiance au serveur?

+0

Je pense que l'algorithme opensource est OK, il y a du cryptage, même si vous connaissez la clé de cryptage, mais vous ne pouvez pas le décrypter, et vous ne pouvez pas obtenir la clé de décryptage à partir de la clé de cryptage. –

+1

Non, le problème est ce que dit Marcelo, qu'est-ce qui empêche le mauvais pare-feu de Chine d'être un homme au milieu et de jeter une version complètement non protégée à votre client? Ou en envoyant leurs propres clés publiques (puisqu'ils ont leur clé privée, ils peuvent tout déchiffrer.) Avec SSL vous avez une CA couple ou racine installée à partir de rien, le client les utilise pour s'assurer que la clé publique appartient vraiment à la bonne adresse . Lorsque vous essayez de le faire en javascript, vous ne pouvez plus vérifier votre homologue, et un gros trou de sécurité est ouvert .. – Onkelborg

+0

juste pour mon propre site, pas pour une large utilisation. –

2

Vous avez un problème fondamental dans la mesure où une implémentation JavaScript de SSL n'aurait pas de certificat racine intégré pour établir l'approbation, ce qui rend impossible la prévention d'une attaque de type man-in-the-middle. Tous les certificats que vous fournissez à partir de votre site, y compris un certificat racine, pourraient être interceptés et remplacés par un espion.

Notez qu'il s'agit d'une limitation fondamentale, et non d'une particularité du fonctionnement de SSL. Toute sécurité cryptographique repose sur l'établissement d'un secret partagé. Les certificats racine déployés avec les navigateurs principaux fournissent les points d'entrée à un réseau de confiance établi par les autorités de certification (CA) qui vous permettent d'établir le secret partagé avec un tiers connu. Ces certificats ne sont pas, AFAIK, directement accessibles au code JavaScript. Ils sont uniquement utilisés pour établir des connexions sécurisées (par exemple, https).

+0

Merci. Oui, mon plan est si faible. Mais ce que je veux c'est un peu plus protéger, j'ai été forcé de le faire contre ma volonté. –

+0

Vous ne pouvez pas faire ce que vous voulez sans déployer un secret partagé ou des racines CA via un canal de communication alternatif, ou les déployer via le canal principal et confirmer leur validité via le canal alternatif (par exemple, les certificats ont des empreintes digitales). être lu au téléphone pour confirmation). Sans ceux-ci, il est presque trivial de monter une attaque d'homme-dans-le-milieu, en supposant un accès complet à votre canal de communication. –

1

Vous ne pouvez pas empêcher les hommes au milieu de piéger vos paquets/messages, surtout s'ils ne s'en soucient pas vraiment si vous le savez. Ce que vous pouvez faire est de crypter vos messages de manière à ce que les intercepter ne leur permettent pas de lire ce que vous envoyez et recevez. En théorie, c'est bien, mais en pratique, vous ne pouvez pas faire du crypto moderne à la main, même avec les touches: vous devez aussi transférer un logiciel, et c'est là que ça devient beaucoup plus gênant.

Vous voulez avoir le côté client du logiciel de chiffrement localement, ou au moins assez pour pouvoir vérifier si une signature numérique du logiciel de chiffrement est correcte. Les signatures numériques sont très difficiles à forger.Livrer le code signé, vérifier sa signature, et si la signature valide contre une clé publique en laquelle vous avez confiance (hélas, vous devrez transférer ce hors bande) alors vous savez que le code (plus tous les certificats CA - racines de confiance - envoyé avec lui) peut être fiable pour fonctionner comme vous le souhaitez. Les paquets peuvent ensuite passer par HTTP simple; ils iront là où ils sont destinés ou seront interceptés, mais de toute façon, personne d'autre que le destinataire ne pourra les lire. Le seulement avantage de SSL est qu'il construit virtuellement tout cela pour vous et le rend facile.

Je n'ai aucune idée de comment c'est pratique de le faire tout en Javascript. Évidemment, il peut le faire - c'est un langage de Turing-complet, il a accès à tous les syscalls nécessaires - mais il pourrait être stupidement cher. Il est peut-être plus facile de penser en termes d'utilisation GPG ...

1

Les autres réponses ici sont corrects (Hiding le fait du gouvernement que vous communiquez tout est un problème totalement différent.): Vous avez gagné » t être en mesure de livrer de manière sécurisée le JavaScript qui va être exécuté sur le client. Cependant, si vous voulez juste en savoir plus sur ce sujet, consultez le projet opensource Forge. Il a une implémentation SSL/TLS en JavaScript et un simple serveur SSL Python:

http://github.com/digitalbazaar/forge/blob/master/README

Si vous voulez lire un peu plus sur ses utilisations:

http://digitalbazaar.com/2010/07/20/javascript-tls-1/

http://digitalbazaar.com/2010/07/20/javascript-tls-2/