
Я заметил, что при установке пакетов из apt
, иногда мы делаем что-то вроде:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
Если я правильно понимаю, то мы здесь идем и извлекаем открытый ключ GPG из https://download.../gpg
и помещаем его в /usr/share/keyrings/docker-archive-keyring.gpg
. Затем мы говорим apt: «когда вы загружаете пакеты из, https://download.docker.com/...
убедитесь, что эти пакеты подписаны закрытым ключом, принадлежащим этому открытому ключу».
Поэтому я не совсем понимаю: если мы доверяем, что на другой стороне находится Docker https://download.docker.com/..
(а мы доверяем, поскольку именно оттуда мы получаем открытый ключ), то зачем нам проверять пакеты, поступающие оттуда, с помощью ключа gpg?
Мне кажется, это самоподписанный сертификат.
Я что-то упустил?
решение1
Это происходит по нескольким причинам, и все они вращаются вокругАтаки «Человек посередине»(MITM) - в частности, защита вас от любого случая в будущем, когда вы подвергнетесь атаке MITM или какому-либо другому виду вредоносного перенаправления на «ложные источники загрузки»послеВы получили хороший ключ.
Если вы находитесь в худшем случае — ваша система уже скомпрометирована и перенаправлена на плохой сайт для злоумышленника (сокращенно «MA») — то вы влипли, и это вас не защитит, потому что вы будете загружать ключи MA. Это не суть этой защиты ключа PGP и связки ключей здесь, это защитить вас отбудущееАтаки MITM.
В этом примере вы уже скомпрометированы, и какой ключ используется, не имеет значения, поскольку MA, скорее всего, контролирует ваш компьютер, сеть, данные и т. д. на данный момент. Однако наиболее распространенный сценарий защиты — это выначинатьс чистой средой/системой изатемустанавливать программное обеспечение из легального источника. (см. следующий раздел)
Однако запуск из скомпрометированной среды не является «распространенным сценарием», от которого защищают ключевые сигнатуры. Наиболее распространенный сценарий: у вас чистая система, с чистыми обновлениями, без компрометации вашей системы, используемых вами DNS-серверов, сети, к которой вы подключены, и т. д.
Вы переходите к установке Docker и получаете ключ Docker с настоящего сайта Docker. Затем вы устанавливаете Docker, и ключ проходит валидацию.
В какой-то момент в будущем MA возьмет под контроль ваш трафик в Интернете и перенаправит вас на «поддельный» сайт загрузки Docker.
Если только MA не украл ключ PGP из Docker с соответствующим ему закрытым ключом, ваша apt
система покажет, что подписи наdownload.docker.com
не совпадаети что в вашей среде происходит что-то странное, и обновления из-за перенаправления на «плохой» репозиторий MA не применяются.
Этотто, от чего защищают подпись ключа и его части: вас могут атаковать MITMбудущее. Это не защитит вас, если вы уже скомпрометированы, ничто не защитит. Это защитит вас, когда вы начинаете чисто и бескомпромиссно, а затемстановитьсяпо какой-то причине скомпрометирован.
Вот почему вам следует сверять отпечатки ключей с известными хорошими отпечатками ключей. Большинство хороших поставщиков репозиториев имеют свои отпечатки, которые легко доступны для ручной проверки, так что вам не придется полагаться на команды JUST, чтобы получить и доверять ключам.