#https #cryptography #certificate #tls1.2
#https #криптография #сертификат #tls1.2
Вопрос:
Итак, я пытаюсь понять, как на самом деле работают сертификаты — я не смог найти то, что именно я ищу в Google, поэтому я формулирую это по-своему… Если есть прямая ссылка, которая, по вашему мнению, может мне помочь — пожалуйста, опубликуйте ее, и я удалю этот вопрос.
Я понимаю, что когда клиент (скажем, браузер) отправляет запрос на веб-сайт, он проверяет подлинность веб-сайта, проверяя его сертификат. Самозаверяющие сертификаты не поощряются, а сертификаты от Центра сертификации (и его филиалов) являются реальной сделкой. Теперь, когда идентификация была проверена, запрос обрабатывается сервером, а ответ отправляется клиенту, и теперь пользователь (человек) может видеть этот зеленый знак блокировки в своем браузере рядом с URL. Я правильно суммировал это? И этот ответ зашифрован и будет расшифрован браузером / клиентом?
В случае потоков единого входа (единого входа) — когда утверждения SAML имеют «цифровую подпись» — что именно это означает? И как вышеупомянутые сертификаты помогают в этом?
У меня просто слишком много концепций, все смешалось в моей голове, и я искал ясности в понимании систем, безопасности и TLS.
Комментарии:
1. Вы близки к использованию сертификатов для HTTPS (веб) и других SSL / TLS, за исключением того, что существует не один центр сертификации, а несколько независимых — в настоящее время наиболее широко используются 5 , но в хранилищах доверия браузера или ОС обычно ~ 100. Канонические ответы для SSL / TLS закончены на безопасности. SX , где это более по теме. Для Интернета после установления и защиты соединения HTTPS (или WebRTC) может быть несколько запросов и ответов. …
2. … SSO и SAML — это совершенно разные вещи и не связаны с SSL / TLS, хотя они могут использовать одни и те же технологические стандарты для сертификатов. Если у вас есть более конкретные вопросы о них, безопасность. SX, вероятно, подходит и для них.
3. И для каждого последующего запроса и ответа проверяется ли сертификат каждый раз?
4. Это зависит от проверяющей стороны (сторон), которая обычно является только клиентом = браузером, хотя я подозреваю, что большинство проверяет только при рукопожатии. Однако соединения обычно простаивают только короткое время — возможно, несколько минут. Это все равно может допускать десятки или сотни запросов на соединение, особенно с современными веб-проектами, и в течение этого срока срок действия не представляет особой проблемы.
Ответ №1:
Прежде всего, это все об асимметричной криптографии. Это позволяет зашифровать сообщение одним ключом и расшифровать другим. Почему это полезно.
Безопасное взаимодействие
Вы можете отправить сообщение на свой сервер, используя открытый ключ этого сервера. Таким образом, вы можете быть уверены, что никто другой (кроме этого сервера) не сможет расшифровать это сообщение
Цифровая подпись
Вы можете зашифровать дайджест сообщения своим закрытым ключом, и любой желающий сможет проверить, были ли это вы, расшифровав вашу «подпись» с помощью вашего открытого ключа.
На каком этапе задействован сертификат
В обоих приведенных выше случаях есть подводный камень. Вы не можете быть действительно уверены, что открытый ключ, который предоставляет вам сервер, действительно является ключом стороны, которой вы доверяете. То же самое с подписями. Вы не можете быть уверены, что открытый ключ, который вы только что успешно использовали для проверки подписи, действительно является ключом человека, которого вы ожидаете подписать ваш контракт.
Сертификат представляет собой набор открытого ключа и информации о владельце пары ключей. Этот пакет имеет цифровую подпись с помощью закрытого ключа центра сертификации.
Что такое сквозной процесс
Давайте рассмотрим случай https. Ваш клиент говорит серверу: «Эй, я хочу использовать протокол https». Это точка, в которой задействована асимметричная криптография. Вы используете открытый ключ сервера для шифрования симметричного ключа (поскольку асимметричная криптография несколько дорогая, она используется только при согласовании симметричного ключа), который будет использоваться для шифрования трафика.
Но как вы можете быть уверены, что можете доверять этому серверу. На самом деле сервер отправляет вам не просто ключ, а сертификат. Вы берете сертификат и проверяете, что имя сервера, указанное в сертификате, на самом деле соответствует тому, что вы использовали в адресной строке. Вы также проверяете подпись центра сертификации, используя открытый ключ этого центра сертификации.
Цепочка сертификации
Открытый ключ центра сертификации, который подписал сертификат сервера, также может потребовать проверки. Такая проверка выполняется так же, как описано выше. Цепочка должна в конечном итоге остановиться на сертификате, которому вы абсолютно доверяете. Такие сертификаты хранятся в так называемом хранилище доверия.
Итак, вот как работает ssl. Утверждения SAML с цифровой подписью работают очень похожим образом. Они предоставляют сертификаты, которые вы можете проверять и использовать извлеченные из них открытые ключи для проверки подписи утверждений.
Комментарии:
1. Я вижу! Итак, что происходит, когда я генерирую утверждение SAML и подписываю его — я подписываю его, используя свой закрытый ключ, верно? И в утверждении я включаю информацию об открытом ключе? Поэтому, когда поставщик услуг получает эту информацию об открытом ключе и дайджест, он расшифровывает с использованием информации об открытом ключе и подтверждает действительность. Правильно ли я понял это? Я предполагаю, что моя проблема заключается в понимании того, как работает шифрование / дешифрование, когда закрытый ключ известен только одной стороне, и как другая сторона «выясняет это» и расшифровывает 🙂
2. Если мы говорим о подписях, вы можете думать о закрытом ключе как о пароле, который используется для шифрования (вы храните его в своем защищенном месте), а об открытом ключе как о пароле, который используется для расшифровки (он может быть у каждого). Итак, в SAML вы подписываете утверждение своим закрытым ключом и предоставляете сертификат, содержащий ваш открытый ключ (поскольку он не является секретным).
3. Клиент проверяет сертификат (либо ищет его в своем хранилище доверия, либо проверяет, что CA, подписавший сертификат, имеет свой сертификат в хранилище доверия клиента), если все в порядке, он принимает этот ключ (он же общедоступный пароль для расшифровки), вычисляет дайджест сообщения, затем расшифровывает зашифрованный дайджест (он жеподпись) сообщения и сравнение двух значений. Если они идентичны, то считается, что сообщение действительно было подписано владельцем сертификата.. Что касается того, какая конкретная математика лежит в основе асимметричной криптографии, боюсь, я не смогу четко объяснить. Обратитесь к описанию алгоритма RSA.
4. О, я не искал математику, стоящую за этим, просто пытался понять процесс. Судя по вашему объяснению, проверка сертификата — это другой процесс, который происходит до проверки их ключа, я прав?
5. Вы имеете в виду до проверки подписи? ДА. Прежде всего, сертификат должен быть проверен. В противном случае нет доверия ко всему. Вы можете прочитать больше о проверке сертификатов здесь oasis-pki.org/pdfs/Understanding_Path_construction-DS2.pdf