Comment négocier une connexion sécurisée entre les pare-feu en utilisant un hôte non sécurisé?

Question

J'ai un défi de sécurité réseau intéressant que je ne peux pas déterminer la meilleure façon d'attaquer.

Je dois fournir un moyen de permettre à deux ordinateurs (A et B) situés derrière des pare-feu d'établir une connexion sécurisée entre eux en utilisant uniquement un serveur commun "non autorisé" sur Internet (quelque part comme RackSpace). (le serveur est considéré comme non fiable car les clients derrière les pare-feux ne lui feront pas confiance puisqu'il est sur un serveur ouvert) Je ne peux pas ajuster les paramètres du pare-feu pour permettre aux réseaux de se connecter directement car les connexions ne sont pas connues temps. Ceci est très similaire à un problème de connexion NAT vers NAT comme celui traité par les outils d'aide de bureau à distance (crossloop, copilote, etc.).

Ce que je voudrais vraiment trouver est un moyen d'ouvrir une connexion SSL entre les deux hôtes et d'avoir la connexion du serveur public. De préférence, lorsque l'hôte A tente de se connecter à l'hôte B, il doit fournir un jeton que le courtier peut vérifier auprès de l'hôte B avant d'établir la connexion.

Pour ajouter une autre pli à cela, le mécanisme de connexion doit prendre en charge deux types de communication. Tout d'abord, une requête/réponse HTTP à un service Web REST et une deuxième connexion de socket persistante pour permettre le passage de message en temps réel. J'ai examiné les techniques que je connais comme OpenSSL en utilisant des certificats, OAuth, etc, mais je ne vois rien qui fasse exactement ce dont j'ai besoin.

Est-ce que quelqu'un d'autre a déjà manipulé quelque chose comme ça? Des pointeurs?

Answer 1

En général, SSL est un protocole basé sur les paquets (dans le but de résoudre votre tâche). Si vous pouvez faire en sorte que l'hôte transfère les paquets d'avant en arrière, vous pouvez facilement avoir un canal de communication sécurisé par SSL. Une chose dont vous avez besoin est quelque chose comme notre SSL/TLS components, qui permet tout le transport et pas seulement les prises. C'est à dire. le composant dit à votre code "envoyer ce paquet de l'autre côté" ou "avez-vous quelque chose à recevoir?" et votre code communique avec votre serveur intermédiaire.

Answer 2

Vous pouvez résoudre votre problème avec SSL simple.

Il suffit que le serveur non fiable transfère les connexions entre les hôtes clients en tant que connexions TCP opaques. Les clients établissent alors une connexion SSL de bout en bout sur ce tunnel TCP transféré - avec OpenSSL, un client appelle SSL_accept() et les autres appels SSL_connect().

Utilisez des certificats, y compris probablement des certificats clients, pour vérifier que l'autre extrémité de la connexion SSL correspond bien à vos attentes. (Il s'agit d'un concept similaire à la façon dont les connexions HTTPS fonctionnent sur les proxys Web - le navigateur dit simplement «connectez-vous à cette destination» et établit une connexion SSL avec le point de terminaison souhaité. et en avant, et puisqu'il n'a pas la clé privée pour le bon certificat, il ne peut pas emprunter l'identité du point final désiré).