Я немного смущен тем, как работает двухсторонний SSL. Как клиент создает свой сертификат для отправки на сервер? Является ли он сгенерирован с сервера и распространен клиентом?
Кроме того, в чем преимущество двухстороннего SSL для одностороннего SSL?
Оба сертификата должны существовать до подключения. Они обычно создаются органами сертификации (не обязательно одинаковыми). (Существуют альтернативные случаи, когда верификация может быть выполнена по-разному, но необходимо провести некоторую проверку.)
Сертификат сервера должен быть создан CA, которому доверяет клиент (и следуя соглашениям об именах, указанным в RFC 6125).
Сертификат клиента должен быть создан ЦС, которому доверяет сервер.
Это зависит от каждой стороны, чтобы выбрать то, на что она надеется.
Существуют онлайн-инструменты CA, которые позволят вам подать заявку на сертификат в вашем браузере и установить его там, как только CA его выпустит. Им не обязательно быть на сервере, который запрашивает аутентификацию сертификата клиента.
Распределение сертификатов и доверительное управление - это роль инфраструктуры открытого ключа (PKI), реализованной через ЦС. Клиент и серверы SSL/TLS, а затем просто пользователи этого PKI.
Когда клиент подключается к серверу, который запрашивает аутентификацию сертификата клиента, сервер отправляет список ЦС, которые он согласен принять как часть запроса клиентского сертификата. Затем клиент может отправить свой клиентский сертификат, если он пожелает, и подходящий.
Основными преимуществами аутентификации клиент-сертификата являются:
Вам может быть интересно Преимущества клиентских сертификатов для проверки подлинности клиента? (в разделе Security.SE).
То, что вы называете "Двусторонним SSL", обычно называется TLS/SSL с аутентификацией сертификата клиента.
В "обычном" TLS-соединении с example.com только клиент проверяет, действительно ли он взаимодействует с сервером для example.com. Сервер не знает, кто такой клиент. Если сервер хочет аутентифицировать клиента, обычным делом является использование паролей, поэтому клиенту необходимо отправить имя пользователя и пароль на сервер, но это происходит внутри TLS-соединения как часть внутреннего протокола (например, HTTP), а не часть самого протокола TLS. Недостатком является то, что вам нужен отдельный пароль для каждого сайта, потому что вы отправляете пароль на сервер. Поэтому, если вы используете один и тот же пароль, например, PayPal и MyPonyForum, то каждый раз, когда вы входите в MyPonyForum, вы отправляете этот пароль на сервер MyPonyForum, чтобы оператор этого сервера мог его перехватить и попробовать в PayPal и может выносить платежи от вашего имени.
Аутентификация сертификата клиента предлагает другой способ аутентификации клиента в TLS-соединении. В отличие от входа в пароль, аутентификация сертификата клиента указывается как часть протокола TLS. Он работает аналогично тому, как клиент аутентифицирует сервер: клиент генерирует пару открытого частного ключа и отправляет открытый ключ в доверенный ЦС для подписания. CA возвращает сертификат клиента, который может использоваться для аутентификации клиента. Теперь клиент может использовать тот же сертификат для аутентификации на разных серверах (т.е. Вы можете использовать тот же сертификат для PayPal и MyPonyForum, не рискуя, что его можно злоупотреблять). Способ, которым он работает, заключается в том, что после отправки сервером сертификата он также запрашивает у клиента сертификат. Затем происходит какая-то магия с открытым ключом (если вы хотите узнать подробности, прочитайте RFC 5246), и теперь клиент знает, что он общается с нужным сервером, сервер знает, что он обменивается данными с правильным клиентом, и оба имеют общий материал для шифрования и проверки соединения.
В двух направлениях ssl клиент запрашивает у серверов цифровой сертификат и сервер запрашивает то же самое от клиента. Он более защищен, так как это оба пути, хотя его бит медленный. Как правило, мы не следим за ним, так как сервер не заботится о личности клиента, но клиент должен убедиться в целостности сервера, к которому он подключается.