Мой наставник говорит, что очень легко получить самозаверяющий сертификат с существующими доменными именами, это вообще возможно?
Технически, да, вы можете создать себе любой сертификат с любым именем, самостоятельно подписанный или подписанный ЦС, который вы контролируете. Это однострочная команда с библиотекой наподобие openssl, здесь нет никакой магии, так как это не то, где Web PKI получает свою функцию аутентификации (это происходит от , который подписывает сертификат).
На этом собственном веб-сайте вы найдете множество ответов о том, как создавать самозаверяющие сертификаты на любое имя по своему вкусу.
Браузер будет проверять этот сертификат, полученный от сервера (законный или взломанный), на основе списка ЦС, который он имеет в доверенном органе (или свой собственный, или какой-то другой ОС). По умолчанию у него не будет никакого ЦС, которым вы управляете, поэтому он по умолчанию отклонит этот сертификат. Если, конечно, вы не форсируете его или не добавляете в него свой собственный CA.
Однако это только половина истории.
Закрепление ключа HTTP
Несмотря на то, что веб-сервер может быть устаревшим, он может указывать, какие ключи использовались для создания открытых сертификатов. См https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
Это выглядит так:
$ wget -SO /dev/null https://securedrop.propublica.org
...
Public-Key-Pins: pin-sha256="PJgArNye1xwYWDAy3Og4ud5XTJd4aOvF0bLa0LzIKiw="; pin-sha256="RRM1dGqnDFsCJXBTHky16vi1obOlCgFFn/yOhI/y+ho="; max-age=86400
...
Открытые ключи, описанные здесь, являются либо одним из конечного сертификата, либо одним из промежуточных сертификатов CA, либо одним из корневого сертификата.
Теперь, конечно, при активной атаке угонщик мог также изменить этот заголовок HTTP, чтобы он содержал ключ, связанный с его поддельным сертификатом.
Но вот как механизм должен работать: мы начинаем с предположения, что действительные серверы начинают использовать эту функцию и предоставляют этот заголовок; клиенты, подключающиеся к нему, должны записать значение заголовка и хранить его в течение max-age секунд, что должно быть длинным значением. Чтобы при последующем посещении веб-сайта браузер теперь мог сопоставлять полученную цепочку сертификатов с любыми закрепленными ключами, которые он запомнил в прошлый раз.
Действительно, это не решает ситуацию, когда вы впервые попадаете на сервер, когда у вас ничего не хранится локально. Что является одной из причин того, что люди потеряли интерес к такому способу защиты вещей.
Вы можете найти множество страшных историй вокруг https://news.netcraft.com/archives/2016/03/30/http-public-key-pinning-youre-doing-it-wrong.html
Посмотрите: https://pinning -test.badssl.com /
Это должно вызвать ошибку, если все настроено правильно в вашем браузере (сертификат не соответствует закрепленным ключам)
Закрепление ключа "Private"
Некоторые браузеры также поставляются с определенными ключами / сертификатами в их исходном коде для некоторых конкретных доменных имен «высокого значения» и, следовательно, могут проверить это для сертификата, который они получают.
См. https://chromium.googlesource.com/chromium/src/net/+/refs/heads/master/http/transport_security_state_static.json, например, для Chromium (большой файл предупреждения).
Например:
{
"name": "google",
"static_spki_hashes": [
"GoogleBackup2048",
"GoogleG2",
"GoogleG3",
"GTSCA1O1",
"GlobalSignRootCA_R2"
],
"bad_static_spki_hashes": [
"GlobalSignRootCA",
"GlobalSignExtendedValidationCA",
"GlobalSignExtendedValidationCA_G2",
"GlobalSignExtendedValidationCA_SHA256_G2"
],
"report_uri": "http://clients3.google.com/cert_upload_json"
},
Таким образом, мы, вероятно, можем сделать вывод, что браузер откажется подключаться к веб-страницам «Google», если полученный сертификат не будет подписан одним из вышеуказанных ЦС (и будет специально отклонять некоторые другие ЦС).
Эта страница для браузера Chromium также может быть вам интересна:
https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md
Чтобы включить проверку цепочки сертификатов, Chrome имеет доступ к двум
хранилища трастовых якорей (то есть сертификаты, которые уполномочены как
эмитенты). Одно хранилище доверенных привязок - это системная или общедоступная привязка доверия
хранилище, а другое - локальное или частное хранилище доверия.
...
Chrome не выполняет проверку контактов при цепочке сертификатов
цепочки до частного якоря доверия. Ключевым результатом этой политики является
что частные доверительные якоря могут использоваться для прокси (или MITM) соединений,
даже на закрепленные сайты. «Защита от потери данных», брандмауэры,
фильтры содержимого, и вредоносные программы могут использовать эту функцию, чтобы победить
защита закрепления клавиш.
Ожидать-CT
Как написано на приведенной выше странице Википедии, «Google рекомендует использовать Expect-CT в качестве более безопасной альтернативы».
этоэто более или менее та же идея, просто реализованная по-разному.
CT означает прозрачность сертификатов, и в основном существуют серверы с коллекцией всех недавно выпущенных сертификатов всеми CA, которые соответствуют требованиям CAB Forum (которые им необходимыследовать, если они хотят, чтобы их рут продолжал включаться в браузеры).Система сделана таким образом, что она ведет себя в основном как в режиме добавления только, и теоретически было бы трудно изменить содержимое.Таким образом, один (например, браузер) может подключиться к одному из этих серверов и дважды проверить, что сертификат, полученный от сервера, действительно записан на нем (это делается либо внутри полосы, когда при установлении соединения TLS сервер может отправлять доказательства того, что сертификатнаходится в некоторых журналах CT, или клиент TLS может проверить себя, делая проверки OCSP).Если нет, то это, вероятно, означает некоторую проблему и должно прервать соединение.
Это задокументировано в https://httpwg.org/http-extensions/expect-ct.html
Однако при первом посещении вы получаете ту же проблему, что и при закреплении ключаcase.
Взгляните на https://invalid -expected-sct.badssl.com / , который должен завершиться ошибкой, если все настроено правильно.
DANE
DANE использует TLSA записей в DNS, чтобы владелец домена мог указать, какие сертификаты (или ключи) следует ожидать при подключении к различным службам в его домене.Он может указывать либо подробности о сертификате / ключе окончания службы, либо сведения о том, что ЦС подписывает свой сертификат.
Его интерес заключается в том, чтобы быть универсальным (не привязанным к какой-либо конкретной услуге) и разрешать, или нет, в зависимости отжелание зависеть от текущей веб-PKI со всеми известными центрами сертификации.
Однако:
- Чтобы быть полезным, необходимо использовать DNSSEC, иначе злоумышленники могут фильтровать или изменять записи
TLSAследовательно, сводит на нет защиту - Браузеры на самом деле не читают эти записи, чтобы использовать их, сейчас это в основном мир электронной почты