Что делает SSL безопасным?

Question

Я читал несколько сайтов в интернете о том, как работает SSL, но я не понимаю, как именно он обеспечивает безопасность.Возможно, потому что я не совсем понимаю, как это работает.

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

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

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

Спасибо, что объяснили заранее.

Answer 1

Во-первых, некоторые основные понятия о криптографии с открытым ключом:

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

Чтобы убедиться, что вы общаетесь с нужным объектом, вам необходимо привязать идентификатор к паре ключей. Именно здесь приходят сертификаты. Сертификат открытого ключа - это подписанный документ, содержащий как личность (имя) субъекта, так и открытый ключ субъекта. Например, сертификат для www.google.com содержит его открытый ключ и имя www.google.com. Он был подписан с использованием закрытого ключа центра сертификации (в данном случае Thawte). В терминологии X.509 (общий стандарт для сертификатов, используемых для HTTPS), CA является издателем сертификата, и он также помещает свое имя в сертификат, наряду с именем субъекта, открытым ключом субъекта (и другими атрибутами) , Эмитенты предназначены для проверки личности того, для кого они выдают сертификат.

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

Возможно, вы захотите прочитать больше о рукопожатии TLS , но вкратце:

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

Для обеспечения безопасности SSL / TLS вам необходимо как минимум 3 пункта:

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

(Это относится к подавляющему большинству случаев использования SSL / TLS (в частности, HTTPS), но также возможно использовать другие механизмы, кроме сертификатов X.509 с TLS, например, сертификат OpenPGP или наборы шифров Kerberos. насколько я знаю, встречается реже)

Answer 2

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

Для шифрования или подписи (сертификатов) вы можете использовать асинхронные ключи. Это означает, что у вас есть два разных ключа (открытый и закрытый) для шифрования / дешифрования. Обычно вы шифруете свои данные с помощью открытого ключа, и кто-то может расшифровать их с помощью своего закрытого ключа. Подписание выполняется с помощью вашего закрытого ключа, и кто-то другой может проверить его с помощью открытого ключа.

Итак, вы видите, подделать сертификат не так просто, поскольку у вас нет закрытого ключа от поставщика корневых сертификатов.

Answer 3

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

Нет.Ключ никогда не передается.Он вычисляется на обоих концах независимо друг от друга с помощью алгоритма согласования ключей.

Что мешает мошенническому серверу подделывать сертификат, подписанный поставщиком корневого сертификата?

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

Answer 4

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

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

Если у X и Y есть какие-либо ранее существующие средства обмена информацией друг с другом таким образом, что они могут декодировать ее намного быстреечем Z, даже если это не очень безопасно, этого может быть достаточно для предотвращения вышеописанной атаки "человек посередине".Все, что должно произойти, это чтобы X и Y спросили друг друга о ключе, который они используют.Если Z сможет распознать этот вопрос и заменить свой ответ, он сможет продолжить хитрость.С другой стороны, если бы вопрос задавался таким образом, чтобы законная сторона могла ответить гораздо быстрее, чем самозванец, Z мог бы оказаться в тупике.Например, если приложение голосового телефона отображало для каждого участника информацию о согласованном ключе, и одна из сторон попросила другую «прочитать цифры с 12 по 18 вашего ключа, производя наилучшее впечатление об Элмере Фадде» (выбрав наместо, цифры для чтения и голос для использования) законный участник сможет ответить немедленно, но злоумышленнику потребуется время, чтобы произвести фальшивую запись о человеке, говорящем, как указано).