Реализация SSL-сервера с использованием libssl и sendmsg () SCM_RIGHTS

Question

Теперь мне интересно, можем ли мы создать какой-нибудь SSL-сервер на основе следующих политик / схем в среде Linux.

(1) Что касается первоначального запроса, он должен быть входящим в родительском.серверный процесс.После установления соединения SSL, а также обработки начального анализа запроса, запрос (сокет) будет перенаправлен процессу обработки запроса для дальнейшей обработки.

(2) Процесс обработки запроса будет чем-то, чтодолжен быть запущен заранее.В этом смысле мы не будем использовать схему, основанную на fork-exec-pipe.

(3) Что касается связи между процессом родительского сервера и процессом обработки запросов, был создан некоторый IPC, чтобыскопируйте дескриптор открытого сокета из процесса родительского сервера в процесс обработки запроса с помощью метода sendmsg () - SCM_RIGHTS.

(4) С точки зрения функциональности SSL мы должны использовать OpenSSL (libssl).

(5) В процессе обработки запросов мы должны создать новый сокет SSL, используя дескриптор общего сокета из процесса родительского сервера.

Дело в том, что я неНе нужно терять производительность передачи данных между сервером и процессом обработки запросов.Я также не хочу порождать процесс обработки запросов в соответствии с запросами.Поэтому я хотел бы заранее запустить процесс обработки запросов.

Хотя я не совсем уверен, имеет ли смысл то, что я пытаюсь здесь сделать, имеет смысл, если бы кто-нибудь из вас мог датьМне подсказывают, возможен ли вышеуказанный подход.

Answer 1

Не ясно, что именно вы ищете, особенно, где вы хотите сделать шифрование / дешифрование SSL.

Хотите ли вы выполнить шифрование / дешифрование внутри процессов обработчика запросов?
Это кажется более вероятной интерпретацией.Тем не менее, вы говорите о выполнении некоторого анализа запроса в основном процессе.Являются ли данные, проанализированные в главном процессе, уже частью сеанса SSL?Если это так, вам потребуется выполнить SSL-рукопожатие (инициализация и обмен ключами) в главном процессе, чтобы получить доступ к зашифрованным данным.Если вы затем передадите исходный сокет другому процессу, у него не будет доступа к состоянию SSL родительского процесса, поэтому он не сможет продолжить расшифровку с того места, где остановился родительский процесс.Если он попытался повторно инициализировать SSL на сокете, как если бы это было чистое соединение, клиент, вероятно, (правильно) будет рассматривать нежелательное рукопожатие в середине соединения как ошибку протокола и завершит соединение.Если этого не произойдет, это создаст дыру в безопасности, так как это может быть злоумышленник, который злонамеренно перенаправил сетевой трафик клиента, а не процесс обработки запросов, который вызывает повторную инициализацию.Как правило, невозможно передать инициализированные сеансы SSL различным процессам, не сообщив при этом также о полном внутреннем состоянии OpenSSL (обмен ключами, некоторые порядковые номера и т. Д.), Что будет трудно, если не невозможно.

Если вам не нужно прикасаться к сеансу SSL в родительском процессе, и вы анализируете только некоторые незашифрованные данные, поступающие до начала фактического сеанса SSL (аналогично, например, команде STARTTLS в IMAP), ваша идея будет работать без проблем.Просто прочитайте то, что вам нужно, до того момента, когда должен начаться обмен SSL, затем передайте сокет бэкэнд-процессу, используя SCM_RIGHTS (см., Например, пример на cmsg (3) или на этом сайте.).Есть также библиотеки, которые выполняют эту работу за вас, а именно: libancillary .

Или вы ожидаете, что главный процесс будет выполнять шифрование / дешифрование SSL для процессов обработчика запросов?
В этом случае нет смысла передавать исходный сокет процессам-обработчикам запросов, поскольку единственное, что они могут получить от него, - это зашифрованные данные.В сценарии вы должны открыть новое соединение с внутренним процессом, так как он будет переносить разные данные (расшифрованные).Затем главный процесс будет считывать зашифрованные данные из сетевого сокета, расшифровывать их и записывать результат в новый сокет для обработчика запросов.Аналогично в другом направлении.

Примечание: если вы просто хотите, чтобы процессы обработки запросов вообще не беспокоились о SSL, я бы рекомендовал им прослушивать интерфейс обратной связи и использовать что-то вроде stud для выполнения грязной работы SSL / TLS.

Короче говоря, вы должны выбрать один из вышеперечисленных.Невозможно сделать оба одновременно.