Корпорация добра

Свершилось!

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

Гугл заботится о Ваших данных! Правда, своей, сложною любовью.

Google изменила метод шифрования HTTPS, используемый службами компании, для того, чтобы в будущем защитить передаваемый трафик от расшифровки.

Автор язык русский знать и говорить им хорошо так что сначала кажется, что Гугл сделал какой-то свой личный HTTPS. А всё проще:

Для того чтобы снизить вероятность расшифровки трафика, Google ввела свойство, которое гарантирует, что при компрометации одноразового ключа, доступ к данным, защищенным остальными ключами, будет закрыт. Данное свойство протоколов известно как совершенная прямая секретность (Perfect forward secrecy).

PFS! Какой, однако, свежак: данная технология есть в Windows с 1999 года. На данный момент в Technet, к сожалению, статьи про Windows 2000 уже практически не найти, но есть про Windows 2003: http://technet.microsoft.com/en-us/library/cc779969(WS.10).aspx , да и при желании можно проверить наличие оного — копнуть любой материал по настройке IPSec на Windows 2000 и увидеть наличие данной фичи: http://www.dlink.ru/ru/faq/92/516.html например.

Всего-то 12 лет как есть в Windows, а в материале подано ну просто как killer-feature имени Google по защите данных. Прекрасно, прекрасно. Дальше, правда, ещё круче:

Таким образом, злоумышленник, который сможет взломать один из ключей, не сможет получить доступ к большей части трафика, например, службы электронной почты Gmail.

Переводчик точно не понимает, что такое PFS и как оно работает, потому что из данной фразы следует, что до включения PFS можно было, взломав один из ключей, получить доступ к большей части трафика Gmail. Если это так, то Google имеет смысл самораспуститься прямо сегодня вечером. Но не суть. Дальше он [излагающий] просто превосходит сам себя:

Новое HTTPS решение от Google используют ECDHE_RSA код для обмена ключами и RC4_128 алгоритм для их шифрования. К сожалению, такая комбинация на данный момент поддерживается только браузерами Firefox и Chrome. Это означает, что HTTPS связь в браузере Internet Explorer будет менее безопасной.

Видите, как всё логично — FF и хром хорошие, IE плохой. Старшеклассники с акне откладывают в сторону аниме, вытирают руки об майки с пингвинами и аплодируют.

На самом же деле всё просто.

Алгоритм RC4-128 является вообще одним из самых древних симметричных алгоритмов, которые применяются в современных ОС. Он 1987 года, и в целях безопасности и он, и его младший друг RC2 вообще обычно отключаются (например, вот так). В нормальных, современных реализациях, уже много лет как используется ощутимо более лучший алгоритм AES. Например, начиная с ядра NT 6.0 (это Windows Vista и Windows Server 2008) для защиты в SSL и TLS используется куча вариаций связок ECDHE и AES с разными длинами ключа:

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

Зачем же это гуглу? Да всё просто — пиарить в конце 2011 года RC4 как ультрапрорыв в плане безопасности можно только в случае, когда надо, чтобы до данных клиентов был доступ. Да и чтобы отвлечь внимание от другого фейла — того, что на данный момент известна атака на SSL 2.0/3.0 и TLS 1.0, а с поддержкой TLS выше 1.0 у Chrome проблемы. Проблема проста — полноценной поддержки TLS 1.1 и 1.2 в хроме просто нет, тут он проигрывает Internet Explorer 9, в котором эта поддержка есть изначально.

Резюмируя новость о том, как Google заботится о данных клиентов:

  • Новость представляет из себя сообщение о том, что Google начал использовать технологию PFS (есть в Windows с 1999 года) и предлагает в конце 2011 года аж включить поддержку аж ECDHE+RC4 (в Windows ощутимо более лучшая связка ECDHE+AES есть с 2006 года).
  • Новость аккуратно обходит тот факт, что софт от Google до сих пор поддерживает только уязвимые реализации TLS (в отличии от ПО других производителей, которое достаточно давно поддерживает современные TLS 1.1 и TLS 1.2).
  • Предлагаемое Google решение по защите трафика менее безопасно, чем реализуемое, например, на идущей из коробки Windows Vista.
  • Компания Google мало того, что умышлено ослабляет защиту передаваемых данных, согласовывая в SSL/TLS старые cipher suites, так ещё почему-то выдаёт это за огромную заботу о безопасности клиентов. Для желающих проверить огромность заботы — попробуйте зайти на gmail с использованием протоколов TLS 1.1 или TLS 1.2 (они точно безопаснее SSL и TLS 1.0), или при жестко выставленном со своей стороны SSL/TLS-сессии протоколе AES. Вышло? Вот она, забота-то — пользуйте RC4, который был ещё в Windows 95 OSR2 (в MPPE, если быть точным).

Пользуйтесь ПО от Google — это безопасно и надёжно. Этим парням можно доверять свои персональные данные как никому другому! Они их защитят, ага. Шифром Цезаря, выдав его за ультрахайтех.

UPDATE: В комментариях состоялась попытка объяснить, что гугл на самом деле защищает клиентов, а остальное просто гадкие журналисты выдумали. В ходе попытки был вывален вагон мифов, показывающих либо относительно слабое знакомство мифолюбителей с криптографией, либо умышленное желание ввести читателей в заблуждение. Я выпишу часть мифов сюда.

ГУГЛОМИФ N1: Включая дефолтным cipher suite с RC4, мы защищаем клиентов от BEAST.
РЕАЛЬНОСТЬ: Для защиты от BEAST надо не дефолтным включить cipher suite с RC4, а оставить его вообще единственным, т.е. выключить все остальные. Пока это не сделано — защиты от BEAST нет. То есть предложенная гуглом мера является «костылём», который, вдобавок, ещё и не решает свою задачу.

ГУГЛОМИФ N2: TLS 1.1 и TLS 1.2 в хроме нет потому что они не нужны (глючные), плюс сам Microsoft их отключает, плюс у них проблемы с совместимостью
РЕАЛЬНОСТЬ: TLS старше 1.0 в хроме нет, потому что нет в openssl. В openssl нет, потому что по доброй традиции СПО, на безопасность клиента — насрать, абы как работает, вот и нормально. Это и есть лозунг гугла в плане безопасности, по сути.

Далее. Стандарту TLS 1.1 уже более 5 лет (он от апреля 2006 года), почему его за это время не реализовали и спешно делают сейчас — вопрос к гуглу и авторам openssl. У каждого из протоколов — TLS 1.1 и 1.2 — свои дополнительные фишки в плане безопасности, вполне заметные, достаточно почитать сами стандарты. Microsoft эти стандарты никогда не «отключал», и проблем с совместимостью у них нет — т.е. работа TLS 1.2 в общем никак не пересекается с работой TLS 1.0 и SSL 3.0, например.

ГУГЛОМИФ N3: Вообще RC4 и так безопасный!
РЕАЛЬНОСТЬ: Достаточно открыть любую литературу по криптоанализу, чтобы выяснить, что у изначально потокового RC4 достаточно много проблем на уровне дизайна, которые ощутимо снижают его безопасность. Именно поэтому основным протоколом с секретным ключом долгое время был DES, а после — AES. Переключение на RC4 в ноябре 2011 года — это ощутимое снижение уровня безопасности.

А вообще сам по себе подход гугла — «сделаем хуже, а пропагандой объясним, что лучше» — настораживает.

Как понятно, всё это — хитрая реклама утилиты, при помощи которой можно настроить SSL/TLS и криптографическую подсистему.

Реклама
Корпорация добра

