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

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

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

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

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

спамер?

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

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

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

> 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

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

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

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

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

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

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

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

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

// wbr

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

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