— Гость (25/09/2010 01:20)   
Есть на pgpru.com один такой материал... я бы его назвал более общо: "как принимать решения"^[link8]. Та заметка столь фундаментальная, ясная и чёткая, что я бы скорей отнёс её к области логики "как надо правильно и последовательно думать, а также самоанализироваться". В контексте обсуждаемого — увы: я не вижу обстоятельного рассмотрения ни одного из тех 5ти пунктов, зато сразу вижу ряд явных ляпов в тексте^*. Если перейти к неконструктиву (а то что это я сегодня такой серьёзный?), то куда нам до "элитарных блогов/сообществ", у нас даже регистрации там не имеется, равно как и желания оную заполучить.

На серьёзный чисто теоретический прорыв это не тянет, т.к. очень слабая проработка вопроса. На практический не тянет по ещё более очевидным вещам. Механизмы /etc/hosts уже частично решают задачу.

Разумнее доверять не домену, а PGP-ключу админа сайта, который его подписал (точнее, сертификату, который подписан ключом админа). Certificate Patrol в итоге эту задачу решает. Для "широких масс" такое решение не годится, а для узких, типа нашего сайта — вполне, но широкие массы и не будут заморачиваться с PGP-ключами, а тогда о чём весь сыр-бор? Кроме всего этого, есть масса стандартных способов сделать "свой интернет в интернете": /etc/hosts, DNSSEC, свои "корневые" DNS-сервера и свои VPN-тунели (при надобности).

^*

подписывает подпись на записе о сайе

Чаво?!

нет тех IP, которые можно блокировать, тех организаций, что разделегируют

Ну, хостинг-то всё равно на каком-то IP, который известен всем, в том числе и властям. Пока они будут переносить его на новый хостинг, сайт будет в дауне, даже если сохранит доменное имя.

— Гость (25/09/2010 16:12)   
Буква N в DNS это name – имя. Когда одному имени разные, но контактирующие между собой группы людей будут сопоставлять разные вещи, это приведёт к неприятным последствиям.

[offtopic?]
Агада^[link9] о строительстве Вавилонской башни:

Смешал Господь язык их так, что один не понимал речи другого. Один скажет другому: "принеси воды", а тот несет песку; "подай топор" — подает лопату. Рассвирепеет тот и раскроит ему череп.

[/offtopic]

— Гость (25/09/2010 16:42)   
Важное уточнение: к неприятным последствиям обычно приводит не само по себе сопоставление одному имени разных вещей, а нераспознавание и неотслеживание такой ситуации. Поэтому и нужны подписи.

— Гость (26/09/2010 17:53)   

к неприятным последствиям обычно приводит не само по себе сопоставление одному имени разных вещей, а нераспознавание и неотслеживание такой ситуации.

И это не только в ИБ имеет место быть :)

— poptalk (01/05/2012 18:24)   
(Я думаю, мой вопрос подходит к этой теме.) Когда-то я читал научную статью про DNS, в котором доменное имя защищено электронной цифровой подписью. Доменное имя там не совсем обычное, оно состоит из публичного ключа шифрования и произвольных данных. Также этот DNS хранится в DHT, то есть он устойчив к изъятию сервера. Этот DNS уже где-то реализован? Как зарегистрировать в нём свой сайт? Можно ли прикрутить его к nslookup в Unix?

— Гость (01/05/2012 19:49)   

Доменное имя ... состоит из публичного ключа шифрования

Скрытые сервисы Tor? :)

— poptalk (02/05/2012 14:44)   

Скрытые сервисы Tor? :)

Нет, скрытый сервис Tor не нужен. Нужно именно то, что я сказал.

— poptalk (11/06/2012 14:10)   
Вы имеете в виду DNSSEC? Я не вникал в устройство DNSSEC, но по всем видимости оно не подходит. Мне важно, чтобы данные хранились на независимых серверах; а DNSSEC иерархическая, как главный скажет, так все сделают. Но если кто-то знаком с DNSSEC и знает, как применить DNSSEC в моём случае, я с благодарностью выслушаю.

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

— Гость (11/06/2012 22:15)   

Это верно, но главный не сможет подделать чужие подписи, потому клиенты сразу увидят нестыковку. Откуда берутся у клиентов ключи для сверки всех подписей в цепочке (в DNSSEC) — не доразобрался.

Вам это не нравится, но последовательное решение вашей проблемы — onion-адреса в Tor. Там DNS — просто обрезанный хэш сертификата сервера. Имеется продуманный протокол анонимности расположения серверов. Гарантируется отсутствие механизма удаления onion-адресов на уровне протокола (ну разве что сервер сломать и его сертификат похитить). Единственная простая атака против скрытого сервиса — DoS. В обычном интернете если не смогут отобрать DNS, отберут сам IP.

— poptalk (11/06/2012 22:45)   

последовательное решение вашей проблемы — onion-адреса в Tor

Понятно, спасибо.

— SATtva (13/06/2012 10:39)   

а DNSSEC иерархическая, как главный скажет, так все сделают.

Это верно, но главный не сможет подделать чужие подписи, потому клиенты сразу увидят нестыковку. Откуда берутся у клиентов ключи для сверки всех подписей в цепочке (в DNSSEC) — не доразобрался.

Строго по иерархии — сверху вниз, как и рекурсивные DNS-запросы. Ключи корневой зоны поставляются с резолвером, они заверяют ключи доменов первого уровня, которые заверяют ключи доменов второго уровня, а те могут заверять ключи третьего уровня, и т.д. Если верхняя зона хочет подделать нижестоящие ключи, она может это сделать (да-да, как с УЦ X.509, нет в жизни счастья).

