RFC/advice: Дизайн защищенного/незащищенного протокола rpc/event-stream

SSL кажется довольно раздутым для того, что я хочу сделать, и я страстно ненавижу OpenSSL (NSS может быть полезен). Мне нужно открыть TCP-канал между двумя узлами, который будет использоваться для RPC/зашифрованных RPC/потоков событий/зашифрованных потоков событий. Я использую буферы протоколов для определения и мультиплексирования различных источников трафика.

Я не хочу использовать SSL для начала. Мне нужно аутентифицированное безопасное установление ключа (аутентифицированное diffie-hellman), а затем, возможно, объект потока на основе блочного шифра для шифрования и дешифрования зашифрованных потоков событий и зашифрованного RPC.

Первая мысль, которая у меня возникла, заключалась в том, чтобы сэкономить время на кодирование и время разработки, опираясь на реализацию SSL, при условии, что я могу получить дескриптор сокета из реализации SSL и использовать его для незашифрованных обменов, а также для зашифрованных обменов. Но это, вероятно, окажется уродливой реализацией, и, насколько я знаю, это может быть несовместимо с протоколом ssl (т. Е. Сильная связь между состоянием TCP и состоянием SSL).

Вторая мысль, которая у меня была, заключалась в том, чтобы сэкономить время кодирования и время разработки, открыв несколько сокетов. Но, как мы все знаем, дизайн протокола с несколькими сокетами — это зло.

Третья мысль заключалась в том, что я просто все зашифрую, но рассматриваемый сервис служит в качестве высокопроизводительного коммутатора событий, и у него также есть сервер базы данных, работающий на той же машине. Накладные расходы этого подхода не удовлетворяют, так как большая часть трафика будет открытым текстом.

Таким образом, эти подходы не кажутся мне удовлетворительными. Поэтому я пришел к выводу, что с помощью cryptopp и boost::asio я могу накатить свое решение и построить свой собственный протокол (что я уже должен сделать). Я довольно способный системный программист, и у меня есть инженеры, разбирающиеся в применении методов шифрования.

Я полностью за повторное использование, и в этом случае я хотел бы повторно использовать SSL, но не думаю, что смогу. Любые советы, которые вы можете дать мне из своего опыта в подобных ситуациях (вы, должно быть, разработали или работали над сетевым протоколом), будут оценены. Совет, который произвел на меня наибольшее впечатление, получает галочку. :D

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


person Hassan Syed    schedule 09.02.2011    source источник
comment
Я не знаю, что вы подразумеваете под раздутым, но похоже, что вы пытаетесь заново изобрести SSL. На самом деле, вы делаете много предположений в своем вопросе. Фактически, вы можете наложить SSL-соединение поверх уже подключенного TCP-соединения, и многие протоколы обновления SSL основаны именно на этом поведении.   -  person President James K. Polk    schedule 10.02.2011


Ответы (1)


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

Самый простой способ сделать это — использовать библиотеку SSL, которая позволяет вам предоставлять свои собственные функции отправки/получения, которые будут вызываться библиотекой SSL, когда она имеет зашифрованные данные для отправки или получения. Затем вы должны реализовать эти функции, заключив данные SSL в специальные фреймы в рамках вашего собственного базового протокола.

(Я знаком только с тем, как это делает библиотека OpenSSL — функция SSL_set_bio() — но я уверен, что другие реализации SSL допускают нечто подобное).

Учтите, однако, что накладные расходы на вычисление части протокола, связанной с согласованием ключей, независимо от того, выполняются ли они через SSL или самостоятельно, намного перевешивают фактическое шифрование/дешифрование блочного шифра, поэтому «зашифровать все» может быть не так уж сложно. потери, как вы ожидаете.

person caf    schedule 10.02.2011
comment
Открытые сокеты будут постоянными, поэтому накладные расходы на обмен ключами будут минимальными, а узлы всегда будут существовать в защищенной сети как есть. Мне нужен только обмен ключами, безопасный канал и простая аутентификация (достаточно простого пароля по безопасному каналу). Понимание того, что сокеты SSL и сокеты TCP слабо связаны, приветствуется, спасибо. Я все еще разрываюсь между собственным и повторным использованием SSL. Boost::asio имеет поддержку openssl, и на большинстве машин все равно установлен SSL. Я просто чувствую себя очень виноватым в зависимости от cryptopp + SSL, так как есть много совпадений. - person Hassan Syed; 11.02.2011