|
Задавайте вопросы, мы ответим
Вы не зашли.
Штатный MySQL conneсtor берёт 3 ключа SSH - из файлов. Прошу модифицировать его так, чтоб он брал их из памяти локального хоста. Или как-то иначе, но не из файлов.
Имеется клиент-серверная кроссплатформенная программа, которая конектится к серверу по SSH. Эти ключи вкомпилированны в код С++ клиентской части.
Для Win, это мы сделали через маску памяти.
Нужно сделать для Android (mariadb), NIX, MacOS & IOs.
В теории, есть NamedPipes, но у нас они - не заработали...(т.е. на пустом тестовом примере ключи передавались через NamedPipes, а в реальной работе приложения - нет)
Отредактированно proot (25.02.2021 17:04:01)
Неактивен
Мне кажется, вы смотрите не туда. MySQL не умеет коннектиться по SSH, а SSH используется только как один
из вариантов шифрования потока (при этом реальный трафик будет идти всё равно по TCP внутри этого
шифрованного канала). То, что его внесли в коннектор, — это, скорее, недоразумение, чем правильное решение
(хотя оно, конечно, направлено на упрощение подключения в некоторых случаях).
Предлагаю воспользоваться правильным решением — взять какой-нибудь libssh и настроить туннелирование
через него напрямую (а коннектор натравливать уже на проброшенный порт).
Неактивен
Спасибо за совет!
Я таки, как заказчик, смотрю только к себе в кошелёк...Я не разу не программист!
Сервер MySQL генерит три файла ключей. Чтоб повысить стойкость к взлому и спрятать эти ключи на стороне клиента, было предложено вкомпилить их в исходник клиенткой части и провести обфускацию. Понимаем всю кривизну решения! Но, а как иначе? Если ключи комплектовать с клиентской частью в свободном доступе, то какой в них смысл? Любой, кто имеет доступ к клиентской части (читай все) может подключиться к MySQL серверу, к примеру, через Workbench и слить всю базу и сам сервер. Да, сейчас так не делают. Сейчас всё "лежит" на сервере, а клиентской части, как таковой нет. Есть Web интерфейс, который "управляет картинками". Но у нас такая вот "архивная" структура...
Неактивен
Да, это вообще SSL, я ошибся...
Неактивен
Ох. Если цель обфусцировать клиентские подключения, и при этом у всех клиентов один ключ (в том смысле, что вы не выдаете каждому клиенту свой персональный), то сертификат достанут в любом случае, даже если он хорошо обфусцирован. Если вы хотите ограничить доступ к данным, подумайте, как вы хотите раздавать данные, и сделать серверные ограничения, которые позволят раздавать только нужными кусками (HTTP api, хранимые процедуры, еще что-то).
Если будете всё же заниматься обфускацией ключа:
* Можно подпатчить libmysqlclient: viosslfactories.cc / vio_set_cert_stuff() — там используется SSL_CTX_use_PrivateKey_file, его можно переделать на SSL_CTX_use_PrivateKey, создав ключ из опции.
* Возможно, будет проще сделать временный файл, в который записать текст ключа и не изменять библиотеку (и удалить сразу после sql_connect()).
* Как возможный вариант — на этапе линковки переопределить SSL_CTX_use_PrivateKey_file (и заменить на версию, которая подгрузит контекст из памяти) — костыль, но тоже имеет право на жизнь.
Неактивен
Спасибо за "наколку" ..обязуюсь донести до исполнителя. Осталось только за малым - найти оного..
Неактивен
