Нужен ли клиенту private key?

Question

[Notcoder]

Есть сервер на Qt (QSslServer) и клиент. Оба используют QSslSocket.
У сервера есть сертификат и ключ, у клиента вроде бы тоже. У каждого различные.
Если клиентов много, получается что для каждого из них private key (клиентский) должен отличаться, иначе нет смысла шифровать что-то вообще. Как лучше всего решить проблему?

Если каждому клиенту автоматически (на стороне клиента) генерировать свой ключ и сертификат, важно ли вообще что он будет не подписанный?

Comments

[Ivan Ustûžanin]

если нужно только шифрование трафика, без аутентификации клиента по закрытому ключу, то клиенту вообще ключевая пара не нужна, так собственно весь интернет работает — сертификат и его закрытый ключ на сервере, на клиенте только доверие к УЦ, выпустившему этот сертификат

если без аутентификации не обойтись (как делает WireGuard), то да, на каждого клиента нужна своя уникальная ключевая пара

[Steel_Balls]

а задача-то какая?
Ты про цель напиши, а не вот это вот

Answer 1

[Saboteur]

Вы бы уточнили вопрос, что именно вы хотите сделать.

Клиентский сертификат вообще не обязателен для ssl, шифрование и так будет работать.

Но он может использоваться для авторизации или для mutual-tls
В этом случае понятно, что у каждого должна быть свой сертификат и приватный ключ, а для подключения, нужно чтобы сервер и клиент друг другу доверяли, для чего нужно чтобы или они были выданы CA которому оба доверяют.

Но мне кажется, что вы не совсем понимаете как и что у вас вообще работает, потому что формулирование вопроса туманно

Comments

[Notcoder]

Конкретно: я хочу сделать зашифрованное соединение между клиентом и сервером.
Клиент отправляет данные на сервер, сервер их проверяет, отправляет ответ клиенту.
Я точно не до конца понимаю что и как, если есть статья или что-то что можно почитать и разобраться, был бы благодарен.

[Saboteur]

Так вы же используете QSslServer
Он и шифрует.
Для шифрованного сообщения достаточно только сертификата на стороне сервера.
https://habr.com/ru/articles/258285/

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

Опционально можно mTLS
В процессе этого рукопожатия, клиент в самом начале также может передать свой сертификат со своим публичным ключом для установления mutual TLS, сервер тогда проверит доверяет ли он ему и уже после этого будет продолжать рукопожатие, отправляя данные клиенту уже зашифрованные его публичным ключом, то есть половина рукопожатия будет уже тоже зашифрована и клиент провалидирован на доверяемый сертификат
В этом случае естественно нужно чтобы и клиент и сервер доверяли друг другу.
Ну и отдельно все выше это только про установление шифрованной сессии

Опционально можно еще и авторизировать - тогда да, у каждого клиента должен быть свой сертификат, на стороне приложения тогда нужно хранить какие-то данные по этому сертификату для авторизации - можно serial ID, можно certificate subject.

Что такое доверять - при установлении tls соединения, необходимо указать trusted keystore, место где лежат доверяемые сертификаты. В зависимости от софта и ОС, можно посмотреть что там по дефолту. Обычно указывается на файл с сертификатами (pem, jks, p12 форматы, или хранилище сертификатов виндовс).

Цепочка сертификатов строится как
* Рутовый сертификат (срок годности десятки лет), которым подписываются CA (center authority) сертификаты
* CA сертификат (обычно срок годности 5-10 лет), которым подписываются уже пользовательские сертификаты
* Ну и клиенский сертификат, срок годности разный. обычно месяц-год-два года.
В доверенные сертификаты можно добавить любой из этой цепочки, и следовательно получить свои плюсы и минусы. Добавив один раз рутовый или CA сертификат, вы не паритесь по поводу того, что на той стороне перевыпустили новый сертификат. Главное чтобы он был выпущен через тот же CA/root
Можно добавить сам клиентский в доверенные, но при перевыпуске клиентского, нужно будет сперва добавить новый клиентский в доверенные.

Как-то так.

[Inviz Custos]

Notcoder, также желательно указать какую именно проблему вы хотите решить шифрованием.
Приложение будет запускаться посторонним человеком и Вы хотите затруднить анализ трафика?

[CityCat4]

Я точно не до конца понимаю что и как

Оно и заметно.

Для шифрования не нужно сертификат клиента - достаточно сертификата сервера. Сертификат клиента нужен, если:
- есть аутентификация (этот человек - Джон Рукомойников, потому что он предоставил сертификат) и авторизация (поскольку личность Джона подтверждена, ему будут доступны такие-то ресурсы)
- есть разделение ресурсов (поскольку личность Джона подтверждена, ему будет доступен приватный канал)

НО:

Для того, чтобы такое замутить - клиенты либо генерят CSR самостоятельно (что настоятельно рекомендуется, так как только в этом случае ключ никуда не уходит), либо безоговорочно доверяют Вам, когда Вы им генерите каждому пару ключ-сертификат, для чего подымаете свой CA и раздаете его сертификат, чтобы все эти люди поместили его в доверенные.

Еще раз:
Это вопрос исключительно доверия. Каждый, кто ставит Ваш сертификат в корневые, должен четко понимать - с этого момента Вы можете выпускать любые сертификаты и система будет им доверять равно также как GlobalSign и LE.

[Saboteur]

Я бы даже сказал, что именно для шифрование даже не нужен сертификат сервера, нужен только публичный ключ сервера. Сертификат это уже на уровне дополнительной валидации сервера и добавление expiration. В том же ssh без сервера устанавливается шифрованное соединение

[Ivan Ustûžanin]

Saboteur,

В том же ssh без сервера устанавливается шифрованное соединение

наверное всё же «без сертификата» )

[Notcoder]

Inviz Custos, изначально задача была сделать авторизацию пользователя в приложении, а вообще пытаюсь разобраться как возможно по максимуму в технологии в целом

[Notcoder]

Saboteur, спасибо за ответ

Answer 2

[Alexey Dmitriev]

Клиент должен доверять корневому центру сертификации, подписавшему сертификат на сервере. Либо иметь опцию игнорировать проверку и принимать любые сертификаты.
Private key никогда и никому не отдается.