Открытый ключ ЦС и открытый ключ сервера: что следует использовать для установки HTTPS-соединения?

Мне нужно создать клиентскую библиотеку для связи с одной службой (скажем, google.com) через HTTPS. Я хотел бы, чтобы библиотека поставлялась со всеми данными (сертификат или ключ), необходимыми для аутентификации службы.

Я запутался, какими должны быть эти данные. Должен ли это быть открытый ключ центра сертификации, подписавшего сертификат google.com? Или это должен быть открытый ключ google.com?

Во всех примерах, которые я видел, открытый ключ центра сертификации используется для аутентификации соединения. Но кажется ненужным. Если моя библиотека взаимодействует только с google.com, могу ли я получить и сохранить открытый ключ google.com по защищенному каналу (в браузере), а затем использовать этот ключ напрямую для установления аутентифицированных соединений без повторного использования ключа ЦС?


ssl https security public-key-encryption
person Jan Wrobel    schedule 02.01.2013    source источник
comment
Это не то, как работает SSL. Вам просто нужен доверенный корневой ЦС, чтобы вы могли проверить сертификат, который отправляет сервер.   -  person SLaks    schedule 02.01.2013
comment
@SLaks Но я так понимаю, что центры сертификации были введены для аутентификации большого количества сайтов без хранения всех их ключей на стороне клиента (кошмар управления). Если библиотека общается с одним сервером и имеет открытый ключ этого сервера, нужна ли еще проверка сертификата (если сертификат подделан, открытый ключ все равно не будет работать)?   -  person Jan Wrobel    schedule 02.01.2013
comment
Ты прав; вы можете хранить один открытый ключ и требовать, чтобы сервер использовал этот ключ. Однако это делает невозможным замену ключа, поэтому существуют PKI и CRL. Что бы вы сделали, если бы секретный ключ был скомпрометирован?   -  person SLaks    schedule 02.01.2013
comment
@SLaks Это действительно проблема, если закрытый ключ скомпрометирован, все клиенты должны быть обновлены. Но аналогичным образом, если ключ ЦС скомпрометирован или сервер меняет ЦС, все клиенты должны быть обновлены. Эта проблема возникает, когда библиотека поставляется с минимально возможным набором ключей, необходимых для аутентификации сервера (часто рекомендуемый подход). Например, HTTP-библиотека Ruby не использует ключи ЦС по умолчанию, поэтому рекомендуется добавлять как можно меньше ключей: verify-an-ssl-certificate" title="почему ruby ​​не может проверить сертификат ssl"> stackoverflow.com/questions/9199660/   -  person Jan Wrobel    schedule 02.01.2013
comment
Будем надеяться, что корневые центры сертификации могут применять более эффективные меры безопасности, чем вы. en.wikipedia.org/wiki/Key_Ceremony   -  person SLaks    schedule 02.01.2013

Ответы (1)


arrow_upward
2
arrow_downward

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

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

Изменить на основе вашего комментария:

Есть больше преимуществ в доставке сертификата ЦС, а не только сертификата сервера.

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

Если вы отправили сертификат своего сервера, вам понадобится способ безопасного обновления сертификата на каждом клиенте.

person mfanto    schedule 02.01.2013
comment
Вопрос не в сервере, а в клиенте. Почему клиент должен поставляться с ключом CA для аутентификации сервера и не может быть отправлен напрямую с открытым ключом сервера (который был получен и проверен с помощью браузера)? - person Jan Wrobel; 02.01.2013
comment
Обновленный ответ. Если ЦС доверенный, то ничего особенного делать не нужно. Это также проще в случае компрометации, поскольку центр сертификации легче защитить, и вам не нужно будет обновлять клиент с новым сертификатом сервера. - person mfanto; 02.01.2013
comment
Ваш ответ противоречит сам себе после редактирования, но ему не нужно использовать чью-либо пару ключей: ему нужно использовать сертификат, который содержит только открытый ключ; и он должен отправить сертификат самого высокого подписавшего. Открытый ключ сервера не используется для шифрования чего-либо в SSL, но он используется клиентом для проверки подписи, сгенерированной сервером, в качестве доказательства того, что он владеет этим сертификатом. - person user207421; 03.01.2013
comment
Это не противоречит само по себе, я просто мог быть не ясен в своей формулировке. Я почищу это. Но предварительный секрет шифруется открытым ключом сервера во время процесса рукопожатия. См. шаг 4 publib.boulder.ibm.com/infocenter/wmqv6/v6r0/ - person mfanto; 03.01.2013
comment
Извиняюсь, я немного неаккуратно с "ключевой парой" в процессе редактирования. - person mfanto; 03.01.2013