Общие сведения о SSL

Ответ 1

Идентификатор SSL характеризуется четырьмя частями:

• Закрытый ключ, который не используется никому.

• Открытый ключ, с которым вы можете поделиться с кем-либо.

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

• Метаданные, прикрепленные к открытому ключу, которые указывают, о чём это говорит. Для ключа сервера это идентифицирует DNS-имя службы, которая защищена (между прочим). Другие данные здесь включают такие вещи, как предполагаемое использование (в основном используется для ограничения размера ущерба, которое может сделать кто-то с украденным сертификатом), и срок действия (чтобы ограничить срок использования украденного сертификата).

• Цифровая подпись на комбинации открытого ключа и метаданных, с тем чтобы их нельзя было перепутать и чтобы кто-то еще знал, насколько доверять метаданным. Существует несколько способов обработки, кто выполняет подпись:

  • Подписание с помощью закрытого ключа (из части 1 выше); самозаверяющий сертификат. Любой может это сделать, но он не несет большого доверия (именно потому, что каждый может это сделать).
  • Получение группы людей, которые доверяют друг другу, чтобы поручиться за вас, подписав сертификат; веб-доверие (так называемое, потому что доверительные отношения транзитивны и часто симметричны, поскольку люди подписывают сертификаты друг друга).
  • Получение доверенной третьей стороны для подписания; центр сертификации (CA). Идентификация ЦС гарантируется другим ЦС более высокого уровня в цепочке доверия обратно к некоторому корневому авторитету, которому доверяет "каждый" (т.е. Есть список, встроенный в вашу библиотеку SSL, которую можно обновить во время развертывания).

  Нет принципиальной технической разницы между тремя типами полномочий выше, но характер доверенных людей, вложенных в них, чрезвычайно переменчив. Детали того, почему это нужно, потребуют очень долгого ответа!

Элементы 2-4 представляют собой цифровой сертификат.

Когда клиент, B, запускает протокол SSL с сервером, A, цифровой сертификат сервера передается B как часть протокола. Закрытый ключ не отправляется, но поскольку B может успешно расшифровать сообщение, отправленное другим концом с открытым ключом в цифровом сертификате, B может знать, что A имеет закрытый ключ, который соответствует. B затем может посмотреть метаданные в сертификате и увидеть, что другой конец утверждает, что он A, и может проверить подпись, чтобы увидеть, насколько доверять этому утверждению; если метаданные подписываются авторитетом, которому B доверяет (прямо или косвенно), тогда B может доверять тому, что на другом конце есть идентификатор SSL. Если это то, что они ожидали (то есть, они хотели поговорить с A: на практике это делается путем сравнения имени DNS в сертификате с именем, которое они использовали при поиске адреса сервера), тогда они могут знайте, что у них есть защищенный канал связи: им хорошо идти.

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

• Закрытый ключ. Владелец идентичности должен позаботиться о том, чтобы это не произошло, но в конечном итоге оно находится в их руках.
• Доверенный орган, который делает ложные утверждения. Здесь случаются некоторые недостатки - самозаверяющая власть никогда не бывает очень надежной, сеть доверия сталкивается с проблемами, потому что доверие - это неудобная вещь, которая обрабатывает транзитивно, а некоторые ЦС полностью беспринципны, а другие слишком склонны не исключать смуту - но в основном это работает достаточно хорошо, потому что большинство сторон стремятся не вызывать проблем, часто по финансовым причинам.
• Способ отразить DNS так, чтобы цель полагала, что другой сервер действительно является олицетворением. Без DNSsec это довольно легко, к сожалению, но эта конкретная проблема уменьшается.

Что касается ваших других вопросов...

Зачем использовать хэширование сертификата, если его часть уже зашифрована CA? Разве это не означает, что никто не может возиться с цифровым сертификатом (с большой вероятностью)?

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

Если я - stackoverflow, и у меня есть 3 сервера, которые делают то же самое - позволяя клиентам получать доступ, читать, идентифицировать и т.д. - мне нужно иметь другой цифровой сертификат для каждого из трех серверов.

