Если клиент ранее не встречался с сервером, поэтому он не знает ожидаемого открытого ключа, необходимо использовать стороннего посредника для проверки задействованных идентификаторов. В сценариях P2P у вас есть так называемые « стороны, подписывающие ключи », где люди обмениваются открытыми ключами посредством личной встречи.
Если люди уже знают друг друга, то даже через небезопасный канал вы можете использовать алгоритмы, такие как Диффи-Хеллман , чтобы обмениваться вашими личностями, которые вы можете проверять на основании информации, которую вы уже имели о личности этого человека.
В обычном сценарии HTTPS клиент, возможно, еще не знает сервер, но сервер представляет сертификат, подтвержденный взаимно доверенной третьей стороной, который подтверждает его личность. Например, Paypal может предоставить вам сертификат, который гласит: «VeriSign согласен, что я тот, кем я говорю». И если вы доверяете VeriSign, эта «сеть доверия», как она называется, означает, что вы доверяете Paypal - это те, кому они говорят они есть.
В вашем сценарии клиент-сервер серверу нужен как его личный, так и открытый ключ - открытый ключ используется для шифрования сообщений, возвращаемых клиенту, а закрытый ключ используется для расшифровки сообщений, отправляемых клиентом. ему.
Сервер обычно не знает, кто пользователь (говоря криптографически), клиент может создать новый сертификат и пару открытых / закрытых ключей для каждого отправляемого им запроса. Способ изменить это подробно описан в этой статье IBM . То, что в конечном итоге происходит в обычных сценариях HTTPS, представляет собой смесь шифрования с закрытым и открытым ключами; Вы можете прочитать больше об этом в этом связанном SO сообщении .
Удачи!