Перенаправить ВСЕ веб-трафик через TLS без VPN

Предположения:

Сервер:

• У меня есть сервер Debian Squeeze, маршрутизируемый в общедоступном Интернете, со статическим IPv4-адресом.
• У меня есть неограниченный доступ для изменения программного обеспечения на сервере.
• Сервер может прослушивать произвольные порты, переконфигурировать правила брандмауэра, в основном нет никаких ограничений на то, что сервер может сделать.

Клиент:

• Я могу запускать Firefox, Java-программы, .NET-программы и некоторые собственные исполняемые файлы, которым не требуется доступ администратора в моей локальной системе (заблокированный рабочий стол Windows без прав администратора).
• Я могу установить дополнения в Firefox.
• Я могу слушать на любом порту localhostинтерфейса loopback ( ). Таким образом, вышеупомянутые программы могут связываться с локальным портом и выполнять произвольный сетевой ввод-вывод, не проходя через прокси.
• Весь общедоступный доступ в Интернет направляется через ограничивающий прокси-сервер HTTP, который блокирует многие сайты и тщательно проверяет состояние. На порте 80 он разрешает исключительно HTTP (без TLS / SSL). На порте 443 он позволяет на CONNECTоснове SSL / TLS удаленным хостам, которые не заблокированы доменным именем / IP-адресом.
• Ограничительный прокси-сервер HTTP не выполняет глубокую проверку пакетов соединений TLS, которые разрешены через прокси-сервер, и не выполняет атаки Man in Middle на эти соединения.
• Вышеупомянутый сервер, к которому у меня есть доступ, не заблокирован прокси.

Цель:

Я хочу направить все запросы HTTP и HTTPS, отправленные Firefox, через вышеуказанный сервер через SSL / TLS.

Другие заметки о «Голе»:

• Даже если сайт конечной точки (например, http://superuser.com) не использует SSL / TLS для моего сервера, я все же хочу использовать SSL / TLS от моего клиента до моего сервера , и чтобы мой сервер выполнял HTTP-запрос - зашифрованный или нет - - в желаемое место назначения.
• Мне все равно, если мой сервер смотрит на трафик SSL "в открытом виде". Другими словами, я не требую полного сквозного шифрования SSL от моего локального клиента, вплоть до удаленного сервера, если к удаленному серверу обращаются, например, через https://google.com. Другими словами, я доверяю серверу для обеспечения конфиденциальности моих данных.
• Я готов установить любое программное обеспечение или дополнения Firefox, которые не требуют прав администратора и могут работать на 32-битной Windows 7.
• Программное обеспечение с открытым исходным кодом предпочтительнее проприетарного, и бесплатное программное обеспечение предпочтительнее программного обеспечения, требующего лицензионного сбора.
• Существующее программное обеспечение предпочтительнее, чем кодирование нового программного обеспечения, хотя я готов написать код, если это единственный способ.

Я ищу свободно описанное «решение», которое описывает:

• Какое программное обеспечение потребуется клиенту? Если вам известен конкретный пакет программного обеспечения, назовите его; в противном случае опишите, что клиентское программное обеспечение должно было бы делать .
• Какое программное обеспечение потребуется на сервере? Если вам известен конкретный пакет программного обеспечения, назовите его; в противном случае опишите, что должно делать серверное программное обеспечение .
• Если вы назвали конкретные программные пакеты выше, опишите, какие параметры конфигурации были бы необходимы для его настройки в соответствии с моей целью.
• Если по какой-то причине вы считаете, что это невозможно , опишите почему .

Вещи, которые я пробовал, которые не работают

• Устанавливая squidна своем сервере, я попытался настроить собственный HTTP-прокси на своем сервере. Это не сработало, потому что когда я запрашиваю сайты в Firefox по обычному HTTP, Firefox пытается получить доступ к моему серверу также по обычному HTTP! Это неприемлемо, потому что прокси в моей локальной сети может, конечно, наблюдать и / или блокировать обычный HTTP-трафик между моим клиентом и сервером.
• VPN не работают , даже OpenVPN через TLS, прослушивающий порт 443, потому что у меня нет прав на локальном компьютере для установки tunсетевого адаптера, который может выполнять маршрутизацию уровня 3, и я не могу выполнить какую-либо маршрутизацию уровня 2 (например tap). Короче говоря: мне понадобятся права администратора для установки OpenVPN, и даже если бы у меня были эти права администратора временно, компания не слишком обрадовалась бы, если бы обнаружила, что она установлена. Программа на Java или .NET гораздо менее заметна, особенно если она не установлена ​​в «Установка и удаление программ» и не имеет компонента драйвера ядра, как в OpenVPN.

Я понял. : D Это решение удовлетворяет всем моим требованиям и полностью отвечает всем моим целям. Производительность тоже не так уж плоха, учитывая уровень косвенности, который необходим для достижения этой цели.

Общий подход таков:

1. Установите локальный центр сертификации (CA) и сгенерируйте RSA «ключ сервера» и «ключ клиента» (я использовал 256-битное шифрование). Для этого я использовал Easy-RSA версии 3.0.0-rc2.

2. Запустите любой стандартный HTTP-прокси в «Debian Box» (сервер в общедоступном Интернете), убедившись, что он прослушивает только локальный хост (он НЕ должен быть открыт для общедоступного Интернета). Для своих целей я использовал Privoxy, но Squidработал бы так же хорошо. Поскольку он прослушивает только локальный хост, аутентификация не требуется (если только на вашем компьютере не запущены процессы, которым вы не доверяете; в этом случае yikes ...)

3. Загрузите stunnel и установите его как на клиенте, так и на сервере. Процесс для этого будет зависеть от ОС; в моем случае я решил скомпилировать stunnel из исходного кода (паранойя ...) для Windows, что было довольно сложным процессом, который я не буду здесь подробно описывать. На стороне сервера это было доступно в диспетчере пакетов :)

