Реализация SSL-сервера с использованием libssl и sendmsg() SCM_RIGHTS
Теперь мне интересно, можем ли мы создать какой-нибудь SSL-сервер на основе следующих политик / схем в среде Linux.
(1) Что касается первоначального запроса, он должен быть входящим в процесс родительского сервера. После установления SSL-соединения, а также обработки первоначального анализа запроса, запрос (сокет) будет перенаправлен в процесс обработки запроса для дальнейшей обработки.
(2) Процесс обработки запросов должен выполняться заранее. В этом смысле мы не будем использовать схему на основе fork-exec-pipe.
(3) Что касается связи между процессом родительского сервера и процессом обработки запроса, был установлен некоторый IPC для копирования дескриптора открытого сокета из процесса родительского сервера в процесс обработки запроса с использованием метода sendmsg() - SCM_RIGHTS.
(4) С точки зрения функциональности SSL мы должны использовать OpenSSL (libssl).
(5) В процессе обработки запросов мы должны создать новый сокет SSL, используя дескриптор общего сокета из процесса родительского сервера.
Дело в том, что я не хочу терять производительность передачи данных между сервером и процессом обработки запросов. Я также не хочу порождать процесс обработки запросов в соответствии с запросами. Поэтому я хотел бы заранее запустить процесс обработки запросов.
Хотя я не совсем уверен, имеет ли смысл то, что я пытаюсь сделать здесь, для вас, было бы полезно, если бы кто-нибудь из вас мог подсказать мне, возможен ли вышеуказанный подход.
1 ответ
Не ясно, что именно вы ищете, особенно, где вы хотите сделать шифрование / дешифрование SSL.
Вы хотите сделать шифрование / дешифрование внутри процессов обработчика запросов?
Это кажется более вероятной интерпретацией. Тем не менее, вы говорите о выполнении некоторого анализа запроса в основном процессе. Являются ли данные, проанализированные в главном процессе, уже частью сеанса SSL? Если это так, вам потребуется выполнить SSL-рукопожатие (инициализация и обмен ключами) в главном процессе, чтобы получить доступ к зашифрованным данным. Если вы затем передадите исходный сокет другому процессу, у него не будет доступа к состоянию SSL родительского процесса, поэтому он не сможет продолжить расшифровку с того места, где остановился родительский процесс. Если он попытался повторно инициализировать SSL на сокете, как если бы это было чистое соединение, клиент, вероятно, (правильно) будет рассматривать нежелательное рукопожатие в середине соединения как ошибку протокола и завершит соединение. Если этого не произойдет, это создаст дыру в безопасности, так как это может быть злоумышленник, который злонамеренно перенаправил сетевой трафик клиента, а не процесс обработки запросов, который вызывает повторную инициализацию. Как правило, невозможно передать инициализированные сеансы SSL различным процессам, не сообщив при этом также о полном внутреннем состоянии OpenSSL (обмен ключами, некоторые порядковые номера и т. Д.), Что было бы трудно, если не невозможно.
Если вам не нужно прикасаться к сеансу SSL в родительском процессе, и вы анализируете только некоторые незашифрованные данные, поступающие до начала фактического сеанса SSL (аналогично, например, команде STARTTLS в IMAP), ваша идея будет работать без проблем. Просто прочитайте, что вам нужно, до того момента, когда должен начаться обмен SSL, а затем передайте сокет бэкэнд-процессу, используя SCM_RIGHTS (см., Например, пример в cmsg(3) или на этом сайте). Есть также библиотеки, которые делают работу за вас, а именно, библиотека.
Или вы ожидаете, что главный процесс будет выполнять шифрование / дешифрование SSL для процессов обработчика запросов?
В этом случае нет смысла передавать исходный сокет процессам-обработчикам запросов, поскольку единственное, что они получают от него, - это зашифрованные данные. В сценарии вы должны открыть новое соединение с внутренним процессом, так как он будет переносить различные данные (расшифрованные). Затем главный процесс будет считывать зашифрованные данные из сетевого сокета, расшифровывать их и записывать результат в новый сокет для обработчика запросов. Аналогично в другом направлении.
NB. Если вы просто хотите, чтобы процессы обработки запросов вообще не беспокоились о SSL, я бы рекомендовал им прослушивать интерфейс обратной связи и использовать что-то вроде stud для грязной работы SSL/TLS.
Короче говоря, вы должны выбрать один из вышеперечисленных. Невозможно сделать оба одновременно.