Comments 18
Я не очень понимаю, если можно объясните:
- зачем нужны корневые центры сертификации для Domain Validation — которые просто подтверждают что общение идёт с https://домен.рф? чем такой сертификат отличается от самоподписанного? почему продавцы доменых имён не генерируют простые сертификаты Domain Validation при регистрации домена ?
- насколько замедляется доступ к сайту пока браузер проверяет его сертификат? Насколько критично если центр сертификации находится в США/КНР, а не в Европе ?
- Есть ли российские сертификаты? т.е. центры сертификации в РФ, а не продавцы американских сертификатов
- Если компания сделала мне сертификат Domain Validation значит ли это что она технически легко может расшифровать https трафик между сайтом и браузером, если сможет его перехватить ?
Let's Encript примерно месяц назад стал поддерживать кириллические домены, но его придётся обновлять раз в 3 месяца + ставить доп. ПО. А StartSSL — американские компании задавили.
Если кому надо вот описание и настройки:
https://тхаб.рф/wiki/Установка_SSL-сертификата_Let%27s_Encript_для_кириллического_домена_на_Apache
- В конце статьи см. ссылку "цепочки сертификатов"
- Зависит от массы факторов.
- Да.
- Нет. При правильной процедуре выдачи закрытый ключ сертификата не покидает контролируемого вами устройства. А компания выдаёт вам открытый ключ, который вы смело можете показывать всему миру.
1. Затем, что без какой-то третей стороны которая служит точкой доверия нельзя установить зашифрованное соединение. Если вы будете отсылать самоподписанный сертификат, злоумышленник может перехватить ваш ответ и отправить свой самоподписанный сертификат клиенту. Клиент никак не сможет этого заметить.
Центры сертификации решают эту проблему так, что они выступают третей стороной, которой доверяет клиент. Злоумышленник не может просто самоподписать и отправить сертификат клиенту, ему нужна будет подпись центра, иначе клиент поднимет тревогу.
Центры сертификации решают эту проблему так, что они выступают третей стороной, которой доверяет клиент. Злоумышленник не может просто самоподписать и отправить сертификат клиенту, ему нужна будет подпись центра, иначе клиент поднимет тревогу.
- А в Казахстане сейчас именно для этого обязали все сайты получать сертификаты в местном центре? Чтобы КНБ Казахстана мог их подменять при необходимости?
- т.е. если США имеют доступ к сертификатам Летс Ен Крипт, то они могут при необходимости подменить сертификат Гмайл на подписанный АНБ сертификат и читать почту, смотреть операции в онлайн банке ?
2. Да, могут. Хотя честно говоря, мне кажется они и так могут почитать почту, когда захочется, без подмены всяких там сертификатов и перехвата трафика.
Такие CA (удостоверяющие центры) быстро потеряют доверие и будут исключены разработчиками из списков доверенных.
Такая же история случилась с казахскими центрами. Кто-то из представителей власти написал в mozilla пост с просьбой о включении казахского УЦ в список доверенных. Однако пользователи быстро описали, что казахские власти хотят сделать, поэтому им было однозначно отказано.
Такая же история случилась с казахскими центрами. Кто-то из представителей власти написал в mozilla пост с просьбой о включении казахского УЦ в список доверенных. Однако пользователи быстро описали, что казахские власти хотят сделать, поэтому им было однозначно отказано.
Хммм.
- Корневые центры сертификации считаютсякем? доверенными лицами в трехсторонней схеме сервер-ЦС-клиент. Сервер доверяет ЦС в том, что его сертификат не будет подменен этим ЦС и в том, что ЦС без ведома сервера (точнее, его админов, кто управляет разворачиванием сертификатов на веб-серверах) не выпустит ещё один сертификат на то же имя, которое использует сервер (hostname). Клиент доверяет ЦС в том, что ЦС выдал сертификат именно тому серверу, на котором находится интересующий клиента ресурс, и в том, что этот сертификат не скомпрометирован третьей стороной. Клиент имеет возможность выбирать, каким корневым ЦС он доверяет, с помощью редактирования своего списка сертификатов доверенных корневых ЦС. Поэтому сертификат ЦС от самоподписанного отличается только тем, что к нему есть доверие не только у сервера, но и у клиента.
- Зависит от доступности точки распространения списков отзыва сертификатов, если таковая указана в сертификате, и размера самого списка. Однако такая проверка проводится один раз за сессию связи TLS, которую браузеры и серверы из-за накладных расходов стараются не закрывать.
- Есть где-то. Как минимум сертификаты для отправки налоговой или бухгалтерской отчетности выдаются российским ЦС. Насчет сертификатов для веб-серверов — не знаю.
- Нет, поскольку закрытый ключ от сертификата ЦС не получает в момент обработки запроса на сертификат. Мало того, из-за технологии Forward Secrecy перехват трафика ничего не даст, даже если впоследствии закрытый ключ сервера достанется атакующему. Вот после того, как закрытый ключ был получен кем-то ещё, тогда получивший закрытый ключ может перехватить и расшифровать трафик в защищенном соединении. Но для этого есть механизм отзыва сертификата, который должна инициировать СБ сервера, после чего запросить новый сертификат, создав новый, недоступный (по возможности СБ) другим закрытый ключ, а открытый от него предоставить ЦС для выпуска нового сертификата.
Надеюсь, более-менее понятно объяснил.
У вас на картинке, объясняющей шифрование, фундаментальная ошибка, хотя в тексте описание верное. Передаваемые данные НЕ шифруются публичными ключами — несимметричная криптография крайне затрата с точки зрения вычислительных ресурсов. Несимметричные ключи нужны для того, чтобы обменяться симметричным сессионным ключом, с помощью которого уже и идет шифрование.
ECC (Elliptic Curve Cryptography) определяет пару ключей с помощью точек на кривой и используется только для цифровой подписи.
Да? А вот, например, в TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 для обмена ключами что используется? :)
В итоге надежной кажется только схема, когда ключи передаются через флешки или голубиной почтой.
Для личного использования (или небольшой рабочей группы, компании) по моему подойдёт самоподписанный сертификат + браузер FF который позволяет такие сертификаты добавлять в доверенные после чего лишних сообщений не выскакивает. С Гугл Хром и Яндекс.Браузер такие номера не проходят :(
Если main-in-the-middle перехватит соединение и предоставит сертификат на ваш домен, подписанный каким-нибудь подконтрольным ему VeriSign (которому Firefox доверяет), клиент увидит в браузере, что соединение доверенное, но подмену сможет обнаружить, только закопавшись в свойствах сертификата (сверив серийный номер и хеш). Разве нет?
У меня только поверхностные знания в области SSL/TLS, шифровании, сертификатах и т. д. Из любопытства я иногда почитываю разные статьи на эту тему и пытаюсь разобраться как это устроено. У всех этих статей есть один общий недостаток, присущий и этой статье. А именно несоблюдение терминологии. В первом абзаце вводится определение SSL как протокола, а через несколько строк употребляется уже какой-то SSL-сертификат. А что это такое?? Что такое ключ шифрования? Чем он отличается от алгоритма шифрования? И т. д. и т. п.
В общем, сначала вводятся одни термины, а потом используются другие.
В общем, сначала вводятся одни термины, а потом используются другие.
>>> Всем известно, что сертификаты обеспечивают надежное соединение
Ну вы серьезно?.. сертификаты не обеспечивают надежного соединения… и даже криптография его не обеспечивает… его обеспечивает довольно большой комплекс решений.
Ну вы серьезно?.. сертификаты не обеспечивают надежного соединения… и даже криптография его не обеспечивает… его обеспечивает довольно большой комплекс решений.
Пост называется «как это работает», но я не увидел даже высокоуровнего описания протокола. Нет ни положения в OSI, не написано как происходит согласование криптографических параметров, нет даже малейшего намека на техничность статьи. Ваш вариант с шифрованием секрета на клиенте и передачей на сервер уже давно устарел. HMAC не единственный вариант аутентификации сообщений, есть еще cbc-mac, aes-eax например.
Большая часть статьи про сертификаты, которые отношение к TLS хоть и имеют, но не составляют его большую часть. Это относится больше к проблемам обмена ключами в небезопасном канале.
Советую почитать статью «Анализируем TLS не выходя из комы», чтобы хоть немного понять как он работает.
Большая часть статьи про сертификаты, которые отношение к TLS хоть и имеют, но не составляют его большую часть. Это относится больше к проблемам обмена ключами в небезопасном канале.
Советую почитать статью «Анализируем TLS не выходя из комы», чтобы хоть немного понять как он работает.
Sign up to leave a comment.
«Как это работает»: знакомство с SSL/TLS