4. Поначалу конфигурация Stunnel была довольно сложной, но она проще, чем кажется! По сути, на сервере вам нужно что-то вроде ниже "server's stunnel.conf". На клиенте вам нужно что-то вроде ниже "client's stunnel.conf".

5. Запустите Privoxy; запустить stunnel на сервере, указав его в файле конфигурации; запустить stunnel на клиенте, указав его в файле конфигурации. В конфигурации Privoxy нет ничего особенного; по умолчанию для меня это было хорошо.

6. В Firefox, выбранном вами клиентском браузере, установите прокси-сервер HTTP и HTTPS таким же, как порт, который прослушивает stunnel вашего клиента - вероятно, что-то вроде localhost: 8080.

Я должен, вероятно, заметить, что если прокси вашей локальной сети требует какой-то аутентификации, вам придется либо получить для аутентификации stunnel, либо использовать другой локальный перехватывающий прокси и связать их вместе - что-то вроде Firefox -> stunnel -> local проверка подлинности прокси -> прокси / шлюз локальной сети -> интернет -> стойка вашего сервера -> privoxy.

Это много копирует, но это работает!

;This is the *client's* stunnel.conf.
[https]
accept = localhost:9020
connect = your.lan.proxy:80
client = yes
protocol = connect
;protocolHost should be the same as the "accept" for the server
protocolHost = 1.2.3.4:443
;Same CAfile, different cert and key pair
CAfile = ca.crt
cert = client.crt
key = client.key
;VERY IMPORTANT!!! Make sure it's really your server and not a MITM attempt by your local network by making sure that the certificate authority "ca.crt" really signed the server's cert
verify = 2
;More performance tweaks...
sessionCachetimeout = 600
sessionCacheSize = 200
TIMEOUTidle = 600

,

;This is the *server's* stunnel.conf.
[https]
;1.2.3.4 is a publicly-routable, static IP address that can be connected to by your box that's under the firewall
accept = 1.2.3.4:443
;localhost:8118 is an example of where your local forwarding HTTP(S) proxy might reside.
connect = localhost:8118
CAfile = ca.crt
cert = server.crt
key = server.key
;VERY IMPORTANT!!! Without this, anyone in the world can use your public stunnel port as an open proxy!
verify = 2
;Set some timeouts higher for performance reasons
sessionCacheTimeout = 600
sessionCacheSize = 200
TIMEOUTidle = 600

Как только все настроено, конечный результат выглядит примерно так:

