Google против PKI

Судя по новостям, Google, видимо, готовится к чему-то серёзному, и решила напоследок вообще отменить такой термин, как безопасность. Компания в очередной раз осознанно ухудшает безопасность своих продуктов и, как следствие, персональных данных пользователей, которые по незнанию доверяют этому «безопасному» ПО.

http://www.securitylab.ru/news/419662.php

То есть к тому, что chrome является безусловным «лидером» по количеству дырок и багов, плюс к тому, что google умышленно снижает стойкость криптографической защиты SSL и умышленно не использует надёжные протоколы защиты данных, прибавился безусловный хит — Google решил отменить PKI, потому что реализация проверки сертификата на отзыв тормозит загрузку страниц.

Большего абсурда и демонстрации «компетентности» разработчиков из Google представить себе трудно. Почитайте только глубокомысленные рассуждения оных:

The median time for a successful OCSP check is ~300ms and the mean is nearly a second. This delays page loading and discourages sites from using HTTPS.

Понятно, почему на кадровом рынке России гугл собирает неликвид — фразу вида «мы делаем безопасный браузер — поэтому давайте не проверять сертификаты на отзыв, а то это тормозит загрузку страничек и из-за этого (sic!) сайты не любят https» родить хотя бы мало-мальски компетентный разработчик не в состоянии. Срыв покровов — оказывается, https не используется ресурсами не из-за, допустим, возрастания нагрузки на оборудование, т.к. шифрование трафика вызывает рост загрузки вычислительных мощностей, а из-за проверки сертификата на отзыв.

Да, прекрасная гуглобезопасность — ради цифирок в синтетическом тесте предложить отключить по дефолту одну из ключевых проверок в PKI.

Важный момент также то, как именно они это собираются сделать: втихую раздать это через очередное обновление — конечно, никак не уведомив пользователей о таком «махоньком» изменении безопасности. Ну а зачем, действительно? Пользователи продукции Google ведь не должны иметь своих личных данных, они — поисковый материал.

Очевидно же, что именно таким людям — компетентным, ответственным, акцентирующимся на серьёзном подходе к безопасности — и надо доверять свои данные. Империя добра, хуле.

Реклама
Google против PKI