Корпорация добра: Один комментарий

  1. Alexey Drozdov :

    Хорошо, прореплицирую тут свой пост, дабы как минимум просто не пропадал :)

    ************************************
    Доброго начала недели, коллеги по цеху и все остальный.

    Приятно удивлен, что тема активна и интересна.
    Руслан, спасибо за ее создание.

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

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

    Ну а теперь давайте сначала сформулируем ключевые вопросы обсуждения:
    1. Гугл ламер и не понимает в безопасности ничего или делает это спечально.
    (мнение основано на том, что дескать ввел деволтовый ECDHE_RSA_RC4_128)?
    2. Спасает ли RC4 атаки типа BEAST?
    3. Помогло бы включение на сервисах гугла TLS 1.2 здечь и сейчас от BEAST?
    4. Правльно ли выписан сертификат для http://www.kernel.org?
    5. Как все вышеобозначенное соотносится с фишингом? И что это такое вообще?

    А теперь попорядку и БЕЗ ПОПЫТОК уйти в сторону.

    1.
    Я уверен, что

    Алексей, Вы вообще здоровы?

    Вы тут третьи сутки на борцовский мостик выходите, объясняя, что зелёное — необязательно зелёное, зато часто мягкое и делится на 17 нацело.

    Постинги все есть, можно прочитать дискуссию с самого начала, там всё очень подробно разобрано.

    Что Вы пишете-то ересь какую-то сейчас? Вы почитайте:

    > 1. Гугл ламер и не понимает в безопасности ничего или делает это спечально (мнение основано на том, что дескать ввел деволтовый ECDHE_RSA_RC4_128)

    Нет. Формулировалось другое — что у гугла точно есть финансовые возможности сделать хорошо, и текущим действием — сменой дефолта на RC4 — он осознанно делает _хуже_чем_было_. При этом, удивительно, шестой год как не может реализовать TLS 1.1. Наличие которого делало бы это обсуждение не нужным.

    И что значит «дескать»? Он что, не ввёл этот suite дефолтным? Что за очередные увиливания?

    > 2. Спасает ли RC4 атаки типа BEAST?

    Что за бредовая формулировка? Что спасает? Сам алгоритм? Нет. Сам алгоритм данные шифрует. Херовенько, кстати, шифрует. Хуже чем AES.

    > 3. Помогло бы включение на сервисах гугла TLS 1.2 здечь и сейчас от BEAST?

    Помогло бы включение TLS 1.1. Почему Вы всё время передёргиваете в таких «мелочах»?

    > 4. Правльно ли выписан сертификат для http://www.kernel.org

    Алексей, Вы, случаем, не наркозависимый? У http://www.kernel.org вообще нет сертификата. Сертификат есть у https://kernel.org, и выписан он на другой FQDN. Поэтому при открытии возникает ошибка — что узел A предъявляет сертификат узла B. Всё.

    > 5. Как все вышеобозначенное соотносится с фишингом? И что это такое вообще?

    Раз пять уже в треде написано. Так трудно прочитать?

    Алексей, Вы попробуйте всё ж свои силы бросить на полезные дела — вместо того, чтобы отстаивать заплесневелую честь гугла, в очередной раз пойманного на любви к защите данных пользователей, например подучили бы криптографию. Чтобы не говорить, что RC4 может по CBC работать, например. А то у меня от этого вашего заявления кота в ванную вырвало.

    И нет смысла в Вашей ситуации писать объяснительные такого характера. Все комментарии открыты, все целы, всё можно прочитать. Хорошо видно, кто и что утверждал, и кто на это что отвечал. Зачем при такой ситуации-то постинги вида «Я сейчас объясню, как на самом деле было!». И так же видно.

    Что ж на хабре-то и секлабе заткнулись с такой скоростью пропагандоны, которые идентичными словами синхронно славили очередной прорыв в защите гуглом данных-то? Ну, чего им стесняться/скрывать, если всё на самом-то деле очень хорошо?

  2. Наоборот, он не требует активного перехвата, для данного метода достаточно просто сниффать трафик.

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

    Подменить client hello можно было только для ssl2.
    В более поздних версиях он уже защищен хешами, так что не получится. Это можно будет сделать только при условии, если подсовывать другой сертификат (ну и , есвественно, в случае спертых ключей).

    Хм, вполне допускаю, что я ошибаюсь, но я в упор не вижу где хешируется client-hello. Более того, на этом этапе даже неизвестно ЧЕМ можно хешировать так, чтобы оба участника поняли друг друга. Не могли бы Вы прояснить что Вы имеете в виду.

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

    Да. О том и речь

    Если клиент откажется от поддержки его на своей стороне, то кому от этого легче будет?

    Легче будет Мэллори.

    1. Alexey Drozdov:

      Руслан, почему ты не опубликуешь мой развернутый комментарий?
      Что мешает?

      Или ты решил выехать на силе «цензуры»?

      В комментарии я высказывал свое видение, которые ты значительно исказил, и настаиваешь, на том, что я не заявлял.

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

        То, что гугл в 2011 году рекомендует RC4 как крутую меру безопасности — это, безусловно, фейл. То, что гугл сам не может / не хочет реализовать TLS 1.1 (а говоря проще — ждёт, пока его доделают в openssl, чтобы оттуда спиздить) — тоже фейл. Через месяц 2012й год, а безопасность в плане SSL/TLS у хрома хуже, чем у IE9 выпуска 2009 года. Зато на секлабе беготня пропагандистов — «это ультранововведение, RC4, сделает браузер Chrome гораздо более безопасным, чем IE!». Позор, мужики — миллиардная корпорация, а пропагандисты уровня журнала «хакир».

        Как там с CBC в RC4-то дела продвигаются, лол? Скоро будет? Когда уже наконец-то гугл объяснит черни, что шифровать DES’ом — самое правильное? (тут должна быть картинка с плакатом «БЛОГЕР! ПИШИ МЕДЛЕННЕЕ, УВАЖАЙ ТРУД СОТРУДНИКОВ ФСБ, КОТОРЫЕ ЧИТАЮТ ТВОЙ ТРАФИК», она очень в тему).

        Очень понравилось, как на хабре постинг про это проскочил. Тоже гуглоиксперт вылез, абсолютно теми же словами, что и на секлабе, написал про «ололо пабеда гугла сикурно не то что в MS», а ему дали в комментариях ссылку на этот постинг, он ВНЕЗАПНО сразу свою публикацию переместил в черновики. Наверное, его тоже не так поняли, правда, а на самом-то деле он уууууу что хотел сказать, да? Просто теми же словами. СЛУЧАЙНО. 😉

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

        Кстати, как с сертификатом https://kernel.org ? Сколько чинить будут, какие прогнозы? 🙂

        1. Alexey Drozdov:

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

          Выполни уж проверку 🙂
          Почему ты не хочешь его пропустить?

          1. Алексей, у меня есть ощущение, что Вы, как бы так сказать вежливо, «сорвались». По делу ничего не пишете, по 3 раза попробовали одно и тоже написать — я каждый раз детально разобрал, что и как. Теперь включили известную в этом блоге шарманку «да меня тут модерят». Тут никого лет 5 как не модерят, даже конченых дебилов. В вордпрессе встроенный механизм фильтрации тупо делает ручной аксепт первого поста, дальше — без аксепта. Вы ж сейчас написали, и сразу ведь появилось, правда? Ну, как же так получается, если Вас преследуют и модерят? 🙂

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

          2. Alexey Drozdov:

            Хорошо, прореплицирую тут свой пост, дабы как минимум просто не пропадал 🙂

            ************************************
            Доброго начала недели, коллеги по цеху и все остальный.

            Приятно удивлен, что тема активна и интересна.
            Руслан, спасибо за ее создание.

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

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

            Ну а теперь давайте сначала сформулируем ключевые вопросы обсуждения:
            1. Гугл ламер и не понимает в безопасности ничего или делает это спечально.
            (мнение основано на том, что дескать ввел деволтовый ECDHE_RSA_RC4_128)?
            2. Спасает ли RC4 атаки типа BEAST?
            3. Помогло бы включение на сервисах гугла TLS 1.2 здечь и сейчас от BEAST?
            4. Правльно ли выписан сертификат для http://www.kernel.org?
            5. Как все вышеобозначенное соотносится с фишингом? И что это такое вообще?

            А теперь попорядку и БЕЗ ПОПЫТОК уйти в сторону.

            1.
            Я уверен, что

  3. Alexey Drozdov:

    2chivemind :
    BEAST же требует активного мима

    Наоборот, он не требует активного перехвата, для данного метода достаточно просто сниффать трафик.

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

    Также был комментарий, что типа надо запрещать все кроме rc4.
    Но тут хочу заметить, что алгоритм выбирает все же сервер из списка пересечений множеств, предложенных клиентом и поддерживаемых сами сервером.
    Т.е. для заданного сервиса можно настроить, что будет при возможности выбираться именно rc4.
    Если клиент откажется от поддержки его на своей стороне, то кому от этого легче будет?

    А если учитывать, что 99% пользователей никогда не меняют настройки браузеров, то результат на лицо. Что бы при этом ни говорили.

    1. > Также был комментарий, что типа надо запрещать все кроме rc4.

      Также после фейла в основном треде начались поползновения в боковых.

      > Т.е. для заданного сервиса можно настроить, что будет при возможности выбираться именно rc4.

      Да-да, именно это и будут делать все пользователи, поэтому мегапрорыв в безопасности состоялся, ага.

      > А если учитывать, что 99% пользователей никогда не меняют настройки браузеров, то результат на лицо. Что бы при этом ни говорили.

      Да, и он, повторюсь, прост:

      1. Смена дефолтного cipher suite на _RC4 не защищает от BEAST.
      2. Смена дефолтного cipher suite на _RC4 ухудшает безопасность, т.к. подавляющее большинство клиентских браузеров давно умеют AES.
      3. В хроме до сих пор не реализован TLS 1.1, RFC по которому вышел в апреле 2006 года (сейчас ноябрь 2011). В других продуктах (IE9 например) данный стандарт, да и 1.2 тоже, уже есть из коробки несколько лет как.
      4. В результате гугл предоставляет более плохой по уровню безопасности сервис, чем остальные браузеры, умышленно ухудшает защиту данных в своих, не раскрываемых целях, очень серьёзно отстаёт по уровню безопасности своего ПО и обманывает клиентов, пытаясь представить свой нерабочий костыль как некий вариант решения проблемы, которую сам гугл тем, что не сделал поддержку современных версий TLS, себе и создал.

      Когда, ну когда же гугл переведёт шифрование данных клиентов на RC2-40bit? Ведь это ещё безопаснее, главное ж пропаганду запустить вовремя, люди ведь должны знать Правду?

  4. Alexey Drozdov:

    >>В данном случае – предложенный Вами редирект (когда после установки SSL-сессии с сайтом будет идти перенаправление на сайт с другим FQDN) – это как раз фишинговый ход, а не нормальная мера безопасности. Т.е. в сертификате написан сайт X, Вы на него начинаете заходить, а он Вас редиректит на сайт Y. Это как бы плохо сильно.

    Вот рассмотрим хотя бы 1 конкретный пример:
    Есть ресурс
    https://www.bankofamerica.com/
    Есть ресурс
    https://bankofamerica.com/

    При заходе на второй, редиректит вас на 1-й.
    FQDN разные.

    Поясните что тут «плохо сильно»?

    Именно для данного случая, не затрагивая более никакие посторонние вопросы 🙂

    1. То есть сайт предъявдяющий невалидный (для запрошенного домена) сертификат:
      https://www.ssllabs.com/ssldb/analyze.html?d=kernel.org

      это в общем то же самое, что и сайт, предъявляющий два сертификата для двух разных FQDN (и редиректящий с одного на другой)
      https://www.ssllabs.com/ssldb/analyze.html?d=bankofamerica%2ecom&s=171%2e159%2e228%2e150
      https://www.ssllabs.com/ssldb/analyze.html?d=bankofamerica%2ecom&s=171%2e159%2e228%2e173

      PS: А Вы уже выслали баг-репорт в гугл?

      1. Я, в принципе, то же самое у него спрашивал. Т.е. я не понимаю, человек реально не видит разницы между «на несколько разных доменов один сертификат с именем одного из них и перекидывать пользователя по своему желанию» и «несколько доменов, у каждого валидный сертификат с его именем»? Вроде ж очевидно.

      2. darkhead:

        Давайте еще в Мозиллу вышлем, пусть там поржут ))

        1. Ну а в Microsoft ничего высылать не будем. Ясно ж, что это все оттого, что там одни индусы.

          Вообще поначалу Алексей выглядил довольно вменяемым (уровень значительно выше, чем привычные линукс-мантры). Даже вот этот непольшой прокол с сертификатами — ну ошибся умный человек, и что? Все ошибаются, но умные люди просто признают свои ошибки, а не начинают юлить и говорить про папу-начальника-ФСБ и собственную митол-группу.

          Или вот тот же BEAST. Опять таки, после неоднократных недвусмысленных намеков на то, что если уже и так есть активный мим, то модификация client hello для обхода «гугловых бизапастных дефолтов» не составит труда, единственной ситуацией, в которой такая мера действительно могла бы быть эффективной против биста — это запрет всех остальных сьютов, что тоже неоднократно прямым текстом говорилось. И что же? Да, как обычно:

          В отличии от вас я непосредственно использую его в разработках, которые используются по всему миру (да да ) и поэтому как никак на техническом уровне поболее знаю как оно на самом деле работает, а не просто на уровне додумок типа «но в реализации в любой ОС» и др.

          Тьфу

          1. Я, кажется, ему раза 3 это напрямую написал — очевидно же, что смена дефолта никак не повлияет на то, что зараженный клиент тупо откажется от неудобного дефолта и согласует другой cipher suite, и атака пройдёт. Чтобы не работало, надо оставить _только_ suit’ы с RC4.

    2. Алексей, Вы действительно не понимаете, как работает SSL? Это плохо. Я достаточно подробно расписал ответ на этот Ваш вопрос в предыдущий раз и повторю ещё. Сам по себе редирект — это не фишинг. А вот когда сертификат с 1 FQDN используется для доступного по нескольким FQDN сайта, и пользователь, зашедший по FQDN, который есть в сертификате, после редиректится на FQDN, которого нет — то вот это очень плохо.

      В Вашем примере (откуда Вы зачем-то убрали упоминание про сертификат и наличие в нём только 1 FQDN) — если на оба указанных URL будет привязан сертификат, допустим, с http://www.bankofamerica.com, и пользователь зайдёт на этот же URL, а его оттуда безусловно перекинут редиректом сразу на bankofamerica.com, и предъявят тот же сертификат (т.е. именно то, что Вы предлагали как «вариант решения» для ситуации с kernel.org), это как раз будет плохо. Поэтому сейчас с настройками https на kernel.org — ошибка. Про которую пишет любой браузер, как бы Вам это не было неприятно. Состоит она (ошибка) в том, что в поле SAN сертификата не добавлено одно из действительных имён сайта. Выхода два — выписать другой сертификат или убрать https-привязку с kernel.org. Пока это не сделано — https настроен с ошибкой, достаточно простой и очевидной. Поэтому я это и использовал для иллюстрации в стартовом примере — ну, а заодно выяснились Ваши пробелы в знаниях работы HTTPS.

  5. Alexey Drozdov:

    Вы, уважаемый эмоциональный, истинный мастер демагогии.
    Вам про красное, а вы доказываете, что синее круче зеленого.

    Толку от такого диалог 0 — вы просто не хотите слушать, о чем вам говорят, а додумываете, что вам хотели «вроде как» сказать.

    Вообще-то что касается ваших заявлений о моем непонимании азов — это вообще ваше заблуждение.

    В отличии от вас я непосредственно использую его в разработках, которые используются по всему миру (да да 🙂 ) и поэтому как никак на техническом уровне поболее знаю как оно на самом деле работает, а не просто на уровне додумок типа «но в реализации в любой ОС» и др.

    Например под RC4_128_SHA я понимал его использования в видах
    типа TLS_RSA_WITH_RC4_128_SHA, ECDH_RSA_RC4_128_SHA и др. В таком виде они описаны, в частности, в RFC.
    Но, естественно, RC4 может самостоятельно быть использован в других видах и , в частности, как было сказано для блочной обработки, но это уже не относится к ssl.

    1. Алексей, я прекрасно вижу, что Вы попытались прикопаться, но у Вас ничего не получилось.

      В отличии от Вас у меня 1я форма допуска как раз связанная с криптосредствами. Это, судя по дискуссии, ощутимо лучше чем «я тут контрибутил во что-то криптографическое». Поэтому именно я Вам на Ваши ошибки указываю, а не наоборот. Вы знаете криптографию на том уровне, что не сдали бы второй семестр первого курса в ИКСИ. Вас бы взрослые дяди скушали, весело и с юмором. Вы посмотрите, как Вы «RC4 знаете хорошо». То он у Вас безопаснее AES, то поточный и поэтому в нём нет режимов, то уже блочный но по CBC (!!!!). Наверное, если бы гугл сделал дефолтным RC2-40, Вы бы тут доказывали, что 40 бит — это тоже в принципе круто, и почти AES-256, ага.

      Поэтому, увы и ах — то, что гугл сделал дефолтным cipher suite с RC4, лишь понизило безопасность. И проблему с BEAST никак не решило. Браузер Chrome остался очень небезопасным — в нём до сих пор нет протоколов TLS 1.1 и TLS 1.2. Сейчас он в рассматриваемом криптографическом аспекте ощутимо слабее, чем дефолтный IE9.

      Ваши попытки время от времени то перевести тему, то занизить масштаб проблемы, вообще эпичны:

      > Предлагаемые сервисы не являются средством не предполагают изначально обмена гос тайн и т.п. Поэтому упоминания требований FIPS тут не уместны.

      Алексей, стандарту FIPS140 уже вообще тьма сколько времени. Он давно уже не столь указатель гостайны, сколь указатель поддержки более-менее приличных ограничений по безопасности. И включается вплоть до Windows 2000. И в него, в древний стандарт «нижней планки безопасности», входит как раз отключение старых хэш-функций, увеличение минимальной длины ключа RSA и отключение устаревших симметричных алгоритмов, в частности — RC4. Вы понимаете? Это не «мегагосбезопасность», это «нормально для 1999 года». То, что в ноябре 2011 гугл эту планку понижает ниже 1999, вообще никак в сторону повышения безопасности не повернуть.

      Я допишу в статью FAQ на основе основных Ваших заблуждений («это против BEAST спасает», «новый TLS не нужен потому что его в СПО не смогли сделать» и прочее).

  6. 123456qwertyu:

    Ruslan V. Karmanov :
    С IE был фейл гораздо, гораздо эпичнее, чем медленное открытие вкладок. На IE9 нельзя было на сайте Microsoft нажать кнопку «Оплатить» в тренерском разделе. Т.е. тренер Microsoft – MCT который – раз в год платит некую сумму (37.5$ обычно). Вот форму заполнить можно было, а кнопка нажималась только под хромом или FF. Было в апреле, интересно, поправят ли к этому.

    Ну, баги-то везде бывают.

    Но, откровенно говоря, когда я узнал, что в IE9 сделали разделение «вкладка=процесс», я был очень разочарован. С моей точки зрения, это костыль к стабильности. Это подпись разработчиков под текстом: «мы не можем сделать не падающий браузер и потому выносим вкладки в процессы для того, чтобы падала максимум одна вкладка». Ну да, я понимаю, что стабильность браузера на 98% зависит от используемых в нём плагинов (у меня никакие браузеры не падают, ага, ибо ванильные или почти ванильные — и кстати, именно за это я люблю Оперу: жестовый функционал и прочие плюшки у неё не в виде плагинов-глюкал, а в ядре), но могли бы, что ли, только особо корявые плагины в отдельный автоматически перезапускаемый процесс вынести, как это сделали в FF, а не вкладки целиком. Оверхэд же дикий от такого подхода, и по процессору, и по памяти…

    1. Alexey Drozdov:

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

      Что касается оперы, то ей пока везет, что она занимает максиму 1 % в пользовательском сегменте. Вот когда она будет «отсчитываться» за хотя бы 10%, то поверьте, будут совсем иные вопросы обсуждаться.

      При всем при этом, конечно, не стоит путать идеи и реализации, которые. Моя практика показывает, что нет сейчас ни одного эталонного браузера. К сожалению 😦
      И в первую очередь это связано с политикой.

      1. 123456qwertyu:

        > А с чего вы взяли, что таким образом решается _только_ проблема падений?
        Полагаю, также таким образом даётся возможность запускать каждую вкладку с разными привилегиями («защищённый режим» в одной вкладке, его отсутствие — в другой). Однако, это можно было бы решить выполнением не более трёх экземпляров браузера (контейнер «защищённых» вкладок, контейнер «незащищённых» и фронтэнд/координатор).

        Я что-то ещё забыл?

        > чуток бы по иному взглянули на многие вещи и не пришлось бы разочаровываться.
        IE9 — браузер, который медленнее всех на рынке открывает новую вкладку. На нетбуке после открытия десятка-другого вкладок с ним работать вообще тяжко. С моей точки зрения, это очень большой минус в его User Experience, и это здорово перечёркивает все его несомненные плюсы. Метафорически: если автомобиль со светофора еле трогается, всем пофигу не только на крутость его противоугонки и подушек безопасности, но даже на максимально достижимую им (после разгона) скорость.

        > Что касается оперы, то ей пока везет, что она занимает максиму 1 % в пользовательском сегменте.
        Я понимаю это. И по этой причине даже не особенно хочу увеличения её доли. А то ещё начнут ломать 🙂 её положение «Картонного Джо» меня полностью устраивает.

        > Моя практика показывает, что нет сейчас ни одного эталонного браузера
        Увы. Вот бы функционал «из коробки» и скорость Оперы, да к защищённости и управляемости IE, да со встроенным адблоком…

        1. Alexey Drozdov:

          Для начала хотелось бы сказать, что в том же IE9/IE10 встроен некий алгоритм, что позволяет группировать ряд вкладок в один процесс, что в итоге приводит не к линейному росту процессов.

          Действительно, повышение юзабилити для пользователей за счет исключения падения всего браузера это одна из ключевых причин.
          Но не единственная.
          Разнесение по процессам позволяет изолировать среду исполнения при работе на разных ресурсах, т.к. в случае использования неизвестной уязвимости значительно снижается риск того, что будет получен доступ к данным.
          Далее это позволяет ограничивать загрузку ряда плагинов в процессы, которым они не нужны, что также повышает безопасность.

          Например с chrome пошли еще дальше — там реализованы песочницы в процессах, которые стараются неким образом также защитить процессы вкладок от вмешательства из-вне.

          Далее, это позволяет проще бороться с утечками памяти. Достаточно вспомнить FF 7, когда он мог спонтанно начать кушать по 2 гига памяти и кроме полного перезапуска процесса ничего не помогало.

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

          В целом есть и еще доп бинефиты, но смысла вдаваться в детали пока не вижу.

    2. Почитайте что нибудь. Опере вообще по фигу на безопасность и никаких попыток «запесочивания» даже не предпринимается, а Fx в лучших традициях опенсорсных карго-культов сделал отдельные процессы, но не позаботился о понижении прав для этих процессов.

      То что Вы предлагаете было реализовано в IE7 (один процесс — PMIE, один процесс — все остальные), К тому же, как уже было отмечено, IE8+ не предоставляют каждой вкладке по процессу.

  7. alexeydrozdov :

    Они сделали ECDHE_RSA_RC4 по дефолту. Браузеры Firefox и Chrome будут его использовать.
    Учитывая вопросы обратной совместимости (это самое ключевое!) более коренные изменения сделать пока у них не получится.

    Если они прямо сейчас бы включили TLS 1.1+ и сказали , что все зашибись, то большинство пользователей увы, были бы введены в заблуждение, ибо их браузеры не готовы к этому :)

    Т.е. _на данный момент_ это адекватный шаг, при этом же надо понимать, что это временное решение, так как было рекомендовано отключать пересогласование на серверах после освещения атаки на него в 2009.

    Что именно в нем кривого? что он чисто wildcard?
    Вот можно даже для наглядности:
    https://www.ssllabs.com/ssldb/analyze.html?d=www.kernel.org

    Я про редирект на сервере имел в виду – сами по себе они никакой опасности не несут.

    Вы предполагаете, что установка дефолтным cipher suite ощутимо устаревшей связки с RC4 — это плюс? Вроде ж в предыдущем комментарии разобрались — от Beast это не спасёт, схема обмена ключами тут не при чём. В чём профит-то, с Вашей точки зрения?

    Если бы они прямо сейчас включили TLS 1.1+ в качестве дополнения к существующему TLS 1.0, то было бы только хорошо. На совместимость бы это не повлияло — те браузеры, которые не умеют 1.1+, ходили бы по 1.0, а обладатели более безопасных браузеров получили бы профит. А Вы так пишете, как будто или TLS 1.1, или 1.0. Это не так, совсем. Вводить в заблуждение — это то, что в статье на секлабе, на которую мы договорились не ссылаться. Где «там фключили RC4 поэтому IE хуже чем FF». 🙂

    На данный момент добавление в поддерживаемые cipher suites ECDH — это, конечно, лучше, чем его отсутствие, но выдавать это за новую и мегафичу — это не айс вообще. Это давно есть — со времени той же Vista — и поддерживается там без крестных ходов, плясок с бубнами, и анонсов компании Microsoft. И не подаётся оной как Мегафича Для Защиты Клиентов В Отличии От Гадких Конкурентов.

    Кривое в сертификате то, что в SAN неверно указаны имена. Есть четкий стандарт, как их надо указывать — браузеры абсолютно единодушно сообщают, что сделано неправильно. Такой косяк на таком уровне — это тот самый показатель уровня «абыкакателей» и «итаквродекакпашет».

    А редирект на сервере в случае SSL-сертификата на другое имя называется гнусным словом «фишинг». Не рекомендую так делать. 🙂

    1. Alexey Drozdov:

      Ну зачем же повторять в N-й раз, про старость RC4. Чего бы тогда про возраст RSA и DH не упомянуть — так было бы более корректно.
      Надежность RC4-128 вполне адекватна на текущий момент.

      А помогает решать проблему атаки BEAST потому что не используется CBC.

      До сих пор не могу понять претензии к гуглу именно по поводу SSL-я.
      Я постоянно отслеживаю их наработки в данном направлении, предложения и то, что они постоянно внедряют на своих серверах и в chromium. В частности, даже общался по работе с Адамом (автором первопричинного поста) — очень адекватный перец.

      Что касается версий более 1.0, то уверяю, что работы ведутся и результат скоро будет. Что касается хромиума, то он использует движек NSS, что и мозиловцы, так что оба проета ждут качественно имплементации и тогда — наступит счастье для жаждущих 🙂
      А не загорами и релиз openssl с поддержкой 1.2.

      Кстати, microsoft-то не даром отключал поддержку TLS 1.1+ для IE по умолчанию. Пример засады http://blogs.msdn.com/b/ieinternals/archive/2011/03/25/misbehaving-https-servers-impair-tls-1.1-and-tls-1.2.aspx
      Так что не все гладко, как может показать, в датском королевстве.
      И тут снова на первом плане обратная совместимость, а не распальцовка по поводу крутизны безопасности.

      Мне кажется, что пока переживать-то особо нечего и тем более паниковать.
      Даже больше хочу сказать — уменя складывается ощущение, что «паникуют» больше бабкосрубатели — надо же новую веху внедрять 😀

      И возвращаясь к сертификату 🙂
      В нем вообще на заданы альтернативные имена. Это не обязательный атрибут. Так что не вижу проблем с сертификатом. Да, могли бы и более удобно сделать, но это не является показателм их безолаберности или непонимания.
      И все браузеры нормально все сообщают для хоста http://www.kernel.org.

      Да, что-то вы про фишинг пугаете. Уточните его определение 🙂

      1. Про старость RC4 можно упомянуть, потому что данный протокол реально старый, и даже во времена, пока AES не было, что-то не использовался для действительно серьёзных решений, где требовался 3DES. А с появлением AES, который лучше DES и по скорости и по стойкости, RC4 стал совсем старым. Почитайте, ради интереса, хотя бы аналитику Брюса Шнейера на тему RC4 — очень хорошо показываются design problems, которые не решить реализацией.

        Поэтому Ваше сравнение некорректно — про устаревание RSA говорить смысла нет, а вот про устаревание RC4 — вполне. Не задумывались, почему RC4 странным образом при большей длине ключа, чем DES, не использовался в госсистемах — там, где использовался даже 112-ти битный вариант DES? Я намекну, что не всё от количества бит зависит — 128 бит RC4 необязательно лучше 112 бит DES. И уж точно не лучше 128 бит AES. 🙂

        > Надёжность RC4-128 вполне адекватна на текущий момент

        То-то такой завал использования RC4 в секурных решениях. Ускорителей RC4 аппаратных просто завал, ага. И запрещают к ввозу почему-то сплошь железки, реализующие RC4, ага. 😉

        > А помогает решать проблему атаки BEAST потому что не используется CBC.

        Алексей, что ж Вы так тему переводить стали? То, что шифр RC4 ещё и используется в херовом с точки зрения безопасности режиме ECB, а не CBC, только дополнительно показывает, что решения с его использованием ещё сильнее проигрывают тому же AES. Вы как-то путаетесь. Я Вам напомню:

        — Гугл сделал дефолтным cipher suite, который использует устаревший протокол RC4 — при том, что уже десяток лет как есть AES. Более того, в данной реализации RC4 работает в менее эффективном с точки зрения режиме ECB, что ещё сильнее ухудшает безопасность. Подавать этот двойной фейл как плюс в безопасности совсем нельзя. Обычный AES безопаснее и есть «из коробки» уже годы. Никаких прорывов.

        — Вы предполагаете, что это сделано для защиты от BEAST. Замечу, что это Ваше предположение. Оно достаточно легко дезавуируется тем, что для защиты от BEAST надо не дефолтным сделать слабый cipher suite на RC4, а _отключить_все_остальные_. Этого не сделано, поэтому как защитная мера от BEAST сие рассматриваться не может. Потому что не решает вопрос.

        > До сих пор не могу понять претензии к гуглу именно по поводу SSL-я.

        Может сейчас чуть яснее станет. Я могу повторить — новость, преподносимая как прорыв в безопасности, рассказывает об ослаблении оной, а реальная безопасность (реализация современных версий протоколов TLS) на данный момент у гугла не реализована. Вот совсем. Понимаете разницу между «не включено по дефолту» и «вообще нет в продукте»? Вот у меня почта на Exchange 2010. Я на неё подключаюсь по TLS 1.2. Для этого я его включил. И ряд проблем с безопасностью ушёл. Совсем. Если бы у меня был Chrome, я бы этого не смог сделать. Всё просто, никакой магии.

        > Я постоянно отслеживаю их наработки в данном направлении, предложения и то, что они постоянно внедряют на своих серверах и в chromium. В частности, даже общался по работе с Адамом (автором первопричинного поста) – очень адекватный перец.

        Алексей, хороший парень — это не профессия. Речь не про адекватность данного товарища, а про то, что в продукте X долго внедряется нужный функционал, который помогает от вполне конкретной проблемы. У других продуктов это уже есть, и давно. На фоне производитель продукта X делает ложные заявления о мерах по увеличению безопасности, которые оказываются фейком. Вот и всё.

        > Что касается версий более 1.0, то уверяю, что работы ведутся и результат скоро будет
        > А не загорами и релиз openssl с поддержкой 1.2.

        Ну вот как будет — так и посмотрим. Пока-то нет, уже несколько лет как. На реализацию забили, годы прошли, в старой реализации нашлась дырка. Теперь с горящей попой бегают. Serious business, да. Забота эбаут клайентс.

        > Кстати, microsoft-то не даром отключал поддержку TLS 1.1+ для IE по умолчанию

        Если бы Вы прочитали ссылку, которую нашли, видимо, в поисках «компромата на плохой новый TLS 1.1+», то заметили бы, что идёт речь о кривой реализации TLS на ряде серверов. Не Microsoft IIS’овских, если что. :))))))))))))))))))))))))))))))))). Да и Microsoft не «отключал», он просто «не включал по дефолту». Это чуть разные действия — если бы после конкретной ошибки у себя Microsoft выпустил патч, который бы реально что-то отключал — это один разговор. А тут — просто добавилась фича, но не включена по умолчанию. Так что Вы чуток не то нашли.

        > И тут снова на первом плане обратная совместимость, а не распальцовка по поводу крутизны безопасности.
        > Мне кажется, что пока переживать-то особо нечего и тем более паниковать.
        > Даже больше хочу сказать – уменя складывается ощущение, что “паникуют” больше бабкосрубатели – надо же новую веху внедрять

        Вы бы определились в своём отношении — то у Вас TLS 1.1+ не нужен, раз нет в гуглопродуктах, то скоро там будет. Распальцовка — это когда у продукта от Google нет современных реализаций TLS, есть только старые и дырявые, новые пишутся спешно, а на фоне говорится «А вы это… пока… ну… а, вот — на RC4 переключитесь, точно, так секурнее!». Уныло это, настолько на фейл похоже, что прямо-таки фейл.

        Бабкосрубатели — это, интересно, кто? В продуктах от MS это есть из коробки — что в 2008R2 Server, что в Windows 7. Даже в нулевых версиях, без патчей. Бабло на этом срубить разве что гугл может попробовать — ну типа выпустить безопасную реализацию и сделать помимо Самого Безопасного Облака Гугла например Пипец Какое Безопасное Облако Гугла — Почти Как У Microsoft Три Года Назад, Только Хуже, и брать за это дополнительную копейку. Т.е. MS-то это точно не интересно — продажи новых продуктов никак не вырастут, потому что фича есть уже в текущем поколении.

        > И возвращаясь к сертификату
        > В нем вообще на заданы альтернативные имена. Это не обязательный атрибут.

        Если что, на данный момент для веб-серверов, доступных более чем по одному FQDN, заполнение поля SAN является обязательным. И анализируется зачастую уже только SAN, а не сабжект. Проверьте сами.

        > Так что не вижу проблем с сертификатом

        Выписывающие его должны были или не вязать его к kernel.org, или добавить kernel.org в SAN. На данный момент сертификат сообщает ложную информацию и не является подтверждающим подлинность.

        > И все браузеры нормально все сообщают для хоста http://www.kernel.org

        Да, потому что это другой хост.

        > Да, что-то вы про фишинг пугаете. Уточните его определение.

        В данном случае — предложенный Вами редирект (когда после установки SSL-сессии с сайтом будет идти перенаправление на сайт с другим FQDN) — это как раз фишинговый ход, а не нормальная мера безопасности. Т.е. в сертификате написан сайт X, Вы на него начинаете заходить, а он Вас редиректит на сайт Y. Это как бы плохо сильно.

        1. Alexey Drozdov:

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

          Чтобы не разводить демогогию давайте подытожу свое видение:
          1. На данный момент известных успешных атак на RC4_128_SHA не описано.
          2. RC4_128_SHA не использует ни CBC (хотя есть варианты с ним) ни ECB, т.к. RC4 это потоковый алгорим (тут Вы постоянно всех вводите в заблуждение)
          3. Сервисы Гугла стали использовать по возможности TLS_ECDHE_RSA_WITH_RC4_128_SHA
          4. Браузеры Mizilla и Chromium (Chrome) в своих предпочтениях ставят методы *_RC4_* далеко не на первом месте.
          5. Нигде в статьях гугла не было упомянуто о сопердостижениях и о прорывах в безопасности — это придумали журналисты, а Вы эмоционально взъелись на это.

          В итоге получаем защита он атаки BEAST для упомянутых выше двух брайзеров (при дефолтных настройках) обеспечивается с сервисами гугла.

          Предлагаемые сервисы не являются средством не предполагают изначально обмена гос тайн и т.п. Поэтому упоминания требований FIPS тут не уместны. Но с учетом обозначенного выше п .1, это приемлемое _временное_ решение, не ухудшающее коренным образом безопасность.
          Если же пользователей не устраивает RC4, то он без проблем может его вообще запретить на своей стороне.

          Поэтому считаю, что вы неоправданно поднимаете панику, сами придумав ей причину или просто повелись на малую осведомленность журналистов.

          И что касается пресловутого ядра и фишинга:

          >> И все браузеры нормально все сообщают для хоста http://www.kernel.org
          >Да, потому что это другой хост.

          Другой хост относительно чего?
          почему вы считаете, что kernelo.org — это основной хост?
          Ходите именно по http://www.kernel.org, а нет по каким-то «левым».

          >> Да, что-то вы про фишинг пугаете. Уточните его определение.

          >В данном случае – предложенный Вами редирект (когда после установки SSL-сессии с сайтом будет идти перенаправление на сайт с другим FQDN) – это как раз фишинговый ход, а не нормальная мера безопасности. Т.е. в сертификате написан сайт X, Вы на него начинаете заходить, а он Вас редиректит на сайт Y. Это как бы плохо сильно.

          При любом редиректе на ssl-ресурс создается отдельное соединение, далее идет полная проверка сертификата так, что к фишингу данное описание не имеет никакого отношения.

          Тут, конечно, не столь уместно будет упоминание снова гугла, но попробуйте пройти по https://gmail.com
          После чего скажи-те, это фишинг?

          1. > Похоже, что мы разговариваем на разных языках и далеко ушли от основного вопроса.

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

            Чтобы действительно завязать с демАгогией, подытожим.

            1. На данный момент алгоритм RC4 — даже в своей «топовой» реализации в 128 бит, доступной на большинстве ОС, является устаревшим. Он никогда не использовался в серьёзных решениях по безопасности, не являлся основным для VPN, IPSec и SSL-решений. В нём достаточное количество design problems, чтобы он все время был «дополнительным» даже во времена DES, а сейчас, когда практически везде реализован AES, полное отключение поддержки RC4 является best practice. На фоне этого включение гуглом cipher suite с данным протоколом в ноябре 2011 года является, безусловно, снижением уровня безопасности — вместо того, чтобы при нескольких поддерживаемых cipher suites дефолтным делать самый стойкий (например, на базе AES-256), делают наоборот — самый слабый как по алгоритму, так по битовой длине.

            2. RC4_128_SHA не может использовать CBC или ECB по простой причине — это комплект из шифра+хэш алгоритма. Это раз. Далее, любой потоковый шифр семейства RC в современных реализациях все равно является, по сути, блочным шифром с малым блоком. Чисто «поточным» он является by design, но в реализации в любой ОС ему просто нет смысла уметь шифровать, допустим, 7 или 11 бит. Он все равно работает блоками из n бит. И если уж проводить аналогии, то он как раз работает в ECB-режиме.

            Кстати, объясните смысл мистической фразы «RC4_128_SHA не использует ни CBC (хотя есть варианты с ним)». Так не использует или есть? И если есть — то как это выглядит? У RC4 есть в алгоритме сцепка отдельных блоков по выходу? Да ну? Вы алгоритм-то сам этот видели? Атаки Флурера или Кляйна? Работы Ада Шамира? Они все описывают проблемы на уровне дизайна протокола, который не менялся. Аналогичные проблемы в AES найдёте? 🙂

            3. Сервисы Гугла стали использовать по умолчанию достаточно слабый на текущий момент cipher suite. Так как использование других cs не запрещено на уровне согласования протокола, то защитой от атаки типа BEAST это не является. Если не понимаете, почему — почитайте описание атаки и вдумайтесь. Если Вас убеждают в обратном — Вам врут. Даже если врут «хорошие ребята из гугла» — это все равно врут.

            4. Браузеры «Mizilla» и Chromium (Chrome) могут ставить в своих предпочтениях что угодно — главное, что они не поддерживают TLS выше 1.0, хотя стандарту уже 5 лет как, и в продуктах Microsoft он поддерживается давно.

            5. В итоге получаем — защита он атаки BEAST данными мерами не достигается, а упомянутые выше два браузера в плане безопасности заметно проигрывают тому же IE9, притом проигрыш очень ощутимый — у одного TLS 1.2 изначально, у других — TLS 1.1 спешно доделывается.

            Вам надо адресно заняться азами криптографии, а не перепечатывать маркетинговые заявления гугла. От этой процедуры — перепечатывания — ну никак RC4 в AES не превратится, а TLS 1.0 — в 1.2.

            Теперь про сертификаты.

            Алексей, если сертификат имеет в перечне имён имена X, Y, Z, а привязан к сайту с именем ABCD, то это фейл. Надо или в сертификат имя добавить, или убрать https-привязку к тому FQDN, которого нет в сертификате. Не выдумывайте несуществующие заявления и не отвечайте на них. Никаких основных хостов нет — есть перечень имён в сертификате, если их больше 1. Если имён 5, а привязали на всякий случай к 7, то это design bug. Поэтому на https://kernel.org имеет место очень базовая ошибка конфигурирования веб-сервера, а у Вас — непонимание азов работы https. Всё это несложно и изучаемо при желании, поверьте.

            >>В данном случае – предложенный Вами редирект (когда после установки SSL-сессии с сайтом будет идти перенаправление на сайт с другим FQDN) – это как раз фишинговый ход, а не нормальная мера безопасности. Т.е. в сертификате написан сайт X, Вы на него начинаете заходить, а он Вас редиректит на сайт Y. Это как бы плохо сильно.

            > При любом редиректе на ssl-ресурс создается отдельное соединение, далее идет полная проверка сертификата так, что к фишингу данное описание не имеет никакого отношения.

            Какая неуклюжая подтасовка. То, что создаётся отдельное соединение никак не связано с тем, что при открытии сайта https://www.abcd.com вам предъявят сертификат на https://www.abcd.com, а все ответы пойдут с https://megapornotrojan.xxx . Поэтому Ваше предположение о том, что можно было бы типа сделать редирект показывает, что Вы отдалённо представляете себе, зачем вообще HTTPS нужен и что именно делает SSL. Он, если что, не только данные шифрует, но и подтверждает подлинность сервера. Очень простыми и тупыми методами — посимвольным сравнением FQDN, например. И когда клиенту в SSL-сессии с сайтом A начинают идти HTTP-данные с сайта B, это и есть небезопасное перенаправление, и называется такое без ведома клиента — фишинг.

            Пример с гуглом неудачен — там на каждый сайт выдано по сертификату, с правильным FQDN. А в случае с https://kernel.org и предлагаемым редиректом был бы 1 сертификат с 1 FQDN на 2 сайта с 2 разными FQDN. Разницу не замечаете?

            С чем же именно вызвано ослабление гуглом безопасности — я на 100% не знаю. Равно как и причину ощутимого технологического проигрыша гугла в плане технологий веб-безопасности (старые алгоритмы, годами не реализованые RFC). Думаю, что возможности и деньги у гугла есть. Значит, дело в другом.

          2. BEAST же требует активного мима, не понимаю как включение rc4 по дефолту пожет здесь помочь. Что мешает этому самому миму выбросить из client hello все, что ему не нравится?

            То есть rc4 действительно мог бы помочь, если бы все остальные сьюты были именно что запрещены.

  8. alexeydrozdov:

    Поразительно — такой вот длинный и «серьезный» комментарий на статью, которая абсолютно искажает первоисточник 🙂

    Вот оригинал новости
    http://www.imperialviolet.org/2011/11/22/forwardsecret.html

    Суть ситуации в том, что сервера гугла стали поддерживать дополнительные алгоритмы. Сами по себе эти алгоритмы не столь примечательны — их использование для SSL/TLS описано официально 5 лет назад в http://www.ietf.org/rfc/rfc4492.txt.

    Но они по своей сути весьма ресурсоемки и для популярных сервисов их применение до некоторой поры было весьма накладным решением.

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

    Ни одного слова про какие-то там прорывы в защите (которые так эмоционально обсуждаются в данном посте) нет.

    Что касается более новых версий TLS, то согласно данным http://blog.ivanristic.com/2011/09/ssl-survey-protocol-support.html
    Очень небольшой процент сервисов его использеует т.е., тут должно быть двустроннее стремление для использования бонусов 🙂

    Например, сервера microsoft.com не поддерживают ECDH_* и даже TLS 1.2 выключена на них 🙂 Так что если говорить — говорите на чистоту 🙂

    Про RC4 представлен все в таком свете, что типа альтернатив и не предлагается, хотя на самом деле поддерживается и AES и 3DES — что использовать на совести клиенского приложения.

    До и упоминание древности RC4 вообще выгляди в стиле «отсюда очевидно следует».
    Устойчивость данного алгоритма до сих пор вполне адекватна.
    А вот защита самого сессионного ключа в свете постоянных компрометаций приватных ключей выглядит более здравым делом,

    Короче к чему это я статья исходная гавно и комменты к ней вводят всех в заблуждение 🙂

    1. Отлично, что ссылку исходную дали, я её искал как раз — к сожалению, в оригинальной новости не было оной.

      Речь-то не про то, что все, кто не использует только AES256 с P521 — тупые, а про подачу материала и безумный вывод «гугол внедряет RC4, это значит, что IE плохой». Написали бы, что помимо RSA добавили EC* — было бы как-то чуть проще, чем про «прямую передовую секретность PFS».

      Что касается новых версий TLS, то процент их использования никак не связан с простым фактом — что поддержка современных TLS 1.1/1.2, которым несколько лет, в том же IIS 7.5 и IE9 есть из коробки, а в СПО до сих пор нет. Это если начистоту. Есть большая разница между «есть, но при включении расходует больше ресурсов, поэтому не все включают» и «разработан несколько лет назад, до сих пор не сделали, хотя в текущем есть известная дыра — это мы так заботимся о безопасности». Понятно, что ресурс, который заточен под перекачку файлов, не особо поспешит на TLS 1.2 с AES-256 — ему для галки «мы безопасные» будет достаточно и SSL 3.0 с минимальным RSA-1024 + RC2/4/DES. Но вот если ресурс хочет, допустим, безопасно проводить важные транзакции — почему бы и нет. В случае с Microsoft, ему такую возможность дают — и со стороны клиентского ПО, и со стороны серверного. В случае Google — нет. Поэтому то, что с сайта Microsoft нельзя скачать evaluation-копию Windows 7 по TLS 1.2 — это не так плохо, как то, что в конце 2011 года Google защищает почту и деловые данные клиентов посредством RC4. Понятно, что сайт Microsoft (равно как и сайты Facebook и Twitter), как высоконагруженые, совсем не заинтересованы в том, чтобы вместо шустрого RC4 юзать 3DES. Но! Они не выпускают пресс-релизы, что это «вовсе не экономия, а забота о защите». Понимаете разницу — как в оригинале новости, так и в её подаче?

      А ситуацию с PKI в СПО проще всего увидеть, попытавшись открыть https://kernel.org — будет исчерпывающе видно.

      Про то, что в оригинальной новости написали, что алгоритмы «хорошо оптимизировали», можно подумать отдельно. Я бы ставил на то, что гугл запилил достаточно предсказуемую генерацию ключей, в EC это вполне возможно — если Вы сталкивались с той же «Вербой» и её потомством, Вы должны представлять, про что я намекаю. 🙂

      1. alexeydrozdov:

        Что-то отошли от темы 🙂
        Статья на *лабе как я уже и сказал плохая. Ее смысла обсуждать вообще нет.

        Телодвижения же гугла наоборот можно понять — таким образом они закрыли для большинства случаев «проблему» BEAST. При этом для пользователей все прошло прозрачно — это есть самое важное.
        Что здесь плохого?

        Да, кстати, про какой пресс-релиз идет речь? Источник — блог одного из разработчиков. Это бредо-СМИ все представляют в ином свете.

        Более того не могу понять претензии к гуглу — что у них на низком уровне безопасности? Что такого они не могут обеспечить?
        Повторюсь, RC4 128 адекватно надежен на данный момент. Или речь про TLS 1.1+?

        Да, я вовсе не защищаю гугловцев — мне их политика во многом не нравится, но более мне не нравятся неоправданные претензии 🙂

        Кстати, по поводу приведенного примера в СПО — чем не устраивает https://www.kernel.org/. Сертификат-то нормальный.
        Или я что-то не понял сути претензии 🙂 То, что не запрещен kernel.org или нет редиректа на http://www.kernel.org?

        1. Как же они её закрыли? Чтобы её закрыть, надо отключить всё остальное, кроме RC4 — и AES, и DES. А они добавили поддержку ECDHE_RSA, а схема обмена ключами как бы вообще к Beast никаким боком. Beast — это проблема выбора CBC перед ECB, эллиптическими кривыми vs обычный RSA на него не повлиять. Поэтому это точно не по части Beast. Вот про Beast:

          http://kb.atraining.ru/beast-move-from-ssl-to-tls/

          Претензии к гуглу по части этой статьи просты — вместо использования действительно более стойких схем (TLS старших версий, к примеру), меняется дефолтный симметричный шифр на RC4. Сейчас 2011 год. В чём профит-то такого движения сейчас?

          > Сертификат-то нормальный.

          Да нет, сертификат-то как раз не нормальный. Он выписан криво для данного использования. А «редиректов» в сертификатах вообще не бывает. :). А если они — редиректы — есть на веб-сайте, на котором https, то это ещё хуже, чем то, что имеется в данном примере. 🙂

          1. alexeydrozdov:

            Они сделали ECDHE_RSA_RC4 по дефолту. Браузеры Firefox и Chrome будут его использовать.
            Учитывая вопросы обратной совместимости (это самое ключевое!) более коренные изменения сделать пока у них не получится.

            Если они прямо сейчас бы включили TLS 1.1+ и сказали , что все зашибись, то большинство пользователей увы, были бы введены в заблуждение, ибо их браузеры не готовы к этому 🙂

            Т.е. _на данный момент_ это адекватный шаг, при этом же надо понимать, что это временное решение, так как было рекомендовано отключать пересогласование на серверах после освещения атаки на него в 2009.

            Что именно в нем кривого? что он чисто wildcard?
            Вот можно даже для наглядности:
            https://www.ssllabs.com/ssldb/analyze.html?d=www.kernel.org

            Я про редирект на сервере имел в виду — сами по себе они никакой опасности не несут.

  9. Вообще, невероятно, как очередной набор кнопочек к хтмл-движу «вебкит» стал чуть ли не главным ит-событием года. Ага.

    Они ещё пеарят в 2011 году «самый быстрый браузер» (как будто в 2011 году кто-то вообще помнит, что у браузера есть «скорость» — у всех всё давно открывается просто мгновенно, в любом браузере).

    1. Главное в «скорости» браузера — это реалистичный сценарий. «Допустим, у вас Celeron 433A с 16 гигабайтами оперативки и видеокартой TsengLabs 4000, вот тогда при 170 вкладках…». Ещё, конечно, необходим Правильный Тест — который ставит штукам вида «117й способ сжатия аудио» сразу баллов 50, потому что их нет в IE, а всяким глупостям типа «поддержка TLS 1.1 и 1.2» — или 1 или вообще нуль баллов, т.к. «раз нет в СПО, значит нинужно». Это сразу подчёркивает серьёзность исследователей — не рюшечки им какие-то нужны, всё серьёзно!

      1. Да основная шутка, в общем-то, в том, что нормальному человеку насрать на скорость браузера, потому что он через него странички смотрит, а не приобщается к богу Питуху.

        1. 123456qwertyu:

          Не соглашусь. Когда на слабой машине ждёшь открытия новой вкладки (=запуска нового процесса) IE или Chrome дольше секунды, это раздражает. Так что на рабочей машине (Atom со слабым винтом) лично я предпочитаю Opera.

          Впрочем, Chrome, как и прочие гугловысеры, я в принципе не использую и другим не советую. Не нравится Opera, религия не даёт использовать IE — ставь FF.

          1. С IE был фейл гораздо, гораздо эпичнее, чем медленное открытие вкладок. На IE9 нельзя было на сайте Microsoft нажать кнопку «Оплатить» в тренерском разделе. Т.е. тренер Microsoft — MCT который — раз в год платит некую сумму (37.5$ обычно). Вот форму заполнить можно было, а кнопка нажималась только под хромом или FF. Было в апреле, интересно, поправят ли к этому.

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