Если у вас несколько серверов, обслуживающих одно и то же DNS-имя (существует много способов сделать это, одним из самых простых из которых является циклическое DNS-обслуживание), вы можете установить одинаковый идентификатор для каждого из них. Это немного снижает безопасность, но лишь незначительно; это еще одна услуга, которая просто реализуется несколькими серверами. В теории вы могли бы дать каждому отдельную личность (хотя и с тем же именем), но я не могу придумать какой-либо веской причины для ее фактического выполнения; он скорее будет беспокоить людей, чем альтернативу.

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

Ответ 2

Мой вопрос не может "B" просто взять этот сертификат, таким образом украсть личность "A", что позволит им аутентифицироваться как "A" на "C"

Также есть частная часть сертификата, которая не передается (закрытый ключ). Без закрытого ключа B не может аутентифицироваться как A. Точно так же я знаю ваше имя пользователя StackOverflow, но это не позволяет мне войти в систему как вы.

Зачем использовать хэширование сертификата, если его часть уже зашифрована CA?

Таким образом, любой может проверить, что именно CA создал хэш, а не кто-то другой. Это доказывает, что сертификат был подготовлен CA, и, таким образом, "проверка и т.д.", был выполнен.

Если я - stackoverflow, и у меня есть 3 сервера, которые делают то же самое - позволяя клиентам получать доступ, читать, идентифицировать и т.д. - мне нужно иметь другой цифровой сертификат для каждого из трех серверов.

Это зависит от конкретного случая, но вы, вероятно, будете иметь одинаковые сертификаты для каждого.

Ответ 3

Первый вопрос: вы правы в том, что вы вернетесь из центра сертификации, но вам не хватает части того, что вам нужно, прежде чем отправлять запрос в ЦС. Вам необходимо (1) запрос сертификата и (2) соответствующий закрытый ключ. Вы не отправляете закрытый ключ как часть запроса; вы держите его в секрете на своем сервере. Ваш подписанный сертификат включает копию соответствующего открытого ключа. Прежде чем любой клиент будет считать, что B "владеет" сертификатом, B должен доказать это, используя секретный ключ, чтобы подписать вызов, отправленный клиентом. B не может сделать это без закрытого ключа.

Второй вопрос: типичная криптография с открытым ключом работает с данными фиксированного размера (например, 2048 бит) и является довольно дорогостоящей вычислительной машиной. Таким образом, для цифровой подписи документа произвольного размера документ хэшируется до блока фиксированного размера, который затем зашифровывается закрытым ключом.

Третий вопрос: вы можете использовать один сертификат на нескольких серверах; вам просто нужен соответствующий закрытый ключ на всех серверах. (И, конечно, DNS-имя, используемое для доступа к серверу, должно соответствовать CN в сертификате, или клиент, скорее всего, откажется. Но одно DNS-имя относится к нескольким серверам, является обычным и простым средством балансировки нагрузки.)

Ответ 4

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

Это эквивалент создания точного дубликата Статуи Свободы в Антарктике с ожиданием кражи доходов от туризма в Нью-Йорке. Если вы не начнете взламывать каждую книгу туристических путеводителей и учебник по истории, чтобы заменить "Нью-Йорк" Антарктидой, все по-прежнему отправятся в Нью-Йорк, чтобы увидеть настоящую статую, и вор будет просто иметь очень большую, зеленую, полную холостую сосульку.

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

Ответ 5

У меня также есть некоторые ответы.

Q1) Если B крадет сертификат и пытается выдавать себя за него от A до C.

• C проверит IP-адрес B и узнает, что он не принадлежит C. Затем он прекратит соединение SSL. Конечно, даже если C отправляет зашифрованное сообщение, тогда только Real A сможет его расшифровать.

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

Ответ 6

Вопрос № 1

не может B просто взять этот сертификат [...], который позволит им аутентифицироваться как A-C

Эта часть более крупной диаграммы имеет дело с этот вопрос.

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

Вопрос № 2

Зачем использовать хеширование сертификата, если его часть уже зашифрованный CA?

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

Вопрос № 3

Если я - stackoverflow, и у меня есть 3 сервера [...], я должен иметь другой цифровой сертификат для каждого из трех серверов.

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

Напротив, если у вас есть один сервер, на котором размещается несколько доменов, у вас будет один сертификат SSL с несколькими доменами.