Как обеспечить безопасное соединение через брандмауэры, используя ненадежный хост?

Question

У меня есть интересная проблема с безопасностью сети, которую я не могу найти наилучшим способом атаки.

Мне нужно предоставить способ, позволяющий двум компьютерам (A и B), которые находятся за брандмауэрами, устанавливать безопасное соединение друг с другом, используя только общий ненадежный сервер-посредник в Интернете (где-то вроде RackSpace). (сервер считается ненадежным, потому что клиенты за брандмауэрами не будут ему доверять, поскольку он находится на открытом сервере) Я не могу настроить параметры брандмауэра, чтобы позволить сетям напрямую соединяться друг с другом, потому что соединения неизвестны заранее время.

Это очень похоже на проблему подключения NAT к NAT, подобную той, которая решается инструментами помощи удаленного рабочего стола (crossloop, copilot и т. Д.).

То, что я действительно хотел бы найти, - это способ открыть SSL-соединение между двумя хостами и иметь соединение с публичным сервером. Предпочтительно, когда хост A пытается подключиться к хосту B, он должен предоставить токен, который брокер может проверить с хостом B перед установлением соединения.

Чтобы добавить еще одну складку, механизм соединения должен поддерживать два типа связи. Во-первых, HTTP-запрос / ответ к веб-службе REST и второе постоянное сокетное соединение (я) для передачи сообщений в режиме реального времени.

Я посмотрел на методы, о которых я знаю, такие как OpenSSL, с использованием сертификатов, OAuth и т. Д., Но я не вижу ничего, что вполне соответствует тому, что мне нужно.

Кто-нибудь еще обращался с чем-то подобным раньше? Есть указатели?

Answer 1

Вы можете решить свою проблему с помощью простого SSL.

Просто используйте недоверенные серверы для прямых соединений между клиентскими хостами в виде непрозрачных TCP-соединений.Затем клиенты устанавливают сквозное SSL-соединение через этот перенаправленный TCP-туннель - с OpenSSL один клиент вызывает SSL_accept(), а другой - SSL_connect().

Используйте сертификаты, возможно, включая клиентские сертификаты, дляубедитесь, что другой конец SSL-соединения соответствует ожидаемому.

(Это концептуально аналогично тому, как HTTPS-соединения работают через веб-прокси - браузер просто говорит «подключите меня к этому месту назначения»)и устанавливает соединение SSL с требуемой конечной точкой. Прокси-сервер просто пересылает зашифрованные данные SSL вперед и назад, и, поскольку у него нет закрытого ключа для правильного сертификата, он не может выдать себя за нужную конечную точку).

Answer 2

Как правило, SSL - это пакетный протокол (для решения вашей задачи). Если вы можете заставить хост пересылать пакеты туда и обратно, вы можете легко иметь защищенный SSL канал связи. Одна вещь, которая вам нужна, это что-то вроде наших компонентов SSL / TLS , которые разрешают любую передачу, а не только сокеты То есть компонент сообщает вашему коду «отправить этот пакет другой стороне» или «у вас есть что-нибудь, что я могу получить?» и ваш код связывается с вашим промежуточным сервером.