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

Припущення:

Сервер:

• У мене є сервер Debian Squeeze, маршрутизований у загальнодоступному Інтернеті, зі статичною IPv4 адресою.
• У мене є необмежений доступ для зміни програмного забезпечення на сервері.
• Сервер може слухати на довільних портах, перенастроювати правила брандмауера, в основному немає обмежень щодо того, що сервер може зробити.

Клієнт:

• Я можу запускати Firefox, Java програми, .NET програми та деякі вбудовані файли, які не потребують доступу адміністратора в моїй локальній системі (заблокований робочий стіл Windows без прав адміністратора).
• Я можу встановити Addons у Firefox.
• Я можу слухати будь-який порт localhostінтерфейсу loopback ( ). Отже, вищезгадані програми можуть прив'язуватися до локального порту та виконувати довільну мережу вводу-виводу, не проходячи через проксі.
• Весь відкритий доступ до Інтернету здійснюється за допомогою обмежувального HTTP-проксі, який блокує багато сайтів, і ретельно перевіряє статтю. На порту 80 він дозволяє виключно HTTP (без TLS / SSL). На порту 443 він дозволяє CONNECTбазувати SSL / TLS на віддалених хостах, не заблокованих іменем домену / IP-адресою.
• Обмежуючий HTTP-проксі не здійснює глибокої перевірки пакетів TLS-з'єднань, дозволених через проксі, і він не здійснює атаки Людини в Середньому на ці з'єднання.
• Згаданий вище сервер, до якого я маю доступ, не блокується проксі.

Мета:

Я хочу маршрутизувати всі 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працював би так само добре. Оскільки це прослуховування лише в локальному хості, автентифікація не потрібна (якщо тільки на вашій коробці не запущені процеси, яким ви не довіряєте; в такому випадку, виправляється ...)

3. Завантажте оглушення та встановіть його як на клієнті, так і на сервері. Процес цього має бути специфічним для ОС; у моєму випадку я вирішив компілювати оглушення з джерела (параноїя ...) для Windows, що був досить залученим процесом, який я тут деталізувати не буду. На стороні сервера він був доступний у менеджері пакунків :)

4. Конфігурація Штунеля спочатку була досить грізною, але це простіше, ніж здається! В основному, на сервері вам потрібно щось на кшталт наведеного нижче "stunnel.conf сервера". На клієнті вам потрібно щось на кшталт наведеного нижче "stunnel.conf" клієнта.

5. Старт Privoxy; запустити оглушення на сервері, вказуючи його на конфігураційний файл; запустіть оглушення на клієнті, вказуючи його на конфігураційний файл. У налаштуваннях Privoxy насправді немає нічого особливого; за замовчуванням для мене було добре.

6. У Firefox, вашому браузері за вибором клієнта, встановіть проксі-протокол HTTP та HTTPS таким, як порт, який слухає оглушення вашого клієнта - можливо, це щось на зразок 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(оглушення) і розглядає його як проксі, який може приймати з'єднання HTTP та / або HTTPS.
2. Після того, як stunnel отримує з'єднання з вашого браузера, він простягає через проксі / шлюз вашого брандмауера встановити сеанс TLS з віддаленим сервером. У цей момент ваш клієнт перевіряє сертифікат PKI вашого сервера та навпаки.
3. Після встановлення сеансу TLS з віддаленим сервером, оглушення передає дані, що надходять з вашого браузера, наприклад запит HTTP або тунель SSL, через локальний проксі і безпосередньо на ваш сервер. Цей канал зашифрований, тому ваша локальна мережа не може сказати, що містять дані, вони можуть лише здогадуватися, роблячи аналіз трафіку.
4. Як тільки stunnelекземпляр, що працює на вашому сервері, починає отримувати дані, він відкриває з'єднання, наприклад localhost:8118, де саме прослуховує ваш проксі-сервер HTTP (S), в моєму випадку Privoxy.
5. Потім Privoxy діє як звичайний проксі-сервер HTTP для переадресації та пересилає ваші запити до загальнодоступного Інтернету через Інтернет-провайдер сервера.

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

Я спробував цю установку на своїй локальній машині, і можу запевнити, що "обмежувальний проксі" отримає "a" 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цей файл)

Налаштуйте кальмарів або Apache для того, щоб робити проксі. Оскільки це буде використовуватися через тунель SSH, його потрібно буде слухати лише через інтерфейс зворотного зв'язку. Якщо ви використовуєте Apache:

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

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

На макеті, налаштувати загальнодоступний IP вашого Debian як Hostі 443як порт. Переконайтесь, що SSHвсе-таки вибрано. Перейдіть до Connection -> Proxyналаштувань, виберіть HTTPі заповніть свої "обмежувальні проксі" налаштування. Перейдіть до Connectionналаштувань і встановіть велику кількість 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 на сервері та локальний проксі на клієнті, що використовує шпаклівку для підключення до вашого HTTP-проксі, що підтримується SSL, і встановіть Firefox для проксі-сервера на 127.0.0.1.

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