SenseUnit / dumbproxy

Dumbest HTTP proxy ever

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Подскажите как добавить сертификаты

military1 opened this issue · comments

commented

Здравствуйте!
Подскажите, пожалуйста, как добавить сертификаты.
Такой вариант не работает:
dumbproxy -cert /etc/letsencrypt/live/xxx/fullchain.pem -key /etc/letsencrypt/live/xxx/privkey.pem
Получаю ошибку:
main.go:80: CRITICAL TLS config construction failed:

Добрый день!

Проверил такой ваш вариант у себя - сработало:

user@mx:~$ ./dumbproxy -cert /etc/letsencrypt/live/vm-0.com/fullchain.pem -key /etc/letsencrypt/live/vm-0.com/privkey.pem
MAIN    : 2020/12/30 10:52:00 main.go:76: INFO     Starting proxy server...

Возможно, у пользователя, под которым Вы запускаете, нет прав на чтение указанных файлов.

commented

Спасибо. Так и оказалось, проблема с правами доступа. Это было при использовании snap версии.
Простите за нубский вопрос, запустил dumbproxy.linux-amd64 с сертификатами, работает. А как, как бы установить приложение? заставить работать при закрытом ssh подключении.

Если это более-менее современная система с systemd, то проще всего так:

  • Поместить исполняемый файл dumbproxy по пути /usr/local/bin/dumbproxy
  • В файл /etc/systemd/system/dumbproxy.service записать следующее содержимое:
[Unit]
Description=Dumbiest HTTP proxy ever

[Service]
User=nobody
ExecStart=/usr/local/bin/dumbproxy -cert /etc/letsencrypt/live/xxx/fullchain.pem -key /etc/letsencrypt/live/xxx/privkey.pem
Restart=always
KillMode=process
TimeoutStartSec=5
TimeoutStopSec=5

[Install]
WantedBy=default.target
  • Выполнить следующие команды:
systemctl daemon-reload
systemctl enable dumbproxy
systemctl restart dumbproxy

Логи смотреть с помощью команды journalctl -u dumbproxy.

commented

Большое спасибо!
Подскажите, пожалуйста, по еще одному вопросу. hidden_domain куда и как добавить? Верно ли я понимаю, что при отсутствии hidden_domain, но при использовании варианта с сертификатами, то прокси и так устойчив к DPI? Я использую порт 443, можно ли рекомендовать использование именно этого порта?

Подскажите, пожалуйста, по еще одному вопросу. hidden_domain куда и как добавить? Верно ли я понимаю, что при отсутствии hidden_domain, но при использовании варианта с сертификатами, то прокси и так устойчив к DPI?

Прокси с TLS устойчив к пассивному DPI.

hidden_domain по сути является некоей защитой от активных проб - чтобы не было видно прокси по ответу с HTTP-кодом 407 Proxy Authentication Required. То есть активная проба в этом смысле - когда проверяющий инициирует собственное подключение к серверу, чтобы посмотреть, что он там отвечает, на что похож. Насколько мне известно, такой тип проб применяется только Великим Китайским Файрволом или особо заинтересовавшимися, вручную. Замечу, что если Вы используете сертификаты публичной инфраструктуры PKI (LetsEncrypt, например) и не ограничиваете клиента доверием только к конкретному УЦ (как это сделано в браузерах по умолчанию), то достаточно влиятельные заинтересованные лица могут и выпустить свой аналогичный сертификат с помощью подконтрольного УЦ для проведения атаки "человек посередине". Не знаю, насколько это вероятно, но если такая угроза стоит - то тогда нужно использовать на сервере сертификат собственного CA, а на клиенте steady-tun, настроенный на доверие только своему CA.

Если к Вам ни то, ни то не относится, то скорее всего достаточно только обычного TLS и пароля, чтобы чужие люди не пользовались вашим прокси. В противном случае есть два варианта:

  1. Использовать авторизацию по паролю и hidden_domain=somehiddendomain.com. В таком случае при использовании прокси в браузере вам придётся сначала переходить на somehiddendomain.com чтобы показалось окно ввода пароля на прокси, и браузер запомнил свою авторизацию. Включить такое поведение можно опцией командной строки -auth 'basicfile://?path=/etc/dumbproxy.htpasswd&hidden_domain=somehiddendomain.com', где /etc/dumbproxy.htpasswd файл с хэшироваными bcrypt логинами паролями в формате htpasswd (как у веб-сервера Apache).
  2. Использовать аутентификацию по клиентским TLS-сертификатам. В браузерах в случае с прокси это не работает достаточно хорошо нативно, поэтому потребуется прослойка на клиенте: steady-tun. В таком случае схема будет такая: браузер подключается к локальному steady-tun как к обычному http-прокси без шифрованиям, а steady-tun идёт уже дальше, авторизуя свои TLS-соединения с помощью клиентского сертификата. Для использования такого метода в командной строке dumbproxy должны быть такие опции -cacert /path/to/client_ca.pem -auth 'cert://'

Документация по возможностям авторизации доступна здесь.

Я использую порт 443, можно ли рекомендовать использование именно этого порта?

Да, самый лучший вариант.