— Гость (13/06/2012 19:13)   
Интересно. Но поидее можно написать приложение, которому задать ключи всех уровней руками, и тогда подделать уже будет нельзя.

— SATtva (13/06/2012 19:53)   
Это ничем не отличается от certificate pinning в случае SSL.

— Гость (14/06/2012 12:14)   
Certificate pinning работает, когда сайт поддерживает SSL, а таких меньшинство. Именно поэтому возможность ручной проверки всех подписей в цепочке была бы интересной.

— SATtva (15/06/2012 09:41)   
Я о том, что контроль подписей/ключей в DNSSEC — это столь же нестандартное решение, сколь и certificate pinning (с точки зрения SSL). Как certificate pinning возник в качестве ответной меры на недостатки PKI, так и для контроля ключей DNSSEC что-нибудь аналогичное непременно появится.

— Гость (15/06/2012 14:18)   
Спасибо, теперь понятно.

— Гость (18/06/2012 00:15)   

certificate pinning возник в качестве ответной меры на недостатки PKI

Попытался погуглить на тему. Судя по всему, certificate pinning — просто add exception с точки зрения интерфейса firefox'а. Чтобы полноценно им пользоваться для pgpru.com, надо удалить все CA из браузера. Если же не идти на такие крайние меры (специальный браузер для какого-то сайта), браузер не будет ругаться, если запиненый сертификат вдруг из-за MITM заменится на подписанный валидным CA. Аддон CP теоретически за этим следит, но de facto он неюзабелен^[link11]. Есть ли выход?

— Гость (18/06/2012 01:07)   
А у CP нет режима следить только за указанными доменами или возможности добавлять исключения для «флудящих» доменов типо гугля? Если нет, то можно попросить автора добавить функционал.

— Гость (18/06/2012 02:01)   
Исключения поддерживаются (но их указывается слишком много, так что не вариант). Чтоб только за указанными — нет. Попросить можно, да. Я предпочёл бы, чтоб для "только указанных" был вообще отдельный аддон или хотя бы другие всплывающие окна, а то, что есть в CP пусть так и сидит. При заходе на сайты типа youtube CP выдаёт штук 10 окон, т.к. там подгрузка идёт с кучи доменов и т.д., из-за этого можно просмотреть смену сертификата на релевантный сайт.

— SATtva (18/06/2012 07:38)   

Если же не идти на такие крайние меры (специальный браузер для какого-то сайта), браузер не будет ругаться, если запиненый сертификат вдруг из-за MITM заменится на подписанный валидным CA.

Потому что то, что Вы описываете, не есть certificate pinning. Реальный cert pinning реализован в Firefox для update-сервера, например: в коде жёстко прописан его отпечаток, т.е. никакой иной сертификат не может быть принят в принципе. Такая же история с гугловскими сертификатами в Chrome.

— Гость (18/06/2012 17:11)   

Потому что то, что Вы описываете, не есть certificate pinning.

Тогда объясните как мне его реализовать для конкретного сайта — скажем, для pgpru.com. Ну или ткните в инструкцию, а то гугление для случая firefox мне ничего не дало.

— SATtva (18/06/2012 17:17)   
Надёжно — никак (исключая удаление всех УЦ из хранилища). Пользователю этот функционал не открыт, используется разработчиками для некоторых специальных целей, когда они не считают PKI достаточно безопасным механизмом (видимо, думают, что у обычного пользователя таких сценариев быть не может).

— Гость (11/03/2015 20:00)   

На горизонте замаячил свет: HTTP Public Key Pinning^[link12] (задает список валидных открытых ключей). Если его сопрячь с HSTS (HTTP Strict Transport Security, который говорит о том, что сайт работает только по HTTPS), то получается совсем хорошо. В firefox фичу добавили 20-го января этого года, поэтому в TBB ещё нету (в TBB 4.0.4 сейчас firefox 31.5.0esr, а нужен минимум 35). Кстати, HTTP STS на сайте Tor'а уже поддерживается.

Технология HTTP PKP имеет все шансы убить PKI — привязка сертификата идёт к первому заходу на сайт, потом все остальные сертификаты должны быть подписаны предыдущими (там всегда их минимум два: основной и запасной на случай фейла основного). Плохо только, что браузер пока не показывает никаких идентификаторов, поддерживает ли сайт PKP, поэтому приходится разбирать заголовки вручную (может быть, со временем сделают). Preload list сертификатов (то, что понималось ранее под certificate pinning), возможно, тоже можно редактировать вручную. PKP для всех браузеров (кроме IE, конечно же) есть в виде расширений.

Ссылка на стандарт^[link13].

— Гость (11/03/2015 22:01)   
Настройки HTTP PKP и HTTP STS задаются в файле SiteSecurityServiceState.txt. Его можно бэкапить, чтобы переносить между разными пользователями, или просто редактировать вручную. Пример содержимого:

site.domain:HPKP 0 16505 1234567890123,1,1,XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=

Как получить base64-строку для заголовка Public-Key_pins:

$ openssl rsa -in rsa_key.key -pubout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

— это заголовок на основе приватного ключа, а на основе сертификата несколько иначе:

$ openssl x509 -pubkey < tls.crt | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

Вариант на основе приватного ключа универсальнее, т.к. сертификата может еще не быть (сертификат всегда можно получить позже, привязка идет только к публичному ключу).

report-uri — это скрипт, куда браузер будет отправлять отчеты об ошибках.

Юзерам ничего добавлять руками не надо, в этом смысл PKP. Всё работает само, абсолютно без участия (но отпечатки первый раз надо будет сверить, чтобы избежать MITMа).