Пишем PROXY-SERVER / Сетевые технологии / Сеть
Введение
Было время, когда мне нужно было написать простейшей одноконнектовый прокси, даже без интерфейса, но состоящий из двух половинок, которые соединяются протоколом SPX, а не TCP. Я столкнулся с тем, что в том небольшом количестве примеров работы с WinSock, что у меня были, было столько ненужного мне мусора, что это затрудняло понимание самого принципа. А примеров организации многоконнектовости у меня вообще не было. Поэтому в данной статье я постараюсь как можно проще объяснить принцип работы прокси, но я не буду объяснять все с нуля. Если вы хотите понять принцип работы асинхронных неблокирующих сокетов в Windows и их отличия от стандартных синхронных, для начала прочтите документ «Синхронные и асинхронные сокеты в Windows». А если вы вообще не знакомы с сетевым программированием, отложите не надолго эту статью и постигните основы. Здесь же я расскажу только о том, что действительно может быть непонятным читателю. В качестве примера рассмотрим программу, организующую прослушивание сокета и осуществляющую перенаправление данных на указанный IP:PORT. Правильнее было бы назвать это чем-то вроде «port map» или «port redirect».
Для начала определимся с константами.
Объявим глобальные переменные.
А теперь рассмотрим функцию соединения с прокси.
Warning!
Итак, я показал основные функции прокси. Я специально в первом варианте не добавлял код для проверки ошибок, дабы упростить ядро и позволить проще понять принципы. Теперь я расскажу о тех проблемах, которые есть у нашего прокси.
Код программы. Скачать можно здесь. (Скачано 5320 раз)
Ну что, вы разобрались и готовы к реализации полноценной программы? Тогда заходите сервер UInC в раздел проектов (или на kmint21.com). Там вы найдете пример полнофункциональной реализации такого port-mapper-а. В нем вы увидите обработку всех ошибок, ведение лога, обработку командной строки и многое другое.Попутно замечу, что его размер 5 Kb! А о том, как писать такие маленькие программы, вы можете прочитать в статье «Написание экстра-маленьких Win32 приложений на С++»
(c) Copyright 2001. Украина, Запорожье. KMiNT21 (mailto:kmint21@mail.ru).
uinC Member
[c]uinC
Статья написана специально для UInC (www.uinc.ru).
Любые комментарии, поправки, пожелания или дополнения можно посылать сюда: kmint21@mail.ru
Все документы и программы на этом сайте собраны ТОЛЬКО для образовательных целей, мы не отвечаем ни за какие последствия, которые имели место как следствие использования этих материалов\программ. Вы используете все вышеперечисленное на свой страх и риск.
Любые материалы с этого сайта не могут быть скопированы без разрешения автора или администрации.
Создаем прокси-сервер (socks)
Если вам нужен прокси, то ниже вы найдёте, по моему мнению, лучший способ создания прокси. Для чего нужен прокси-сервер? Очень просто, вот несколько возможных ответов на этот вопрос:
1. Представьте, что вы сидите в отеле или в кафе с бесплатным WiFi. Где гарантия, что WiFi не развёрнут мошенниками, которые ждут, пока какой-нибудь лох начнёт передавать через WiFi данные своей банковской карты или вводить логины и пароли к своим личным страницам. Здесь есть два пути, либо не пользоваться бесплатным WiFi для работы и покупок, либо пользоваться прокси, с помощью которого данные будут передаваться в зашифрованном виде.
2. Сокрытие своего настоящего IP-адреса. Иногда это бывает нужно для соблюдения анонимности.
3. Вы получили бан поисковой системы из-за частого обращения. Например, если Яндекс часто спрашивает, робот вы или человек.
Существует 2 варианта найти прокси-сервер: найти услугу (платную или бесплатную) или создать собственный прокси-сервер. Здесь не будем рассматривать первый вариант, т.к. нет гарантии, что на сервере не пишется лог (вероятность потери личных данных, данные банковских карт, логины и пароли). Ниже рассмотрим второй вариант: создание своего прокси-сервера.
1. Находим хостинг с поддержкой SSH
Если вы веб-мастер, то, возможно, у вас уже есть хостинг с поддержкой SSH. Если нет, то поищите в Интернете недорогой хостинг поддерживающий SSH. Встречаются хостинг-провайдеры, которые готовы предложить нужный нам хостинг за примерно за 1 доллар в месяц. Можно найти и заграничный хостинг, но это будет чуть дороже. Если поискать получше, то можно найти бесплатные варианты, но, думаю, платные будут работать надёжнее.
2. Запускаем программу PuTTY
После того как вы обзавелись хостингом с SSH, вам нужна программа PuTTY для создания локального прокси-сервера. Скачать программу бесплатно можно с официального сайта программы: www.putty.org.
3. Настраиваем программу PuTTY
После запуска программы вы увидите окно с настройками. В поле Host Name введите адрес домена или IP-адрес вашего сервера. В поле Port укажите порт, обычно это 22.
Чтобы при каждом запуске не делать эту длительную процедуру, нужно сохранить текущие настройки. Для этого вернитесь в категорию Session, введите имя для своих настроек в поле Saved Sessions, например, «myhost.ru proxy» и нажмите на кнопку Save. После этого ваши настройки появятся в списке ниже. Теперь, при следующем запуске программы, вы сможете выбрать свои настройки в этом списке и нажать на кнопку Load.
4. Открываем сессию
После настройки программы можно открыть сессию. При этом будет создан локальный прокси-сервер. Для этого щёлкаем по кнопке Open.
Если вы подключаетесь к серверу первый раз, то программа PuTTY оповестит вас о том, что у неё нет информации об этом сервере. Настоятельно рекомендую первый раз подключаться к вашему серверу через надёжную известную сеть, в этом случае нажмите на кнопку Да. Если вы увидите такое сообщение при подключении через неизвестную бесплатную точку доступа, лучше не продолжать подключение и нажать кнопку Отмена.
5. Прокси-сервер готов!
После того как вы ввели логин и пароль, на экране появится информация о сервере, а ваш прокси будет доступен по адресу 127.0.0.1:8888 или localhost:8888. По окончании работы чёрное окно программы PuTTY можно закрыть, согласившись с предупреждением.
6. Настройка браузера и других программ
В меню выберите пункт «Свойства браузера».
В появившемся окне выберите закладку «Подключения» и на ней нажмите на кнопку «Настройка сети».
В окне «Настройка параметров локальной сети» поставьте галку «Использовать прокси-сервер. » (в дальнейшем, чтобы быстро включать и выключать прокси, можно просто снимать или устанавливать эту галку ) и нажмите на кнопку «Дополнительно».
В окне «Параметры прокси-сервера» укажите только пункт 4. Остальные поля очистите, чтобы браузер не путался.
Теперь закройте все окна, нажимая на кнопки «ОК». Ваш браузер готов к работе через прокси.
Локальный прокси-сервер для фильтрации браузерного трафика
Хочу рассказать о процессе разработки и поделиться прокси-сервером, которым сам пользуюсь для фильтрации всяческого мусора и других задач, требующих просмотра или вмешательства в браузерный траффик. Возможно, аналогичный функционал уже где-то есть, но мне хотелось сделать конкретно под свои нужды с возможностью real-time дописывания кода под любую сиюминутно понадобившуюся мелочь. Ну и под не-мелочи тоже, но это уже дольше.
Первоначально была задача упростить посещение сайтов через медленное (около 5-10кбайт/с с лагами) подключение. Тут два основных направления: 1) вырезать всё что не нужно (в первую очередь рекламу), и 2) закешировать всё что можно закешировать без особого вреда для функционала посещаемых сайтов, даже когда сами сайты не разрешают кеширование в http-заголовках, а то и явно препятствуют ему, дописывая после урлов статических файлов знак вопроса с рандомным числом.
Предупреждение: реализация, описанная ниже, делалась для Linux-а, вроде бы работает на других *nix, но даже компиляция её на винде не рассматривалась (хотя возможность адаптировать, конечно, есть).
Черновой вариант: nginx + php-fpm
Тратить на всё это время не хотелось, поэтому было решено по-быстрому настроить связку nginx + php-fpm, из которых первый разбирал входящие подключения, включая https и перенаправлял их все, без разбора хостов и урлов, в один и тот же php-скрипт. Так же была маленькая программа на C, которая конвертировала http-proxy-протокол в обычный http(s)-трафик. То есть превращала запросы GET http://host/path HTTP/1.x в GET /path HTTP/1.x (имя хоста всё равно есть в Host-заголовке) и проксировала все https CONNECT’ы на локальный nginx. Как потом выяснилось, убирать http://host из http-запросов было не обязательно, nginx их принимает так же как и обычные.
PHP-скрипт, в свою очередь, собирал назад разложенный по разным переменным запрос, через fsockopen() подключался к целевому серверу (благо там поддержка SSL встроенная), слал собранный http-запрос, забирал ответ и отправлял его браузеру с помощью header() и echo. Скрипт делался не совсем с нуля, спасибо некоей Évelyne Lachance за https://github.com/eslachance/php-transparent-proxy (но всё же то, что по ссылке, имеет несколько другую цель и поэтому просто скопировать его было нельзя).
Во-вторых, nginx не умеет генерить сертификаты на лету из коробки, а настройку «игнорировать все проблемы с сертификатами» я в firefox не нашёл. Проблема была на тот момент решена патчем браузера, заставлявшим его любой сертификат считать доверенным и подходящим. Наверно были и другие способы это сделать, но все они казались сложнее. Патч естественно был кривой и сделанный почти методом тыка (желания изучать весь браузерный код проверки сертификатов не было), но он делал своё дело, а больше было и не надо.
Между сборкой исходного запроса и отправкой проксированного тривиальным образом были добавлены два куска кода. Один проверял, что host или host/path не из чёрного списка (организованного в виде отдельного php-файла с массивом внутри). Второй проверял, нет ли страницы в кеше (если есть — отдаётся из кеша). Если страницы в кеше нет, то делается проксированный запрос. Если запрос был GET и статус ответа 200, то полученная страница — кандидат на запоминание в кеше. Запоминать или нет — решалось функцией, которая по хосту, урлу (там просто были прописаны конкретные адреса, которые меня интересовали и которые я знал что надо кешировать) и content-type выносила вердикт. Кешировалось немного: http-статус, content-type и тело ответа. И при отдаче из кеша, соответственно, отдавались только эти данные, а все остальные заголовки, которые были в исходном ответе, безвозвратно терялись.
Вот такая грубая и костыльная реализация, на удивление, вполне себе работала, хотя конечно артефакты её присутствия время от времени проявлялись и раздражали.
В следующие полгода использования система дорабатывалась под решение возникающих проблем (как проблем из-за общей её кривости, так и проблем — возникающих задач).
Ещё через 3-4 месяца мне надоело патчить браузер после каждого апдейта и было решено сделать всё по-нормальному — nginx и php выкидываем и пишем всё на C.
Итоговый вариант
Маленькая программа (из старой версии), которая разбирала и перенаправляла прокси-протокол, была взята за основу. Первоочерёдной задачей было реализовать в ней разворачивание https, потому что всё остальное в общем-то уже известно как делать (делалось не раз в другим проектах), а с SSL где-то кроме php я на тот момент ни разу не работал.
Для этого взял библиотеку OpenSSL. Весь код, её использующий, было решено выделить в отдельные процессы. Потому что, во-первых, в ней тогда постоянно находились дыры (а межпроцессная изоляция может эту проблему иногда сгладить), во-вторых так проще делать (модульность и инкапсуляция на уровне сокетов), и в-третьих API OpenSSL местами весьма странное (мягко говоря), и для нейтрализации последствий то ли кривого API, то ли неправильного его применения (вследствие отсутствующей или двусмысленной документации) удобно просто убивать ssl-процесс после того как соединение завершилось (к сожалению, это плохо сказывается на производительности, но я с этим смирился).
Вообще, из-за регулярных уязвимостей и невнятного API я даже собирался написать свою реализацию TLS, и даже начал, но, дойдя до парсинга сертификатов (увы, без этого почти ничего не сделать, ибо сертификаты оказывается используются не только для защиты от подмены сервера, но и для согласования ключей, даже если защита от подмены не нужна), испытал ещё один дискомфорт от спецификации ASN1. Стало понятно, что API библиотеки это только вершина айсберга, а внутри оно всё такое уже начиная с RFC самого протокола. Хотя в последнее время я более менее с этим всем смирился.
SSL/TLS-обёртки
Итак, были сделаны две вспомогательные программы, одна для заворачивания клиентского нешифрованного сокета в SSL/TLS, и вторая для разворачивания зашифрованного сокета, принятого сервером, в незашифрованный. Принцип простой: у подпрограммы есть наследуемые от родительской программы файловые декрипторы, которые родительская программа может заранее открыть нужным образом так, что дочерний процесс будет выглядеть для неё просто сокетом, в который можно записывать и из которого можно читать. При этом практически никакого отличия этого межпроцессного сокета от сокета интернетного не будет.
Таким образом, сервер принимает (accept) входящее подключение, выясняет что на той стороне хотят SSL/TLS, после чего отдаёт соединение дочернему процессу (который поднимает SSL/TLS-сессию, генерирует сертификат если нужно или берёт уже ранее сгенерированный), а от дочернего процесса берёт межпроцессный сокет, через который передаются уже нешифрованные данные. В итоге весь дальнейший код может вообще не делать различий между http-соединением и https-соединением, прозрачно расшифровывающимся дочерним процессом, и использовать для работы с этими соединениями обычные функции для работы с сокетами.
Аналогично и на клиентской стороне, только в обратную сторону: клиент запускает дочерний шифрующий процесс, шлёт данные в межпроцессный сокет, а дочерний процесс уже обеспечивает их шифрование прозрачно для клиента.
Ответ (много отладочных логов, можно скомпилировать чтобы было без них): дамп сертификата и предоставленной цепочки
Попытка собрать trusted цепочку
Как видно, «Certum CA» нет в списке доверенных Root CA, поэтому на первый взгляд это обрыв цепочки, но во втором сертификате цепочки (cert[2]) нашлась ссылка http://repository.certum.pl/ca.cer откуда можно скачать этот неизвестный сертификат; сертификат скачан (cert[*1]), но оказался самоподписанным и таким образом ничему не помогающим. На самом деле, в Root CA есть «Certum Trusted Network CA», так что всё в порядке и можно было ничего не скачивать.
Проверка соответствия доменного имени:
Теперь есть прозрачное подключение, шлём http-запрос и получаем ответ
Основной функционал
С шифрованием разобрались, теперь можно приступить к обработке полезной нагрузки.
Так как nginx у нас больше нет, то парсинг запроса придётся реализовывать заново. В целом ничего сложного тут нет, сначала парсятся заголовки через \r\n или \n разделитель, до тех пор пока не встретится пустая строка, а затем, если был заголовок Content-Length, читается тело запроса указанного количества байт. Chunked encoding в запросах можно и не поддерживать — никакие нормальные браузеры, да и вообще http-клиенты, его не генерируют.
После того, как запрос распарсен, он попадает в обработчик запроса — это та часть, которая раньше была написана на php, весьма увеличившаяся в размерах и количестве файлов. И хотя списки правил (кого блокировать, кого кешировать, кому резать куки и т.д.), ранее бывшие оформлены в виде php-массивов и коротких скриптовых функций, были переделаны в отдельные текстовые файлы специального удобного формата, но часть «пользовательской» логики всё ещё защита в коде (только теперь на C а не PHP), а код в целом унаследовал много признаков «сделать побыстрее как-нибуть» от своего предшественника. Сейчас обработчик (кроме капитально переделанных списков правил) всё так же сделан в виде одного «потока» кода из «главного» файла и вставленных в него include (не заголовочных файлов а сам код).
Изначально функционал обработчика был даже чуть меньше чем функционал последней из старых версий, но за 2 года плавно набрал ещё много нового. Из последнего — последние полгода-год всё чаще стали попадаться сайты с неполными цепочками сертификатов (потому что браузеры теперь их поддерживают без ругани), сначала я их просто вносил в белый список исключений, но это стало происходить слишком часто и пришлось реализовать кеширование и докачивание недостающих сертификатов в цепочке.
Что получилось
Отдельные модули для разворачивания шифрованного SSL/TLS-туннеля, один из которых при желании можно использовать как самостоятельную программу типа ssl-telnet. Ещё можно заменить их на какие-то альтернативные реализации (например с другой крипто-библиотекой), при этом остальная часть прокси ничего не заметит. Аналогично с инкрементальными обновлениями, ничего даже не нужно перезапускать. А ещё можно их использовать как демки по работе с OpenSSL (я прочёл много документации и всяких обсуждений в процессе их написания, возможно кто-то сможет теперь всё это быстрее усвоить). Код старался делать максимально понятным и простым.
Возможность пробросить точку выхода в интернет через, например, ssh port forwarding (связанный с этим функционалом код расположен в helpers/remote.c и в proxy.c в месте где обрабатывается аргумент «—proxy». Это не тоже самое что запустить само прокси на удалённом сервере. Тут важно что кеш и расшифровка SSL/TLS находятся на локальном компе, а пробрасывается только «внешний» конец. Хотя я давно не проверял работу этого режима, могла и сломаться.
Единообразный формат файлов правил для: блокировки загрузки страниц, блокировки куков, управления кешированием, включения сниффера, включения raw-режима (для real-time стримингов).
Аналог /etc/hosts но усовершенствованный: возможность сопоставления айпи-адреса не только по хосту, но и по порту и по протоколу, а так же сменить порт и протокол подключения.
Кеш, управляемый прописанными ему настройками, а не заголовками, присланными сервером. Заголовки управления кешированием часто не отражают действительность (или отражают мнение владельца сайта, которое может расходиться с критериями удобства пользования этим сайтом), поэтому сейчас они игнорируются. Думаю что стоит сделать их учёт по принципу «если сайт разрешил кешировать то значит можно, а если нет — разбираемся сами можно или нельзя», но пока руки не дошли. Кеш хранится в интуитивно понятно организованном дереве директорий, хранится бессрочно, но можно либо вручную удалять отдельные сохранения, либо настройкой задать «игнорировать всё что сохранено раньше такого-то времени».
Возможность кастомных действий перед, после или вместо загрузки страницы проксированным запросом. Реализваны хардкодом, файл handle/inc.rewrite.c
Любой аспект работы прокси можно легко переделать при необходимости. Код, несмотря на то, что он весьма разросся по сравнению с первыми версиями, всё ещё занимает очень мало места, и не потребует много времени как на первоначальное изучение, так и на освежение в памяти забытых деталей. С другой стороны, кому-то это и минус — для пользования всеми возможностями программы предполагается её регулярная пересборка и правка кода, а не «скомпилировал и удалил исходники».
Плюсы и минусы
(+) Модульность
(-) Из-за изоляции OpenSSL работает медленнее чем могло бы
(+) Гибкая настраиваемость под конкретные нужды
(+-) Много настроек прямо в исходном коде в виде #define и не только
(+-) IPv6 не поддерживается
(-) Нет интерактивного приложения для настройки и управления
(-) Код местами весьма плох и костылен
(-) До сих пор нет поддержки Access-Control-Allow-Origin с не ‘*’ в закешированных ответах — но единственное что у меня от этого ломалось это интерфейс мэйлру почты.
(-) До сих пор нет поддержки учёта настроек кеширования, присылаемых сервером
(-) Скачивать через него большие файлы (не в raw режиме) неэффективно — сначала прокси скачает файл себе на диск, затем будет через localhost-сеть отдавать его браузеру, который опять будет сохранять его на диск, а ещё там где-то (а может и в нескольких местах) прописано ограничение в 10мбайт на запрос
Как собрать/установить и технические детали кода
Из обычных библиотек используются стандартная C-библиотека, zlib (для распаковки gzip http-ответов), openssl (линкуется только к ssl-подпрограммам). В случае с Debian это были пакеты zlib1g-dev и libssl-dev. Так же используются свои библиотеки (маленькие) с кодом который мне часто оказывается нужен в разных местах и поэтому вместо регулярного копипаста выделен в отдельные компилируемые единицы.
В целях данной публикации, для упрощения всё это собрано в один пакет (скачать можно тут) и обёрнуто в один сборочный скрипт (да, не Makefile, так уж вышло что пока я обхожусь без make) build-all.sh.
Ряд настроек расположен в исходниках: в скрипте fproxy/build2.sh, в файле fproxy/config.h (если у вас файл с бандлом доверенных центров сертификации расположен не в /etc/ssl/certs/ca-certificates.crt то надо этот путь заменить тут). Настройки подпрограмм (helpers/) расположены прямо в их коде вверху в виде #define (config.h они не используют), но их менять вряд ли кому потребуется.
То, что некоторая часть настроек прописана в компилируемом коде, а не в файлах настроек сделано для (моего) удобства. В файлах настроек настраивается то, что можно назвать наиболее часто меняющимися пользовательскими настройками (списки правил), а всё остальное — в общем то первоначальная настройка программы при её установке, и крайне редкие изменения всяких технических параметров (даже чаще меняется логика работы кода чем #define-настройки). По факту сейчас вполне рабочая версия получается если просто запустить build-all.sh и не трогать никакие исходники перед этим.
Но переделать код на приём настроек через командную строку или из ещё одного файла конфигурации несложно.
Для работы прокси нужна заранее подготовленная структура директорий. Для её создания есть скрипт prepare-dir.sh — он создаёт рядом подготовленную директорию fproxy-target/ со всем что требуется и кладёт туда примеры правил (в том числе много блокировок спамных доменов).
| Путь | Описание: |
|---|---|
| cache/ | Симлинки на второй уровень cache_real/. |
| cache_real/ | Кеш, двухуровневая структура — домен 2 уровня, потом полный домен. |
| saved/ | Симлинки на второй уровень saved_real/. |
| saved_real/ | Сохранённый не-кеш, 2-ур. структура. |
| cert-pin/certs/ | Настройки сертификатов для каждого домена (общий режим, белый/чёрный списки, вопросы). |
| cert-pin/queue/ | Тут создаются файлы при появлении вопросов в качестве флажков для интерактивной программы управлением этими настройками, если она будет. |
| cert-pin/cache/ | Кеш известных проксе сертификатов для дополнения неполных цепочек, принятых от сайтов (это НЕ список доверия, все эти сертификаты действительны только после прохождения проверок на общих основаниях). |
| dyn-certs/ | Кеш для сгенерированных сертификатов которые шлются браузеру. |
| hist/ | Сохранённая история посещений (инструментов для её просмотра пока нет, кроме ручного). |
| internal/ | Сейчас тут хранится сокет для запросов от скачивателя AIA сертификтов к проксе. |
| log/ | Логи. |
| pem/ | Корневой сертификат и приватные ключи для генерации сертификатов сайтов. |
| proxy_temp/ | Хранение запросов которые слишком большие для хранения их в памяти. |
| tmp/ | Временные файлы. |
| dyn-cert-serial | Файл с текущим серийным номером генерируемого сертификата (начальное содежание — символ ‘0’ и перевод строки после него). |
| mincache.date | Если файл есть и в нём тут записано число больше 0, то весь кеш раньше этого времени будет игнорироваться. |
| offline.flag | Если файл есть и в нём тут записано число больше 0, то прокси будет работать в режиме «интернет-архива» — на каждый запрос сначала искать в saved_real/ данные, близкие по времени к указанному числу, и только если не нашлось — проксировать запрос. |
| rules_*.txt | Различные правила, на данный момент их изменения учитываются только после перезапуска прокси. |
Насчёт прав доступа и вообще безопасности
Простейший вариант установки — запустить всё из под своего обычного юзера с обычными правами на всё (можно даже прямо из директории fproxy-target/, созданной скриптом prepare-dir.sh).
Но по ряду причин имеет смысл сделать по-другому. Для прокси создаётся отдельный юзер и группа, ему выдаются эксклюзивные права на чтение данных прокси, и права на запись в несколько мест, где они нужны. Права «только чтение» можно реализовать, поставив владельца root и группу прокси, и поставив доступ 0640 или 0750. Делать что бы то ни было из данных world-readable в любом случае плохая идея, всё же там лежит вся история браузера, а где-то и сохранённое содержание страниц, а так же ключи, с помощью которых браузеру можно делать MITM.
Для работы программы dashboard ей нужен только доступ на чтение к файлу BASE/log/dashboard и ничего другого.
По умолчанию прокси слушает 127.0.0.10:3128. Для работы с 127.0.0.10 у меня ничего специально настраивать (в ОС) не пришлось, но возможно в каких-то системах нужно.
Рабочая директория по умолчанию — та, что была текущей при запуске, но это можно поменять в настройках.
Заключение
Ещё раз ссылка на скачивание: тут.
Для публикации код был дооформлен в такой вид, который на мой взгляд допустимо публиковать, но всё же делалось это исключительно для себя под локальное применение и «по-быстрее», так что сейчас код во многих местах не образец для подражания. Но основную задачу он выполняет, а со временем будет улучшаться.
Из наиболее приоритетных на данный момент планов на будущее в плане функционала — сделать интерактивную настройку и управление (сертификаты, кеш, история, менеджер загрузок больших файлов) либо отдельным приложением, либо в спецдомене через браузер, но ничего не обещаю.
Надеюсь, что кому-то это всё окажется интересным и так или иначе поможет.