The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

В Chrome планируют удалить поддержку технологии PKP (Public Key Pinning)

28.10.2017 23:07

Компания Google представила план прекращения поддержки механизма привязки открытых ключей (PKP, Public Key Pinning), позволяющего явно определить сертификаты каких удостоверяющих центров допустимо использовать для заданного сайта. Прекращение поддержки HTTP-заголовка Public-Key-Pins, позволяющего сайтам определять привязки ключей, запланировано в выпуске Chrome 67, который ожидается 29 мая 2018 года. В дальнейшем, после внедрения для всех сертификатов проверки через механизм Certificate Transparency, ожидается удаление поддержки и ручных привязок.

В качестве причины прекращения поддержки PKP указывается на то, что данная технология не оправдала себя и почти не применяется на практике из-за трудности внедрения на сайтах (сложно подобрать корректный набор ключей для закрепления) и высокой цены ошибок в настройке, которые могут привести к недоступности сайта в случае привязки не тех ключей или утери ключей (например, случайное удаление или компрометация в результате взлома). Кроме того, PKP может применяться для осуществления некоторых видов атак. Например, для скрытой идентификации пользователей или для вымогательства после взлома сайтов (после получения доступа атакующие могут включить HPKP со своими ключами, что не даст вернуться к нормальной работе после возвращения управления и позволит атаковавшим вымогать деньги за предоставление привязанных ключей).

Утверждается, что прекращение поддержки PKP не сопряжено с риском нарушения обратной совместимости, так как это не скажется на работе сайтов. Кроме того, PKP до сих пор не поддерживается в Edge и Safari, а также имеет минимальный уровень внедрения - из миллиона крупнейших сайтов по рейтингу Alexa заголовок Public-Key-Pins выставляют только 375 сайтов.