1. Ваш веб-браузер подключается к localhost:9020(stunnel) и обрабатывает его как прокси, который может принимать соединения HTTP и / или HTTPS.
2. Как только stunnel получает соединение с вашим браузером, через прокси / шлюз вашего брандмауэра он устанавливает сеанс TLS с вашим удаленным сервером. На этом этапе ваш клиент проверяет сертификат PKI вашего сервера, и наоборот.
3. Как только сеанс TLS установлен с вашим удаленным сервером, stunnel передает данные, поступающие из вашего браузера, например HTTP-запрос или запрос туннеля SSL, через локальный прокси-сервер и напрямую на ваш сервер. Этот канал зашифрован, поэтому ваша локальная сеть не может определить, что содержат данные, они могут только догадываться, выполняя анализ трафика.
4. Как только stunnelэкземпляр, запущенный на вашем сервере, начинает получать данные, он открывает соединение, например localhost:8118, с тем местом , где ваш HTTP (S) прокси-сервер, в моем случае Privoxy, прослушивает.
5. Затем Privoxy действует как обычный прокси-сервер HTTP и пересылает ваши запросы в общедоступный Интернет через интернет-провайдера.

Количество задействованных сокетов и буферов делает этот метод очень дорогостоящим, особенно если вы вкладываете SSL-соединение через прокси, но у него есть преимущество в том, что ваша локальная сеть не имеет возможности узнать, какие сайты вы посещаете через SSL. Я имею в виду, он знает, что вы посещаете свой сервер, но кроме этого, он не знает, посещаете ли вы Gmail или SuperUser или что-то еще. И ваш локальный шлюз не имеет возможности фильтровать или блокировать вас.

Я пробовал эту настройку на своем локальном компьютере, и я могу заверить, что «ограничительный прокси» получит CONNECT DEBIAN_IP:443 HTTP/1.1, но он не увидит никакого сертификата, поэтому я не уверен, будет ли это работать.

Давайте предположим: ваш Debian имеет Apacheили Squidвыполняет прокси- сервер и SSH-сервер. На вашем клиентском ПК вам нужна puttyпрограмма, которая не требует прав администратора для запуска, не требует установки и может запускаться с pendrive.

Сначала ваш Debian:

Сделайте ваш SSH прослушивает порт 443, просто добавьте (или заменить текущий порт) а Port 443на /etc/ssh/sshd_configа также позволяют TCP переадресацию (добавить AllowTcpForwarding yesв этот файл)

Настройте свой Squid или Apache для прокси. Поскольку это будет использоваться через туннель SSH, ему нужно будет только прослушивать интерфейс обратной связи. Если вы используете Apache:

Listen 127.0.0.1:8080
ProxyRequests On
<Proxy *>
  Order deny,allow
</Proxy>

Сервер готов, давайте настроим ваш клиентский ПК:

На putty настройте публичный IP вашего Debian как Hostи 443как порт. Убедитесь, что SSHвсе еще выбрано. Измените Connection -> Proxyнастройки, выберите HTTPи заполните настройки «ограниченного прокси». Изменение в Connectionнастройках и укрепите на KeepAlive из 30- 60. Изменить на Connection -> SSH -> Tunnels. На source portукрепите 8080, и Destination, localhost:8080. Оставьте Localвыбранным и нажмите Add. Вы должны увидеть в пространстве над чем-то вроде L8080 locahost:8080. Вернитесь к Sessionнастройкам, запишите имя в первый ряд Saved sessionsи сохраните все эти утомительные настройки, чтобы помочь восстановить соединение в последующие дни.

Теперь вы можете попробовать Openподключиться к вашему Debian. Если вы видите приглашение пользователя, мы всего лишь в шаге от этого. Если нет ... нам придется искать другой путь.

Теперь в Firefox установите localhostв 8080качестве вашего прокси порт .

Вы на полпути с настройкой прокси на вашем сервере. Другая половина - это SSL на сервере и локальный прокси на клиенте, использующий putty для подключения к вашему HTTP-прокси с поддержкой SSL, и установите Firefox для прокси всего на 127.0.0.1.

Я просто сделал быстрый Google для установки замазки и нашел это: https://mariobrandt.de/archives/technik/ssh-tunnel-bypassing-transparent-proxy-using-apache-170/