Google против PKI: Один комментарий

  1. Очередной фейл, в 17 версии хромиума сломали отображение юнкодных символов в субджекте сертификатов, тем самым нет возможности без детального разглядывания сертификата понять где ты находишься на нужном тебе сайте или непонятно где: http://code.google.com/p/chromium/issues/detail?can=2&q=114168&colspec=ID%20Pri%20Mstone%20ReleaseBlock%20Area%20Feature%20Status%20Owner%20Summary&id=114168

  2. Кстати, если уж следовать букве закона, то в составе всех браузеров, которые не являются частью ОС, как IE, есть шифровальные (криптографические средства) иностранного производства «использование», которых юриком без лицензии, а так же ввоз без соблюдения соответсвующей процедуры на территорию РФ (а скачивание из-за бугра дистра браузера по сути есть ввоз) запрещены.

    Все кладут болт на это, но по факту соотвесвующие статьи КоАП пока не отменили (есть законопроект) и теоретически, если «оказывать услуги» с помощью такого браузера можно даже на деятельность без лицензии под уголовку залететь. 😀

    1. бггг
      Криптографические средства в «исконно американской» винде и в русской, одобренной КГБ, версии, они отличаются или нет? Столько ходит слухов про «оставленные гебнёй закладки», да и сам Руслан как-то заикнулся про это. Я сам пока пользуюсь «исконно американской» виндой, да и потом (как выйдет 8) тоже думаю заказать нерусскую версию.

      1. Я склонен считать, что не отличаются. Я точно не помню как организовано «сертифицированное производство». У Владимира Мамыкина спросите, он в курсе. ж-)

  3. Cookie_Monster:

    Есть пара вопросов, на которые я так и не смог найти ответ. Поэтому, почему бы не спросить опенсосок? Адресую эти 2 вопроса опенсосочным блядям.

    1) Начну сразу с примера. Я не хочу вручную вводить пароли в браузере. Я нахожу программу “менеджер паролей” и покупаю ее за смешные деньги. Устанавливаю ее в два щелчка мыши. После чего, программа экономит мое время, делая за меня ручную работу. Если бы у программы был открыт код, то я бы не скачал его даже бесплатно. Более того, я бы даже не знал, что он существует, так как открытый код продукта представляет для меня столько же интереса, как схема купленного мной тостера. Я плачу деньги за работающий продукт и я не хочу тратить свое время, бесплатно выполняя работу автора программы. Как говорил известный, частично вылечившийся опенсосочник Jamie Zawinski: “Linux is only free if your time has no value ”.
    Только что, я описал процесс, через который проходят миллиарды людей каждый день. Это взаимовыгодный, добровольный обмен денег на товар или услугу. Теперь вопрос. Если говорить в терминологии опенсосочного движения, то на каком этапе этого процесса я становлюсь “рабом”? Какой эффект это “рабство” имеет на меня? Поясню еще более подробно. Вот сижу я, вручную ввожу пароли. Затем плачу копеечку и не ввожу. Каким образом можно интерпретировать отличие этих двух состояний, как “переход от свободы к рабству”? Естественно, я завишу от создателя программы, так же, как я завишу от производителя тостера. Я понимаю, что из за социопатии, вам не хотелось бы зависеть ни от кого, но так уж получилось, что весь мир держится на зависимости одних людей от других. Тут мой первый вопрос плавно переходит во второй.

    2) Когда разговор идет о пиратстве, то “люди” из вашего ебанутого движения обычно говорят:

    “Нельзя называть копирование пиратством, потому что, в реальной жизни, пираты убивают людей и похищают корабли. Приравнивать копирование информации к похищению кораблей – аморально и является грязной и лживой пропагандой.”

    Я привожу цитату Столлмана, содержащую именно такие сентименты:

    «Publishers often refer to copying they don’t approve of as “piracy.” In this way, they imply that it is ethically equivalent to attacking ships on the high seas, kidnapping and murdering the people on them.»

    http://www.gnu.org/philosophy/words-to-avoid.html#Piracy

    В следующих двух цитатах, он сравнивает закрытый софт с рабством и пользование закрытым софтом с “выбиранием себе хозяина”, подразумевая, что пользователь закрытого софта — раб.

    «To have the choice between proprietary software packages is being able to choose your master.»

    http://en.wikiquote.org/wiki/Richard_Stallman

    «Now, it may be impossible to totally eradicate the last little bits of non-free software. After all, in almost 200 years of abolitionism, we haven’t eliminated slavery.»

    http://www.techradar.com/news/software/-proprietary-software-keeps-users-helpless—963248

    Рабство, в реальной жизни, это когда один человек принадлежит другому человеку, в таком же смысле, как домашний скот. Хозяин может в любой момент забить своего раба до смерти и никто не скажет ему ни слова. В наше время у домашнего скота в США больше прав, чем было в свое время у рабов. Теперь вопрос. Почему сравнение копирования информации с похищением кораблей — аморально и является грязной и лживой пропагандой, но при этом сравнение закрытого софта с рабством (а людей пишущих закрытый софт с хозяевами и пользователей с рабами), является солидным аргументом?

    1. А что мешает использовать бесплатные с закрытым кодом или бесплатные и с открытым исходным кодом программы, или например, платные, но с открытым кодом? Мне не мешает их, скажем так, беслпатность или открытость кода. Я не понимаю этих заморочек со свободностью, если ПО достаточно качественное, то я буду использовать, то что не стоит мне денежек.
      Для примера 7-Zip. Что плохого в его использовании? Как альтернатива WinRar за денежку. Есть он у меня купленный, но я его не использую, 7-Zip мне милее (хотя я его в явном виде уже давно не использую, обычно это arclite в составе Far Manager, который тоже бесплатен и с открытым исходным кодом, с вполне себе понятной BSD-like лицензией).

      Я ни в коем случае не являюсь каким-либо сторонником СПО, но считаю, что ряд программок имеют право на жизнь в рамках такой модели разработки. А скрещивание понятий свобода и ПО вызывают у меня мигрень.

      По поводу вопросов — игра слов и аллегории в контексте СПО vs коммерческая разработка с закрытым кодом меня мало увлекают. Секты кругом, тараканы и тараканища в головах у многих и словами тут не поможешь. А люди, типа Столлмэна, не умеющие себя вести как подобает в современном обществе, вызывают только чувство жалости, как бы гениальны они не были или таковыми их считали.

      1. Cookie_Monster:

        Вот тут небольшое обсуждение было:
        http://2ch.so/s/res/558667.html

        На мои два вопроса я получил ответ. Вообщем, консенсус опенсосок таков.

        Ответ на первый вопрос: пользуйся встроенным в браузером менеджером паролей.

        Ответ на второй вопрос: копирование информации это не кража(глубокомысленная картинка прилагается):

        Люди не могут прочитать простой текст(мои вопросы) и извлечь из него суть. Я не знаю, что теперь с детьми делают в школах, но мне кажется, что их накачивают барбитуратами. Синдром дефицита внимания и слабоумие шагают по стране.

      2. Cookie_Monster:

        >> А что мешает использовать бесплатные с закрытым кодом или бесплатные и с открытым исходным кодом программы, или например, платные, но с открытым кодом?

        Что мешает? Мне ничего, поэтому пользуюсь любыми программами, жертвуя деньги на нужные мне opensource-проекты. Интересно, как много опенсосок поступает так же? 🙂
        Что касается монополий, лицензий и прочего треша, который занимает умы интеллектуалов из «коммунити», то мне нет до этого никакого дела. Я всего лишь указываю на очевидную ограниченность opensource подхода и на наполненную гордостью предвзятость и ограниченность адептов свободной секты. Что поделаешь, несмотря на показные «рациональность и атеизм», у людишек до такой степени душонка прикипела к Правильной Лицензии, что любой саентолог от зависти удавится.

  4. Вот, появилась адекватная статья http://www.carbonwind.net/blog/post/Inside-Google’s-pushing-revocation-list-approach.aspx

    Общий вывод, вместо того чтобы OCSP Stapling допиливать, они придумали ни с кем не совместимый, не эффективный механизм , который полностью не решает ни одну из поставленных задач. «MITM всё равно возможен». Т.е. чтобы закрыть эти атаки нужно вносить изменения и в браузер и в сервер и OCSP Responder, но гуглу это не позубам, им по зубам CRLи кравлить, ведь для этого ничего не нужно делать. 😉

    1. В общем да, толково товарищ пишет. Реально — костыль делают, ни с чем не совместимый, задач не решающих. Ну, как в случае с RC4 в TLS же было ранее, мы ж тут уже обсуждали.

      — А зачем Google снижает стойкость шифрования сессии, делая предпочтительным RC4?
      — Ну, это защита от BEAST!
      — Так чтобы защититься от BEAST, надо RC4 не приоритетным сделать, а единственным.
      — Ну ээ… иди на хуй, тебя подкупил Microsoft.

      1. Факты: от BEAST уже все пропатчились, чтобы эту атаку использовать нужно иметь возможность хотя бы отправлять запросы в той же SSL/TLS-сессии (что подразумевает, как минимум, обход политик ограничения домена, т.е. эксплоит в браузере, недоработку в браузере или иной технологии типа Java/Flash/Silverlite и граничит уже с MitB), а так же слушать весь сетевой трафик браузера жертвы. Следствие: угроза несколько преувеличена и, по сути, так и осталась академической (как будто о данной проблеме не было известно ранее, всё необходимое для защиты появилось ещё в TLS1.1), в реальности, ИМХО, она не будет массово эксплуатироваться, обыватель может спать спокойно.

        И, что гугл? Сделали изменение под флагом защиты от BEAST именно для обывателя, а сами снизили нагрузку на сервера, чтобы (пофантазируем) немного выронить нагрузку от иного изменения (запуск ECDHE, насколько оно там у них шустро работает, ещё ни кем не доказано, хотя я мог и упустить новости на эту тему). На лицо введение в заблуждение обывателей и реклама псевдо-защищённости браузера.

        Кстати M$ так же предлагала поднять приоритет для RC4 для митигейшена на стороне сервера https://technet.microsoft.com/en-us/security/bulletin/ms12-006 , что несколько печально.
        И набор чипперов у них тоже не блещет прогрессивностью, как и поддержкой TLS1.1+.
        —— —Бонус ————-
        Гугл теперь доберётся до ваших файлов: http://habrahabr.ru/blogs/cloud_computing/137925/
        Хром обновился, все празднуют основное изменение — изменили кнопочку создания новой вкладки (могучее бурление по этому поводу) и допилили проверку скаченных файлов (последнее, в IE это было давным-давно и все ругали, что это шняга шняжная):
        http://habrahabr.ru/blogs/google_chrome/137903/
        Способ продаться за конфетку с потрохами Гуглу: http://habrahabr.ru/blogs/search_engines/137859/

  5. nihilo666:

    То то недавно почта gmail выдала мне, что не удается проверить сертификат гугла на подлинность.

  6. Хром работает на нескольких ОС, поэтому у него возникает проблема как с хранилищем корневых/доверенных/промежуточных сертификатов (не все ОС имеют централизованное и/или своевременно обновляемое хранилище сертификатов), так и с CRLями (хотя они довольно редки в таком виде, та же проблема в разных ОС), поэтому инициатива с собственным кэшем CRL понятна (на других ОС оно, видимо, уже с собой таскает и список корневых/доверенных сертификатов, тут допилили CRLи и решили протрубить о проблеме ;)).
    Но вот зачем отключать проверку CRL чисто в угоду мнимому ускорению я не понимаю.

    НЕТ озвученной ими проблемы с производительностью! В большинстве случаев (я посерфил сайты среднестатистического юзера доступные по HTTPS типа paypal, eBay, почты всякой, социалку и интернет-банков), что OCSP, что CRL/dCRL имеют достаточно длительные «TTL». Вследствие чего они эффективно кэшируются и не вносят задержку при каждом открытии сайта. Блин, раз в день, неделю, а то и в две, можно 300 мс подождать.
    Я вам больше скажу, в большинстве случаев при открытии сайта по HTTPS практически никакого трафика нет (всё достаётся из кэша браузера, кроме всяких не особо нужных гугл аналитикс, вот их бы задавили бы для производительности, вот смех бы был)!
    Проблема приватности, так же высосана из пальца, кто бы говорил, ИМХО, со стороны гугла рассуждения на эту тему это выглядят очень странно. CA и так знает на какой сайт будут ходить, он же сам для его доменного имени сертификат выпускает. А сам по себе IP-адрес, если пользователя заботит приватность, на него лично не выведет. А как следствие механизмов кэширования CA никогда не будет точно знать даже сколько раз определённый пользователь зашёл на сайт.

    Другое дело, что OCSP/CRL при проверке доступа к HTTPS сайту действительно при их среднестатистическом длинном «TTL» не эффективны и кэш гугла теоретически может повысить безопасность всей схемы. Тут есть над чем подумать. С другой стороны их аргументация типа апдейты их кэша тоже можно блокировать, как и доступ к CRL/OCSP, но их нужно блокировать дольше, лишена смысла.
    Кстати, эта тема не такая уж простая и, думаю, не каждый в голове держит эту многоходовку http://technet.microsoft.com/en-us/library/ee619754(WS.10).aspx
    Посему слишком толстый заголовок для поста. Опять же я, надеюсь, они отключат это только по дефалту (и одноразово в текущих инсталляциях) и возможность включить в настройках оставят, иначе это игнорирование стандартов и это глупо. А такой подход, что мы тут подумали за вас и решили сделать так, как нам понравилось, выглядит не взвешенным и не согласованным.
    Предвижу, что в корпоративной среде, после этого хром вообще использовать нельзя будет.

    1. xentronium:

      > на других ОС оно, видимо, уже с собой таскает и список корневых/доверенных сертификатов

      Я не уверен, но по-моему, хром использует нативные хранилища. Во всяком случае, на linux и mac os x.

      1. Прошу прощения, а что в линукс есть централизованное хранилище для корневых сертификатов, которое используется всем софтом, а кем оно маинтейнится. Что действительно есть?

          1. Это не линукс. Это костыли от мозилы.

            Я тут глянул в нетворкмонитор, Хром OCSP Stapling как то по-своему реализует, сам он в клиентхелло соответсвующее расширение не выставляет (экономят на байтах?), но сервер ему всё равно его пихает в серверхелло. Обрабатывает Хром ответ или нет надо сорцы смотреть, а это ад. Я не в курсе, по RFC это или нет, надо бы освежить знания. Кстати, фаерфак так же себя ведёт. Опера корректно всё делает. Сафари не смотрел.
            Кстати, кому интересна тема есть продвинутый чувак, вот полистайте его блог:
            http://www.carbonwind.net/blog/post/Random-SSLTLS-101-OCSPCRL-in-practice.aspx

      2. Всё правильно написано автором выше, т.е. нет «стандартного нативного хранилища». Оно и в винде-то разное от версии к версии, по сути. Поэтому таскать своё хранилище — да, в принципе, логично (ну, заодно и под хромиум задел — ведь даже у мелкой ОС надо сделать локальное хранилище сертификатов). Но все равно суть не меняется — заявления про «https дико тормозит из-за OCSP» — фигня полная. Метод «мы будем гуглоботом crawl’ить ваши CRL, а потом глобально впихивать их в наш браузер — вообще неживой. Что делать с CRL’ами, которые IDP? С дельтами? Ну, у организации X удалось нагуглить базовый CRL и две дельты, а судя по расписанию должны быть ещё 2 дельты — что делаться будет? Ломовой вопрос — а CRL’ы внутренних CA, с ними что? Много вопросов. Как механизм будет работать — периодичность, задачи? Как вообще представляется в гугле «планетарный сборный CRL»?

        Очень напрягает вот такой момент:

        Since we’re pushing a list of revoked certificates anyway, we would like to invite CAs to contribute their revoked certificates (CRLs) to the list. We have to be mindful of size, but the vast majority of revocations happen for purely administrative reasons and can be excluded. So, if we can get the details of the more important revocations, we can improve user security.

        Т.е. они ещё и не всё будут из CRL добавлять, а только «с нашей точки зрения нужное», притом четкого критерия нет — ведь «vast majority of revocations happen for purely administrative reasons and can be excluded». Конкретики нуль, по сути. А зная гугль — они ещё и на ходу втихую переигрывать будут логику алгоритма.

        Кто уже хочет докупить плагин к хрому «Полноценная проверка сертификата на отзыв», недорого? :). Плагин, безусловно, будет запрещён в онлайн-магазине для хромиума — потому что «данный плагин ухудшает поисковую выдачу». 😉

        1. Полностью согласен, придумали фигню и теперь преподносят как фиерический успех в повышении безопасности и скорости работы браузера. Юзали бы SCHANELL как в ранних сборках Хрома и не парились бы. В Windows это спецальный механизм для всех, нет мы свой велосипед пристроим сбоку. И да, будем в него всякие эксперементалбные драфты внедрять, чтобы мозг другим выносили (вспомните историю с TLS False Start, у нас куча народа обламалась из-за этого дебильгного эксперимента, блин сколько нам это стоило, весеть на телефоне и объяснять как это отключить, ладно хоть M$ патч сделали, хотя изначально не собирались, мотивируя, что это блин эксперементальный драфт, кто ж его по дефалту то включает?).

          Интересно как в Comodo Dragon эти изменения перетекут, Comodo как никак тоже свои CA держит.

    2. xentronium:

      Кстати, на удивление взвешенный комментарий с учетом специфики сего блога.

    3. Ах, да, я ещё про OCSP Stapling забыл, оно как раз для этой хни и придумывалось, а в гугл и не знали. 😉

      1. Оно вообще там работает? Буду дико ржать, если нет. Хотя в IE тоже есть свои сложности.

  7. xentronium:

    Кажется, ты немного не правильно понял.
    То, что гугл не будет проверять PKI — это только половина решения.
    Вторая половина решения — база отозванных сертификатов/авторитетов будет храниться локально и пушиться апдейтом (видимо, придумают способ без перезагрузки браузера).

  8. То, что дыр много — ладно, у кого их нет? Да и EMETом/отдельной учеткой позакрывать много что можно.
    То, что хром подвержен BEAST — не так страшно, т.к. уязвимость очень трудно эксплуатировать.
    Но, блин, CRL не проверять — это вообще пушка. Такое палево! Ждём волны фишинга…

  9. То есть, гугловские ДНС дурачки себе уже прописали, теперь будут сидеть с гугловским кешем сертификатов, ага. Дальше гугл скажет, что пользоваться нужно только Правильным Свободным гугл-протоколом ХТТП, а все остальные — несвободные.

    1. Гугловский DNS нам не подходит, потому как имеются внутрисетевые ресурсы в зоне .local. Уже несколько таких прописавших 8.8.8.8 звонили «а почему это у меня на местный ФТП не заходит?»
      Интересно, этот 8.8.8.8 ведет статистику, кто какие домены ресолвил? Зная гугл, предположу, что да.

Обсуждение закрыто.