Компания Google представила (https://groups.google.com/a/chromium.org/d/msg/blink-dev/he9...) план прекращения поддержки механизма привязки открытых ключей (PKP, Public Key Pinning), позволяющего явно определить сертификаты каких удостоверяющих центров допустимо использовать для заданного сайта. Прекращение поддержки HTTP-заголовка Public-Key-Pins, позволяющего сайтам определять привязки ключей, запланировано в выпуске Chrome 67, который ожидается 29 мая 2018 года. В дальнейшем, после внедрения для всех сертификатов проверки через механизм Certificate Transparency (https://www.certificate-transparency.org/), ожидается удаление поддержки и ручных привязок.
В качестве причины прекращения поддержки PKP указывается на то, что данная технология не оправдала себя и почти не применяется на практике из-за трудности внедрения на сайтах (сложно подобрать корректный набор ключей для закрепления) и высокой цены ошибок в настройке, которые могут привести к недоступности сайта в случае привязки не тех ключей или применения другого сертификата на сайте. Кроме того, PKP может применяться для осуществления (https://risky.biz/RB467/) некоторых видов атак. Например, для скрытой идентификации (https://www.opennet.ru/opennews/art.shtml?num=43209) пользователей или для вымогательства (https://github.com/cyph/ransompkp) после взлома сайтов.
Утверждается, что прекращение поддержки PKP не сопряжено с риском нарушения обратной совместимости, так как это не скажется на работе сайтов. Кроме того, PKP до сих пор не поддерживается в Edge и Safari, а также имеет минимальный уровень внедрения - из миллиона крупнейших сайтов по рейтингу Alex заголовок Public-Key-Pins выставляют только 375 сайта. Вместо PKP разработчикам сайтов рекомендуется использовать HTTP-заголовок Expect-CT (https://tools.ietf.org/html/draft-ietf-httpbis-expect-ct-01) c SCT-параметрами (SignedCertificate Timestamps) для выявления некорректных SSL-сертификатов при помощи системы Certificate Transparency (https://www.certificate-transparency.org/). В отличие от HTTP-заголовка Public-Key-Pins в Expect-CT предусмотрена возможность отмены ошибочных привязок. Кроме того, Expect-CT уже применяется рядом удостоверяющих центров.URL: https://groups.google.com/a/chromium.org/d/msg/blink-dev/he9...
Новость: https://www.opennet.ru/opennews/art.shtml?num=47466
Стоит Google отдать должное.
Убрали ещё 1 механизм из Web'а который игнорируется всеми кроме тех 375 сайтов и их пользователей.
TL;DR: нехрен админам заботиться о безопасности, CA позаботятся за них.
А потом CA такие: "упс, мы прое*али ключи от 100500 сертификатов, но вы нас простите, ладно?.."
> А потом CA такие: "упс, мы прое*али ключи от 100500 сертификатов, нода нет, зачем же? Мы просто выдали кому надо (а не владельцу сервера) очередной летсдекриптовый сертификат - их мильярды, они каждый день обновляются, никто ничего и не заметил даже, чего вы волнуетесь?
Ключи просpала один-единственный раз одна-единственная контора, которая не должна была пройти аудит - если бы его проводили как надо, а не ради вымогательства денег. Там просто вообще не было, похоже, ни нормальных админов, ни у тех админов реальных прав остановить бардак.
Все остальные intermediate roots были выданы _сознательно_.
гугль позаботится за них. Поскольку весь этот тяжелый бред (с прозрачным упоминанием еще одной возможности собирания бабла за воздух) с логсерверами, аудиторами и прочей неведомой хренью будет принадлежать известно кому.Соответственно, не владельцы сайта будут решать, каким именно сертификатам доверяет браузер их посетителя.
И не посетитель - см. полезный и нужный пункт об удалении ручной привязки сертификатов - хотя она явно не может быть использована ни для чего, кроме...ну да, 100% уверенности, что сертификат не подменен, если первоначально он был получен из доверенного источника. Без всяких гуглосервисов и гуглошпионов, заметьте.гугль продолжает старательно выполнять условия своего кредита под 0%
> гугль позаботится за них.Ну, вот здесь: https://www.certificate-transparency.org/what-is-ct много говорится о прозрачном, криптографически заверенном журналировании всех процессов сертификации, об открытой системе аудита и мониторинга, поддерживающей публичное наблюдение и проверку выпущенных сертификатов, распределенной системе независимых серверов журналов и т.п.
> Без всяких гуглосервисов и гуглошпионов, заметьте.
Если все будет реализовано по уму и так, как описано, и без навязчивой привязки к серверам Большого Брата, то должно быть хорошо всем.
> много говоритсяда-да, говорится много. Табличку "bullshit" можно поднимать после первых десятка строк.
> Если все будет реализовано по уму и так, как описано
то pkp это не заменит практически никак, ручную привязку сертификата к конкретному хосту - совсем никак.
Ваши возможности на что-то повлиять и вовсе сводятся к нулю, по обе стороны от мушки.
1. вы не можете держать свой лог-сервер - то есть, хоть обдержитесь, но CA вам никаких логов слать не будут. Доверяйте гуглю.
2. вы вряд ли сможете держать свой монитор, анализирующий логи по мере добавления - во-первых, это довольно дорогое удовольствие, во-вторых, наверняка логовладельцы захотят сделать на этом бакшиш (или просто зарейтлимитят - ну можно будет раз в день проверить, что твоему сайту еще не выдали десять сертификатов неизвестно кому, пользы от этого - ноль)
Доверяйте гуглю.
3. из набора функций аудитора вы сможете самостоятельно разьве что проверить, что сертификат есть в логе. А он конечно ж есть, чего ж нам не есть. Вот нет ли там еще парочки - непонятно ни как проверить, ни что делать с этим знанием (они может валидны)."In most cases, the Certificate Transparency system can detect suspect certificates or CAs in a few hours instead of" immediately, as pkp did. Поправил, не благодарите.
Ну и вишенка на тортике: Others will be run as subscription services that domain owners and certificate authorities can buy into.
платите за воздух еще разок.
Да, эта система пока не выглядит совершенной.С одной стороны (https://www.certificate-transparency.org/what-is-ct):
Make it impossible (or at least very difficult) for a CA to issue a SSL certificate for a domain without the certificate being visible to the owner of that domain.
Protect users (as much as possible) from being duped by certificates that were mistakenly or maliciously issued.
И это выглядит хорошо: кому попало не выдаем и юзера как-то защитить пытаемся.С другой стороны (https://datatracker.ietf.org/doc/rfc6962/?include_text=1):
7.2. Detection of Misissue
The logs do not themselves detect misissued certificates; they rely instead on interested parties, such as domain owners, to monitor them and take corrective action when a misissue is detected.
Что не выглядит хорошо, ибо это есть попытка возложить функцию контроля на владельца домена.
Всё правильно делают. Подробнее о проблемах:
https://scotthelme.co.uk/im-giving-up-on-hpkp/
> Всё правильно делают. Подробнее о проблемах:"если у меня взломали сервер и, возможно, сперли все _ваши_ шифрованные данные - c pkp у меня не получается быстренько перевыпустить сертификат и сделать вид что ничего не было".
перевел, не благодари.
твоя позиция понятна, но оглянись вокруг, разве людям в массе работоспособность сервиса не важнее его безопасности? тот же Линукс значительно ближе к народу, когда называет кое-кого обезъянами дрочащими на безопасность?
> твоя позиция понятна, но оглянись вокруг, разве людям в массе работоспособность сервиса
> не важнее его безопасностину так, казалось бы, не пользуйся pkp - доверяй CA, как все...э...заставь своих юзеров доверять CA или позаботиться о себе самим, вот, теперь правильно ;-)
но есть один ньюанс - pkp был еще одним (доступным немногим, с учетом необходимости подкладывать очень небесплатную соломку) препятствием к поголовному переходу на letsencrypt - поскольку, очевидно, бесмысленнен и опасен с короткоживущими сертификатами.
P.S. делайте ставки, господа - уберет гугль pkp из _телеметрии_ хромого, или нет.
> разве людям в массе работоспособность сервиса не важнее его безопасности?Лукавое, манипулятивное и, в ряде конкретных случаев, глупое противопоставление.
> перевел, не благодари.Если бы только это. К примеру, недавняя история с регистрацией на стороннего человека одного из доменов NS серверов TLD .io доставила не по-деццки.
>> перевел, не благодари.
> Если бы только это. К примеру, недавняя история с регистрацией на стороннего
> человека одного из доменов NS серверов TLD .io доставила не по-деццки.ну а чего тебе не нравится? ns был зарегистрирован на несуществующий в природе хост несуществующего в природе домена. Чувак, мимокрокодил, видит, непорядок, дай, думает - зарегистрирую. Денег, между прочим, заплатил, кому следует (тем самым, кто должен бы по идее следить за бардаком) Теперь видимо чувствует себя медведем в сгоревшем автомобиле.
Скотт, конечно, красаучег. Но проблему со злоупотреблениями (ошибками) HPKP можно решить через внедрение механизма отзыва отпечатков. Он, собственно об этом и написал на днях.
> механизм Certificate Transparency,
> Google's Certificate Transparency project ...А, ну понятно...
Мне это механизм с самого начала не понравился.
При mitm-атаке заголовок легко подделывается.
А какой механизм защищает от mitm-атак и в каких браузерах он правильно реализован?
> А какой механизм защищает от mitm-атак и в каких браузерах он правильно
> реализован?механизм trusted ca, удивительное рядом? Но наше индиго-детишко недавно очаровательно описялось, обнаружив что вообще не понимает основополагающих вещей в том, как работает ssl.
pkp защищает не от обычного mitm, а от того, что сам ca неожиданно оказался не очень-то trusted - например, получил кредитец под 0% от кого надо.
как, собственно, и ручное сохранение сертификата сайта.в обоих случаях требуется хотя бы один раз получить настоящий сертификат - например, банально до того, как 0% кредит заставят отрабатывать. Что в любом случае не может быть всеобъемлющим и продолжаться долго - ибо палевно, поэтому в общем можно доверять CA.
Вероятно, если ты создал повод предполагать, что ОНИ за тобой следят, коллекцию сертификатов надо было начинать собирать не вчера.
> А какой механизм защищает от mitm-атак и в каких браузерах он правильно
> реализован?Из публичных методов, в которых каждому клиенту не придётся заранее устанавливать себе сертификат сервера перед обращением к нему, а потом и переустанавливать. если сервер его изменит, ни один из них.
Но использование KPK это лишний геморрой на пустом месте.
> А какой механизм защищает от mitm-атак и в каких браузерах он правильно
> реализован?1. DNSSEC + DANE (доверие переносится на уровень регистратора домена).
2. Ни в каких.
Я один из тех, кто проср*л проект из-за этой технологии. Зарегал домен, поднял все, раскрутил, а потом решил добавить эту фигню. Шобы, значить, было еще более лучше с безопасностью. Потом полетел жесткий диск. Сайт восстановил из бэкапов, сертификат получил новый, поднял и ... никто не может зайти. Все коту под хвост.
Не понял, а почему ты сертификат не бекапил?
Вначале не бэкапил, ибо не было надобности. Если что-то случится, логичнее всего перевыпустить certificate signing request и получить новый сертификат. Более того, в случае взлома старый сертификат нужно инвалидировать и заменить. А потом ... потом было поздно.
Минусующие могут внятно объяснить, почему перегенерация сертификата - это плохо, а его бэкап и раскладывание бэкапов по разным дропбоксам, домашним компам и флешкам - это хорошо?
ЗЫ. Я - другой аноним.
> Минусующие могут внятно объяснить, почему перегенерация сертификата - это плохо, а его
> бэкап и раскладывание бэкапов по разным дропбоксам, домашним компам и флешкам - это
> хорошо?минус не мой, но объясню: потому что если у тебя физически накрылся диск - нет никакого смысла в "перегенерации сертификата" (вообще-то у нормального CA можно скачать тот же самый столько раз, сколько захочется, но закрытый ключ надо, разумеется, уберечь), надо поднять его с того же бэкапа, что всю остальную систему с минимумом лишних телодвижений. Если что - никакого секрета в нем нет, у любого заглянувшего к тебе юзера остается полная копия (можно даже извлечь ее из его браузера), без твоего закрытого ключа она бесполезна.
ломаешь ты при этом, помимо key pin'а, еще и банальное доверие тебе тех немногих умных юзеров, которые используют cert patrol или другой способ сверять сертификаты с ранее полученными их копиями, без всякого навязываемого гуглем или владельцем сайта сервиса. Поскольку они увидят, что ты менял сертификат без явных причин, и все о тебе поймут.
а бэкап без шифрования на левые дропбоксы и теряемую в автобусе флэшку не лучше и не хуже бэкапа того, что, собственно, защищает твой сертификат - юзеру в общем-то похрен, ломанули его mitm'ом из-за того, что ты упустил ключ, или просто стырили его пароль вместе со всей твоей базой.
> Не понял, а почему ты сертификат не бекапил?потому же, почему у него "ценный проект" (суперсекьюрный при том) на единственном жестком диске (а у меня пернатый друг и то на 3ware raid).
Чтоб сразу и волки сыты, и кобыле легче.
> Я один из тех, кто проср*л проект из-за этой технологии.проект ты прос*л потому что ни бэкапы делать не умел, ни в технологии ничерта не разбирался, ни хотя бы хауту не прочел - на всех углах блин написано, что сигнатура должна и обязана быть не одна. Про дать денег нормальному админу, (не Илье-синюку, который не знал для чего нужны CA,но их таких есть) я уж не заикаюсь.
Но виновата, конечно же, технология, ага. Ну вот гугль о тебе и позаботился. К сожалению, и о нас тоже.
Так я и не претендую. Я просто говорю, что если бы этой технологии не было, этот проект был бы жив. Ну, или я прокололся бы на чем-то другом :-)
> Я просто говорю, что если бы этой технологии не было, этот проект был бы живда не было б ssl - тоже был бы жив ;-)
причем и по сей день. Вони по поводу "сайт несекьюрен, ой, не ходите сюда" в хромом почти нет - в десктопном так вообще надо стараться, чтобы что-то там заметить. (пока, конечно, ты пароли clear-text'овой вебформой не отправляешь, но за это и в ssl-обертке убивать уже пора)
в отличии от истории с pkp, когда высовывается страшное окно с непонятными надписями и двумя кнопкам - "еще больше неведомой х..ни" и "загрузить котиков". Кнопки "продолжить" нет в принципе, пользователю незачем решать, что для него опасно, а что нет, гугль лучше знает. (мазила, если что, тоже - редкий юзер осилит удалить пин, даже если ему по буквам диктовать)