LINUX.ORG.RU

Openssl, сертификаты, производительность


0

0

Есть следующая задачка: надо написать сервер и клиент для одной системы.

Необходимо шифрование трафика и идентификация сервера клиентом и клиентов сервером.

Пользовать, как понимаю, разумно Openssl.

Допустим, у нас есть 10000-100000 клиентов, у каждого должен быть свой сертификат.

Допустим, мы можем как-то идентифицировать клиента (по id, или по ip-адресу) и проверить его сертификат, клиент тоже проверяет сертификат сервера.

Как я понимаю, для этого на сервере должны храниться публичная часть сертификатов всех клиентов, а у клиентов публичная часть сертификата сервера?

Обмен будет вестись короткими сообщениями (примерно 128-256 байт), но с большой интенсивностью (100-1000 запросов в секунду).

Причём, скорее всего среди клиентов не будет равномерности по отправке сообщений, т.е. один клиент может прислать одно сообщение в день, другой же каждые 3 секунды слать.

Какая должна быть производительность у сервера, чтобы обслуживать такую нагрузку?

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

Возможно есть какие-то альтернативы ssl в данном случае?


> Какая должна быть производительность у сервера, чтобы обслуживать такую нагрузку? Так же разумным встаёт вопрос: сколько одновременных подключений сможет выдержать сервер? т.е. создавать ли для отправки каждого сообщения заново соединение, или нет.

Лучше кластер из нескольких машин попроще сделать, с лоадбалансером на входе. Балансер принимает подключения клиентов и перкидывает его на самую свободную машину за ним. 100т клиентов с 1т запросов от каждого - это неслабая нагрузка на сетевую подсистему, да и ненадёжно.

> Возможно есть какие-то альтернативы ssl в данном случае?

Блочные симметричные шифры, типа 3DES-CBC. Периодическую смену входных векторов можно реализовать в вашем протоколе, например, раз в сутки (чтобы брутфорсом перехваченный траффик сломать тяжелее было).

mv ★★★★★
()
Ответ на: комментарий от anonymous

Да нет, нет, не спамер))

Финансовая задача... Собирать данные о транзакциях из разных мест.

dimaz-z
() автор топика
Ответ на: комментарий от borisych

> 100-1000 ssl Запросов в секунды это достаточно мало: http://www.ncipher.com/Products/SSL%20Acceleration/nFast.aspx

# Up to 10,000 RSA SSL handshakes per second (RSA 1024 bit)

а если там 4096bit? хорошо, если 1k выжмет..
впрочем, по сравнению с программной реализацией и это хлеб.

// wbr

klalafuda ★☆☆
()

> Как я понимаю, для этого на сервере должны храниться публичная часть сертификатов всех клиентов, а у клиентов публичная часть сертификата сервера?

Разумеется, не должны. man pki, man certificate authority.

> Обмен будет вестись короткими сообщениями (примерно 128-256 байт), но с большой интенсивностью (100-1000 запросов в секунду).

> Так же разумным встаёт вопрос: сколько одновременных подключений сможет выдержать сервер? т.е. создавать ли для отправки каждого сообщения заново соединение, или нет.

Разумеется, не создавать. 1000 новых TCP соединений в секунду -- это самый настоящий DoS сетевого стека ОС, даже не говоря о выполнении SSL handshake для каждого соединения (да, производительность ассиметричных алгоритмов шифрования _много_ меньше производительности СБШ).

anonymous
()
Ответ на: комментарий от anonymous

> Разумеется, не создавать. 1000 новых TCP соединений в секунду -- это самый настоящий DoS сетевого стека ОС, даже не говоря о выполнении SSL handshake для каждого соединения (да, производительность ассиметричных алгоритмов шифрования _много_ меньше производительности СБШ).

да неправда ваша, 1000 новых соединений в секунду при среднем количестве одновременных соединений ~n*10k - это вполне терпимо.

другое дело, что раскодировать 1k сессионных ключей, скажем, по RSA даже 2kbit - это жопа. уж больно он, зараза, дорогой до ресурсов. придётся ставить отдельных сервер, который будет заниматься только декриптом.

// wbr

klalafuda ★☆☆
()

> Возможно есть какие-то альтернативы ssl в данном случае?

Конечно, есть. Собственный протокол, построенный на криптографических примитивах, реализованных в OpenSSL. Например, можно предложить реализовать взаимную аутентификацию сторон, согласование и периодическое обновление ключевого материала для СБШ/HMAC по долговременному SSL/TLS каналу поверх TCP, а сам обмен данными осуществлять шифрованными UDP датаграммами, аутентифицируемыми при помощи HMAC. Похожую архитектуру кстати имеет протокол OpenVPN (там правда отдельного TCP соединения не создается).

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.