HTTPS arrière; L'utilisateur communique avec la clé privée précédemment générée

Question

Je cherche quelque chose comme https, mais en arrière. L'utilisateur génère sa propre clé privée (à l'avance) puis (seulement plus tard) fournit l'application Web avec la clé publique associée. Cette partie de l'échange devrait (si nécessaire) se produire hors-bande. La communication est ensuite cryptée/décryptée avec ces clés. J'ai pensé à quelques approches JavaScript étranges pour implémenter ceci (Du point de vue du client: les soumissions de formulaire sont cryptées à la sortie tandis que le contenu web (sur la réponse ajax) est décrypté. Mais je me demandais s'il existait déjà quelque chose ... quelque chose de communément implémenté dans les navigateurs et les serveurs Web/d'application.) J'ai récemment recréé un mot de passe gmail en texte clair. que seulement moi un d quelques autres utilisent, mais où la sécurité (d'un point de vue d'apprentissage) doit être de premier ordre.

Je dois ajouter, la solution n'a pas besoin d'être pratique

De plus, s'il y a quelque chose d'intrinsèquement mauvais avec mon processus de pensée, je serais très heureux si quelqu'un m'a mis sur la bonne voie ou dirigé moi à la littérature appropriée. La science ne consiste pas à trouver de meilleures réponses; la science consiste à former de meilleures questions.

Merci pour votre temps, O∴D

Answer 1

Ceci est déjà fait. Ils s'appellent des certificats clients TLS. SSL ne doit pas être à sens unique; il peut s'agir d'une authentification mutuelle à deux parties.

Ce que vous faites est que le client génère une clé privée. Le client envoie ensuite une requête CSR (Certificate Signing Request) au serveur, qui signe la clé publique et la renvoie au client. La clé privée n'est jamais envoyée sur le réseau. Si l'AP intercepte et modifie la clé, le client le saura.

Cependant, cela ne pas arrêter un point d'accès non autorisé de demander un certificat pour le compte d'un client. Vous avez besoin d'un canal hors bande pour vérifier l'identité. Il est aucun moyen pour empêcher un homme au milieu d'imiter un client sans un moyen de contourner ce MITM.

Answer 2

Si un point d'accès non autorisé peut renifler les paquets, il peut aussi changer les paquets (un « actif » man-in-the-middle). Donc toute mesure de sécurité qu'un script côté client pourrait éventuellement fournir serait facilement contournée en nobbling le script lui-même sur le chemin du client. HTTPS - et l'avertissement de certificat non autorisé que vous recevez lorsqu'un MitM essaie de vous tromper - est aussi bon qu'il obtient.

Answer 3

SSL et là pour HTTPS permet des certificats clients. côté serveur, vous pouvez utiliser these environment variables pour vérifier un certificat. Si vous avez seulement 1 serveur et un groupe de clients alors une PKI complète n'est pas nécessaire. Au lieu de cela, vous pouvez avoir une liste de certificats clients valides dans la base de données. Here est plus d'informations sur le sujet. Implémenter quoi que ce soit de ce genre dans JavaScript est une mauvaise idée.

Answer 4

Je ne vois pas, pourquoi vous utilisez le cryptage asymétrique ici. Pour l'un, c'est lent, et d'autre part, il est vulnérable à l'homme au milieu de toute façon.
Habituellement, vous utilisez un cryptage asymétrique pour avoir une négociation de session relativement sécurisée, y compris un échange de clés pour un cryptage symétrique, valable pour la session.

Comme vous utilisez un canal sécurisé pour la négociation, je ne comprends pas vraiment pourquoi vous envoyez même des clés publiques, qui ne sont valables que pour une session.
Le chiffrement asymétrique a du sens, si vous avez un secret partagé, qui permet de vérifier une clé publique. Avoir ce secret partagé est nettement plus facile, si vous ne changez pas la clé pour chaque session, et si la clé est générée dans un endroit central (c'est-à-dire le serveur et non pour tous les clients).

Aussi, comme l'a déjà souligné la tour, JavaScript est une mauvaise idée. Vous devez tout écrire à partir de zéro, en commençant par les opérations arithmétiques de base, puisque Number ne vous mènera pas très loin, si vous voulez travailler avec des clés d'un ordre de grandeur, cela fournit une sécurité raisonnable.

greetz
back2dos