Вместо PKP разработчикам сайтов рекомендуется использовать HTTP-заголовок Expect-CT c SCT-параметрами (SignedCertificate Timestamps) для выявления некорректных SSL-сертификатов при помощи системы Certificate Transparency. В отличие от HTTP-заголовка Public-Key-Pins в Expect-CT предусмотрена возможность отмены ошибочных привязок. Certificate Transparency базируется на идее ведения публичного лога всех выданных сертификатов, не позволяющего удостоверяющему центру сгенерировать сертификат без отражения в этом логе и дающего возможность владельцам и пользователям проводить аудит изменений. Expect-CT ссылается на валидные записи в логах Certificate Transparency, которые уже ведутся рядом удостоверяющих центров, включая StartCom, WoSign, DigiCert и Comodo.

  1. Главная ссылка к новости (https://groups.google.com/a/ch...)
  2. OpenNews: Исследование негативного влияния на безопасность локального перехвата HTTPS-трафика
  3. OpenNews: Google представил Key Transparency, альтернативу серверам криптографических ключей
  4. OpenNews: В Tor Browser 6.0.5 устранена уязвимость, позволяющая обойти привязку сертификатов
  5. OpenNews: Новый вид атак по определению ранее открытых в браузере сайтов и отслеживанию посетителей
  6. OpenNews: Релиз web-браузера Chrome 46
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/47466-chrome
Ключевые слова: chrome
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (33) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, AntonAlekseevich (ok), 23:51, 28/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Стоит Google отдать должное.
    Убрали ещё 1 механизм из Web'а который игнорируется всеми кроме тех 375 сайтов и их пользователей.
     
  • 1.2, Аноним (-), 23:59, 28/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    TL;DR: нехрен админам заботиться о безопасности, CA позаботятся за них.
     
     
  • 2.3, Аноним (-), 00:29, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • +12 +/
    А потом CA такие: "упс, мы прое*али ключи от 100500 сертификатов, но вы нас простите, ладно?.."
     
     
  • 3.5, пох (?), 00:39, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > А потом CA такие: "упс, мы прое*али ключи от 100500 сертификатов, но

    да нет, зачем же? Мы просто выдали кому надо (а не владельцу сервера) очередной летсдекриптовый сертификат - их мильярды, они каждый день обновляются, никто ничего и не заметил даже, чего вы волнуетесь?

    Ключи просpала один-единственный раз одна-единственная контора, которая не должна была пройти аудит - если бы его проводили как надо, а не ради вымогательства денег. Там просто вообще не было, похоже, ни нормальных админов, ни у тех админов реальных прав остановить бардак.

    Все остальные intermediate roots были выданы _сознательно_.

     
  • 2.4, пох (?), 00:36, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    гугль позаботится за них. Поскольку весь этот тяжелый бред (с прозрачным упоминанием еще одной возможности собирания бабла за воздух) с логсерверами, аудиторами и прочей неведомой хренью будет принадлежать известно кому.

    Соответственно, не владельцы сайта будут решать, каким именно сертификатам доверяет браузер их посетителя.
    И не посетитель - см. полезный и нужный пункт об удалении ручной привязки сертификатов - хотя она явно не может быть использована ни для чего, кроме...ну да, 100% уверенности, что сертификат не подменен, если первоначально он был получен из доверенного источника. Без всяких гуглосервисов и гуглошпионов, заметьте.

    гугль продолжает старательно выполнять условия своего кредита под 0%

     
     
  • 3.34, Аноним (-), 00:03, 30/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > гугль позаботится за них.

    Ну, вот здесь: https://www.certificate-transparency.org/what-is-ct много говорится о прозрачном, криптографически заверенном журналировании всех процессов сертификации, об открытой системе аудита и мониторинга, поддерживающей публичное наблюдение и проверку выпущенных сертификатов, распределенной системе независимых серверов журналов и т.п.

    > Без всяких гуглосервисов и гуглошпионов, заметьте.

    Если все будет реализовано по уму и так, как описано, и без навязчивой привязки к серверам Большого Брата, то должно быть хорошо всем.

     
     
  • 4.35, пох (?), 01:22, 30/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > много говорится

    да-да, говорится много. Табличку "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.
    платите за воздух еще разок.

     
     
  • 5.36, Аноним (-), 03:12, 30/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да, эта система пока не выглядит совершенной.

    С одной стороны (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.
    Что не выглядит хорошо, ибо это есть попытка возложить функцию контроля на владельца домена.

     

  • 1.7, Аноним (-), 02:39, 29/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всё правильно делают. Подробнее о проблемах:
    https://scotthelme.co.uk/im-giving-up-on-hpkp/
     
     
  • 2.11, пох (?), 10:29, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Всё правильно делают. Подробнее о проблемах:

    "если у меня взломали сервер и, возможно, сперли все _ваши_ шифрованные данные - c pkp у меня не получается быстренько перевыпустить сертификат и сделать вид что ничего не было".
    перевел, не благодари.

     
     
  • 3.13, Аноним (-), 14:51, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    твоя позиция понятна, но оглянись вокруг, разве людям в массе работоспособность сервиса не важнее его безопасности? тот же Линукс значительно ближе к народу, когда называет кое-кого обезъянами дрочащими на безопасность?
     
     
  • 4.28, пох (?), 21:28, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > твоя позиция понятна, но оглянись вокруг, разве людям в массе работоспособность сервиса
    > не важнее его безопасности

    ну так, казалось бы, не пользуйся pkp - доверяй CA, как все...э...заставь своих юзеров доверять CA или позаботиться о себе самим, вот, теперь правильно ;-)

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

    P.S. делайте ставки, господа - уберет гугль pkp из _телеметрии_ хромого, или нет.

     
  • 4.33, Аноним (-), 23:30, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > разве людям в массе работоспособность сервиса не важнее его безопасности?

    Лукавое, манипулятивное и, в ряде конкретных случаев, глупое противопоставление.

     
  • 3.19, xm (ok), 15:49, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > перевел, не благодари.

    Если бы только это. К примеру, недавняя история с регистрацией на стороннего человека одного из доменов NS серверов TLD .io доставила не по-деццки.

     
     
  • 4.29, пох (?), 21:31, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> перевел, не благодари.
    > Если бы только это. К примеру, недавняя история с регистрацией на стороннего
    > человека одного из доменов NS серверов TLD .io доставила не по-деццки.

    ну а чего тебе не нравится? ns был зарегистрирован на несуществующий в природе хост несуществующего в природе домена. Чувак, мимокрокодил, видит, непорядок, дай, думает - зарегистрирую. Денег, между прочим, заплатил, кому следует (тем самым, кто должен бы по идее следить за бардаком) Теперь видимо чувствует себя медведем в сгоревшем автомобиле.


     
  • 2.18, xm (ok), 15:46, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Скотт, конечно, красаучег. Но проблему со злоупотреблениями (ошибками) HPKP можно решить через внедрение механизма отзыва отпечатков. Он, собственно об этом и написал на днях.
     

  • 1.8, Аноним (-), 03:44, 29/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    > механизм Certificate Transparency,
    > Google's Certificate Transparency project ...

    А, ну понятно...

     
  • 1.9, Ilya Indigo (ok), 07:40, 29/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Мне это механизм с самого начала не понравился.
    При mitm-атаке заголовок легко подделывается.
     
     
  • 2.10, Аноним (-), 09:40, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А какой механизм защищает от mitm-атак и в каких браузерах он правильно реализован?
     
     
  • 3.12, пох (?), 10:37, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > А какой механизм защищает от mitm-атак и в каких браузерах он правильно
    > реализован?

    механизм trusted ca, удивительное рядом? Но наше индиго-детишко недавно очаровательно описялось, обнаружив что вообще не понимает основополагающих вещей в том, как работает ssl.

    pkp защищает не от обычного mitm, а от того, что сам ca неожиданно оказался не очень-то trusted - например, получил кредитец под 0% от кого надо.
    как, собственно, и ручное сохранение сертификата сайта.

    в обоих случаях требуется хотя бы один раз получить настоящий сертификат - например, банально до того, как 0% кредит заставят отрабатывать. Что в любом случае не может быть всеобъемлющим и продолжаться долго - ибо палевно, поэтому в общем можно доверять CA.

    Вероятно, если ты создал повод предполагать, что ОНИ за тобой следят, коллекцию сертификатов надо было начинать собирать не вчера.

     
  • 3.15, Ilya Indigo (ok), 15:29, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А какой механизм защищает от mitm-атак и в каких браузерах он правильно
    > реализован?

    Из публичных методов, в которых каждому клиенту не придётся заранее устанавливать себе сертификат сервера перед обращением к нему, а потом и переустанавливать. если сервер его изменит, ни один из них.
    Но использование KPK это лишний геморрой на пустом месте.

     
  • 3.20, xm (ok), 15:51, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А какой механизм защищает от mitm-атак и в каких браузерах он правильно
    > реализован?

    1. DNSSEC + DANE (доверие переносится на уровень регистратора домена).
    2. Ни в каких.

     

  • 1.14, Аноним (-), 15:15, 29/10/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Я один из тех, кто проср*л проект из-за этой технологии. Зарегал домен, поднял все, раскрутил, а потом решил добавить эту фигню. Шобы, значить, было еще более лучше с безопасностью. Потом полетел жесткий диск. Сайт восстановил из бэкапов, сертификат получил новый, поднял и ... никто не может зайти. Все коту под хвост.
     
     
  • 2.16, Аноним (-), 15:30, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Не понял, а почему ты сертификат не бекапил?
     
     
  • 3.22, Аноним (-), 16:27, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Вначале не бэкапил, ибо не было надобности. Если что-то случится, логичнее всего перевыпустить certificate signing request и получить новый сертификат. Более того, в случае взлома старый сертификат нужно инвалидировать и заменить. А потом ... потом было поздно.
     
     
  • 4.30, Аноним (-), 21:36, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Минусующие могут внятно объяснить, почему перегенерация сертификата - это плохо, а его бэкап и раскладывание бэкапов по разным дропбоксам, домашним компам и флешкам - это хорошо?
     
     
  • 5.31, Аноним (-), 21:37, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ЗЫ. Я - другой аноним.
     
  • 5.32, пох (?), 23:07, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Минусующие могут внятно объяснить, почему перегенерация сертификата - это плохо, а его
    > бэкап и раскладывание бэкапов по разным дропбоксам, домашним компам и флешкам - это
    > хорошо?

    минус не мой, но объясню: потому что если у тебя физически накрылся диск - нет никакого смысла в "перегенерации сертификата" (вообще-то у нормального CA можно скачать тот же самый столько раз, сколько захочется, но закрытый ключ надо, разумеется, уберечь), надо поднять его с того же бэкапа, что всю остальную систему с минимумом лишних телодвижений. Если что - никакого секрета в нем нет, у любого заглянувшего к тебе юзера остается полная копия (можно даже извлечь ее из его браузера), без твоего закрытого ключа она бесполезна.

    ломаешь ты при этом, помимо key pin'а, еще и банальное доверие тебе тех немногих умных юзеров, которые используют cert patrol или другой способ сверять сертификаты с ранее полученными их копиями, без всякого навязываемого гуглем или владельцем сайта сервиса. Поскольку они увидят, что ты менял сертификат без явных причин, и все о тебе поймут.

    а бэкап без шифрования на левые дропбоксы и теряемую в автобусе флэшку не лучше и не хуже бэкапа того, что, собственно, защищает твой сертификат - юзеру в общем-то похрен, ломанули его mitm'ом из-за того, что ты упустил ключ, или просто стырили его пароль вместе со всей твоей базой.


     
  • 3.24, пох (?), 16:45, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Не понял, а почему ты сертификат не бекапил?

    потому же, почему у него "ценный проект" (суперсекьюрный при том) на единственном жестком диске (а у меня пернатый друг и то на 3ware raid).
    Чтоб сразу и волки сыты, и кобыле легче.

     
  • 2.23, пох (?), 16:43, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Я один из тех, кто проср*л проект из-за этой технологии.

    проект ты прос*л потому что ни бэкапы делать не умел, ни в технологии ничерта не разбирался, ни хотя бы хауту не прочел - на всех углах блин написано, что сигнатура должна и обязана быть не одна. Про дать денег нормальному админу, (не Илье-синюку, который не знал для чего нужны CA,но их таких есть) я уж не заикаюсь.

    Но виновата, конечно же, технология, ага. Ну вот гугль о тебе и позаботился. К сожалению, и о нас тоже.

     
     
  • 3.25, Аноним (-), 16:56, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Так я и не претендую. Я просто говорю, что если бы этой технологии не было, этот проект был бы жив. Ну, или я прокололся бы на чем-то другом :-)
     
     
  • 4.26, пох (?), 17:24, 29/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Я просто говорю, что если бы этой технологии не было, этот проект был бы жив

    да не было б ssl - тоже был бы жив ;-)

    причем и по сей день. Вони по поводу "сайт несекьюрен, ой, не ходите сюда" в хромом почти нет - в десктопном так вообще надо стараться, чтобы что-то там заметить. (пока, конечно, ты пароли clear-text'овой вебформой не отправляешь, но за это и в ssl-обертке убивать уже пора)

    в отличии от истории с pkp, когда высовывается страшное окно с непонятными надписями и двумя кнопкам - "еще больше неведомой х..ни" и "загрузить котиков". Кнопки "продолжить" нет в принципе, пользователю незачем решать, что для него опасно, а что нет, гугль лучше знает. (мазила, если что, тоже - редкий юзер осилит удалить пин, даже если ему по буквам диктовать)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру