Некоторые пробелы в понимании рабочего процесса инфраструктуры открытых ключей

Принимая эти вопросы за вопросом:

(1) «Мой интернет-магазин» как компания должна быть «сертифицирована» в каком-либо стороннем центре сертификации. Это означает, что мне нужно купить какое-то годовое членство в этом ЦС, а затем они зарегистрируют «Мой интернет-магазин» в своих системах и выдадут мне некоторые вещи, такие как сертификат и пару уникальных открытых и закрытых ключей. Получу ли я какой-нибудь файл-сертификат?

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

Когда вы заплатили деньги и оформили документы, вы и УЦ сгенерируете как минимум 2 вещи:

• Пара открытый/закрытый ключ. Часто это генерируется ВАМИ, а не ЦС. Качество того, как вы сгенерировали и сохранили свою пару ключей, также является фактором, определяющим, насколько другой объект может доверять вашему веб-сайту. Как правило, для идентификационных сертификатов (например, сертификатов сервера SSL) рекомендуется, чтобы клиент (Мой интернет-магазин) сгенерировал ключ.
• Вы отправите запрос сертификата в стандартном формате (пример: PKCS10) в ЦС. Он будет включать в себя кучу информации о My e-Shop и открытый ключ.
• Компания CA проверит ваши документы и удостоверится, что это вы. Затем он будет использовать свой ЦС для цифровой подписи сертификата для вас. Этот сертификат содержит информацию, которую вы только что предоставили, некоторую дополнительную информацию, которую устанавливает для вас поставщик ЦС, ваш открытый ключ и цифровую подпись, сгенерированную путем криптографической привязки всех вышеупомянутых данных к закрытому ключу ЦС.

Вы получаете обратно одну из двух вещей:

• только сертификат (если вы создали свою собственную пару ключей)
• сертификат и пара ключей — если ЦС сгенерировал для вас пару ключей

(2) Выданный сертификат заполняется моей информацией и открытым ключом и хранится в некотором файле на моем веб-сервере. Сертификат подтверждает, что «Мой интернет-магазин» не является конторой воров.

да... вроде. Вашему веб-серверу потребуется как подписанный сертификат, так и пара ключей. Пара ключей используется как часть рукопожатия SSL для конечного пользователя, и этот обмен доказывает, что вы владеете парой ключей, а не какая-то банда воров, которые получили в свои руки сертификат. Вот почему вы хотите защитить пару ключей.

(3) Каждый раз, когда пользователи получают доступ к «Моему интернет-магазину» через «https», их браузеры «молча» сверяют представленный сертификат «Моего интернет-магазина» с тем, который зарегистрирован в ЦС.

Для некоторого определения «молчание». Базовый браузер проверяет, что сертификат: - в настоящее время действителен - подписан ЦС, которому браузер доверяет (или он либо отказывает в доступе, либо выдает раздражающее всплывающее окно)

Надстройки браузера пойдут еще дальше и будут выполнять такие функции, как проверка полного пути (вплоть до самоподписанного корня) и проверка статуса сертификата. Чем выше риск обмена информацией по каналу, тем больше проверок требуется.

(4) Когда какой-либо пользователь входит в «Мой интернет-магазин» через https, происходит следующее: «Мой интернет-магазин» (веб-сервер) получает открытый ключ (PK1) пользователя. Сервер молча представляет пользователю сертификат «Моего интернет-магазина», поэтому пользователи получают открытый ключ (PK2) «Моего интернет-магазина». После некоторой молчаливой проверки браузер пользователя проверяет представленный сертификат и устанавливается безопасный канал.

• Что насчет пользователей? Генерируют ли их браузеры локальные открытые и закрытые ключи при входе в «Мой интернет-магазин» через https?

ОК - здесь что-то идет не по плану.

Для получения подробной информации проверьте протокол SSL - раздел рукопожатия предоставит вам неопровержимые факты.

Браузер и веб-сервер передают туда и обратно информацию, которая позволяет им создать ключ шифрования сеанса. Браузер генерирует некоторый исходный материал, используемый для настройки сеанса, но это не «открытый ключ пользователя (PK1)». Пользователю не нужно иметь учетные данные PKI, ЕСЛИ сервер не настроен для проверки подлинности клиента. В обычном режиме My e-Shop сервер имеет учетные данные PKI, а браузер генерирует некоторый ключевой материал на лету только для одного сеанса. Сервер абсолютно не знает, кто является пользователем браузера, с точки зрения SSL - вся идентификация пользователя происходит из пароля или чего-то еще на уровне приложения.

ПРИМЕЧАНИЕ. Это относится к обычной коммерческой транзакции. Чем выше риск, тем больше защита. Транзакции с высоким риском часто требуют аутентификации клиента.

(5) Когда пользователь отправляет запрос через безопасный канал, запросы шифруются открытым ключом «Моего интернет-магазина». Затем веб-сервер расшифровывает запрос своим закрытым ключом. Затем веб-сервер отправляет зашифрованный ответ с открытым ключом пользователя. В конце браузер пользователя расшифровывает ответ своим закрытым ключом.

Не совсем. Это сорняки - разработчик веб-приложения относительно абстрагирован от всего этого. Но — содержимое сеанса не зашифровано асимметричными ключами — это было бы мучительно интенсивно для ЦП. PKI сервера и данные рукопожатия, генерируемые браузером на лету, используются для обмена ключом шифрования сеанса. Частью этого является то, что клиент выбирает и отправляет секретный ключ, зашифрованный в открытом ключе сервера. Поскольку закрытый ключ есть только у сервера, только сервер может расшифровать данные, отправленные клиентом.

Этот секретный ключ является симметричным (какой именно алгоритм является частью рукопожатия) и используется до конца сеанса.

Ваши шаги неверны на нескольких разных уровнях. Позвольте мне переформулировать их, надеюсь, в ясной форме.

1. Ваш сайт должен иметь SSL-сертификат от доверенного стороннего центра сертификации (Verisign и т. д.). Вам нужно будет купить его у них. Вы сгенерируете пару открытый/закрытый ключ, предоставите им свой открытый ключ (это часть запроса на сертификат), и они сгенерируют сертификат.

2. Сертификат содержит доменное имя вашего сайта, ваш открытый ключ и некоторую другую дополнительную информацию. Он ничего не подтверждает, особенно то, что ваш сайт не является «воровской конторой». Все, что он обычно подтверждает, это то, что вы владеете доменным именем, для которого запрашиваете сертификат. Это не означает, что ваш сайт заслуживает доверия ни в коем случае.

3. Когда пользователь получает доступ к вашему сайту через HTTPS, ваш сервер отправит сертификат в браузер клиента. Клиент никогда не связывается с центром сертификации для проверки вашего сертификата.

3.1. Как правило, конечным пользователям (клиентам, заказчикам) не нужны собственные сертификаты и закрытые ключи. Это называется SSL с взаимной аутентификацией, и обе стороны (ваши клиенты и ваш сайт) имеют сертификат. Это редко (если вообще) используется на сайтах электронной коммерции.

1. Когда пользователь заходит на ваш сайт через HTTPS, ваш сервер отправляет сертификат в клиентский браузер. Клиент будет использовать это для выполнения рукопожатия SSL. Это рукопожатие между браузером и вашим сайтом устанавливает безопасный туннель. Специфика протокола рукопожатия более техническая, чем вам нужно.

2. Когда запрос отправляется на сервер через туннель SSL, сервер обрабатывает его так же, как и любой другой запрос. Единственная разница в том, что связь между вашими клиентами и вашим сервером зашифрована. Ваш веб-сервер, скорее всего, выполнит расшифровку данных из запроса и представит их вашему веб-серверу для обработки. Точно так же данные ответа возвращаются обратно клиенту в зашифрованном виде через туннель SSL.

Лучше?

По пункту 3:

Насколько я знаю, это не совсем правильно. Поскольку на самом деле нет установленной инфраструктуры живого тестирования (по сравнению с такими службами, как DNS), веб-сервер будет отправлять полную цепочку сертификатов в браузер. С другой стороны, браузер или операционная система поставляется с набором доверенных корневых сертификатов (которые необходимо иногда обновлять, обновлять Windows, выпускать новые версии браузера и т. д.).

И да, предполагается, что браузер сгенерирует «ненадежную» пару ключей, поскольку в обычных условиях обычный пользователь не будет генерировать свой собственный сертификат.

По пункту 5:

Также это не совсем правда. Вычисление асинхронного шифрования требует большого количества времени. Таким образом, алгоритм RSA просто используется для обмена ключами для более быстрых стандартов синхронного шифрования (например, AES, 3TES).