Можно ли использовать Squid в качестве «прокси-сервера завершения TLS» для шифрования TCP-соединений с использованием клиентских сертификатов?

Аннотация

Мне нужно зашифрованное соединение TCP от нескольких клиентов к одному порту через Интернет. Можно ли это реализовать с помощью Squid?

Конкретная ситуация

Мы используем решение для мониторинга и управления клиентами в нашей компании, которое доступно через LAN и VPN. Теперь он должен быть доступен с внешних ноутбуков, которые не используют VPN компании . Сообщение должно быть зашифровано (TLS). При аутентификации клиентов должны использоваться сертификаты клиентов. Связь инициируется клиентами и использует один порт TCP.

Результаты моих исследований

NGINX Plus предлагает эту функцию, но наш администратор предпочитает squid или apache. На вики-сайте squid я обнаружил, что: Feature: HTTPS (HTTP Secure или HTTP over SSL / TLS), где упоминается шифрование TCP. Но я также нашел это предупреждение:

Важно отметить, что протоколы, проходящие через CONNECT, не ограничиваются теми протоколами, которые обычно обрабатывает Squid. Буквально все, что использует двустороннее TCP-соединение, может быть передано через туннель CONNECT. Вот почему списки ACL по умолчанию для Squid начинаются с deny CONNECT! SSL_Ports и поэтому у вас должна быть очень веская причина размещать над ними любой тип разрешающего правила.

Подобный вопрос

Этот вопрос шифрует клиентское соединение с помощью прямого прокси-сервера squid с использованием SSL , но не относится к обратным прокси-серверам / доверенным терминалам TLS.

Что мне нужно знать

У меня есть только базовые знания об этих технологиях, и наш администратор попросил меня об общей целесообразности.

• Можно ли использовать Squid для безопасного шифрования TCP-соединений?
• Можно ли это реализовать с помощью аутентификации с помощью клиентских сертификатов?
• Или его следует использовать только для соединений HTTPS?

Возможно, вашему администратору не нравится, NGINX Plusпотому что он не с открытым исходным кодом и будет принимать другой хорошо поддерживаемый продукт с открытым исходным кодом. Затем попросите его взглянуть на stunnel . Он предназначен именно для ваших нужд.

Процитируем пример stunnel в Википедии (для SMTP, но это вполне подходит для ваших нужд):

Например, можно использовать stunnel для обеспечения безопасного SSL-соединения с существующим SMTP-сервером без поддержки SSL. Предположим, что SMTP-сервер ожидает TCP-соединения через порт 25. Можно настроить stunnel для сопоставления SSL-порта 465 с не-SSL-портом 25. Почтовый клиент подключается через SSL к порту 465. Сетевой трафик от клиента первоначально передается по SSL к stunnel. приложение, которое прозрачно шифрует / дешифрует трафик и перенаправляет незащищенный трафик на порт 25 локально. Почтовый сервер видит почтовый клиент без SSL.

Процесс stunnel может выполняться на том же сервере или на другом сервере, чем незащищенное почтовое приложение; однако обе машины обычно находятся за брандмауэром в защищенной внутренней сети (так что злоумышленник не может установить собственное незащищенное соединение напрямую с портом 25).

CONNECT используется только HTTP-клиентами для HTTP-прокси для установки туннеля через прокси. В HTTP нет схемы для зашифрованного соединения с HTTP-прокси.

Я подозреваю, что HTTP-прокси это не то, что вы ищете здесь.

Я не знаю, поддерживает ли Squid TCP-плагины с TLS и клиентскими сертификатами, но WinGate поддерживает. У этого также есть возможность проверить UserPrincipalName в сертификате к Active Directory.

Отказ от ответственности: я работаю на Qbik, которые являются авторами WinGate.