Je ne suis pas sûr que vous en ayez conscience ou non, mais ce que vous faites est une attaque de l'homme du milieu sur www.backendsite.com.
Pour comprendre pourquoi cela ne peut pas fonctionner dans votre scénario, nous devons expliquer le rôle réel des certificats et des clés dans TLS. Alors, c'est parti.
Tout d'abord, nous devons établir une clé en clair. Nous n'avons pas et pour des raisons d'efficacité ne pouvons pas avoir de canal sécurisé, alors nous utilisons Diffie Hellman comme protocole d'échange de clés. Nous aurions pu établir auparavant des paramètres que nous utilisons. La pensée moderne dit que c'est une mauvaise idée, inventons en au fur et à mesure. Cela s'appelle DHE (Diffie Hellman éphémère). Si vous vous sentez vraiment chic, vous pourriez le faire avec EC (EC-DHE).
Maintenant, la question est, comment savez-vous que je vous ai envoyé les paramètres que j'ai envoyés, en utilisant DH? Pour vérifier cela, nous avons besoin d'un algorithme de signature numérique afin que vous ayez des informations publiques sur moi pour vérifier que la signature faite avec ma clé privée ne peut être faite que par moi.
Le matériel de clé du serveur fournit cela pour le serveur - une clé privée et une clé publique (contenue dans le certificat, avec des signatures par l'AC disant oui, nous faisons confiance à cela aussi).
NORMALEMENT, le client peut simplement générer une paire de clés publique/privée pour des connexions anonymes comme il le souhaite. Donc en temps normal:
- Le client a une paire de clés quelconque.
- Elle établit une connexion fonctionnelle avec votre proxy. Le trafic est crypté/décrypté sur ce tunnel.
- Le proxy a sa propre paire de clés "quelconque" avec laquelle il établit une connexion avec le serveur.
- Le serveur se moque peu de qui est le client, il établira une connexion avec n'importe qui, donc il utilise la clé publique de votre proxy.
- La session est établie.
Cependant, maintenant le client fournit une paire de clés spécifique. Cette paire de clés est utilisée pour protéger les paramètres du protocole, voici ce qui se passe :
-
Le client a une paire de clés spécifique, demande TLS et envoie ses paramètres et sa clé publique.
-
Le proxy déchiffre et peut repaqueter de deux manières (je ne sais pas laquelle de ces méthodes se produira en réalité - cela dépend de l'implémentation - j'explique simplement pourquoi cela ne peut pas fonctionner) :
-
Il fournit le certificat public du client au lieu du sien. N'ayant pas la clé privée, il est incapable de déchiffrer les réponses de la session.
-
Il se fâche (encore une fois ce n'est pas ce qui se passe réellement, juste une illustration) et génère ses propres certificats. Cependant, le serveur ne parlera pas à des certificats autres que ceux remplissant certains critères (par exemple, signés par un certificat connu) et donc refuse de négocier la connexion.
La raison pour laquelle cela ne fonctionne pas tout à fait est que nginx essaie d'agir en tant que proxy http, enlevant et réappliquant https si nécessaire, et avec des certificats de confiance établis des deux côtés, TLS empêche intentionnellement les attaques MITM.
Il y a des alternatives que les ingénieurs peuvent prendre lorsque le backend est sous leur contrôle. Je me suis retrouvé ici parce que je voulais rediriger vers un socket unix en transmettant certaines informations de certificat. Cela peut être fait en utilisant ces notes sur l'authentification des certificats avec nginx et cette observation sur les en-têtes HTTP (ne pas transmettre le certificat brut entier).
