Гуглоправда

Пропагандисты гугла продолжают патологически врать:

http://habrahabr.ru/blogs/infosecurity/133430/

Для того, чтобы браузер поддерживал новый тип шифрования, он должен поддерживать стандарт RC4, а IE с RC4 работать не «умеет». Возможно, говорят в Google, поддержка этой технологии будет включена в браузер IE позже.

Пример статьи про то, как NT 4.0 и IE4 ещё в 1997 году с RC4 работать «не умеют»

Тема подробно разобрана ранее в этом же блоге и выяснено, что это «нововведение» лишь ослабляет защиту данных клиентов и никак не меняет ситуацию с атаками на SSL/TLS. В Google Chrome до сих пор не реализованы стандартные меры безопасности, описанные в RFC от апреля 2006 года, которые есть и работают в том же IE9.

На данный момент Google Chrome — один из самых небезопасных браузеров, полностью проигрывающий по криптографической безопасности Internet Explorer’у предыдущуй версии. Сервисы Google — такие как Google+, Gmail, Google Docs и Google Apps являются непригодными для хранения и обработки сколь-нибудь серьёзных данных даже по критериям, под которые подпадал Windows 2000 (ОС 12ти летней давности). Но воровать данные надо, поэтому гугл занимается абсолютно тупой пропагандой, рассчитанной на слепо верующих, потому что все остальные могут за пару минут убедиться в полной несостоятельности данных «мер защиты». А хабрахомячки-гуманитарии с их характерным уровнем грамотности в IT — помогают по мере сил. Вы почитайте просто этот фестиваль слабоумия:

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

Вот так прорыв! Только гугл так может, только в декабре 2011 года.

Один ключ зависим от другого, при этом, насколько можно понять, место хранения ключей постоянно изменяется.

Автор зависим от наркотиков, не иначе. И место инъекции у него постоянно изменяется. Всё чаще, судя по всему, страдает мозг.

Стоит отметить, что шифрование не работает для Internet Explorer, но работает для Mozilla Firefox и для Google Chrome.

Сейчас разработчики сделали HTTPS еще более безопасным, сделав так, чтобы для шифрования данных использовалось два ключа.

Петросян читает статью на хабре

Ребята, ну завязывайте уже с наркотой, реально, это ж до добра не доведёт.

Реклама
Гуглоправда

Гуглоправда: 18 комментариев

  1. dumalka :

    Приходит как-то Вовочка домой, смотрит а на столе записка: «Вовочка! У тебя завтра экзамен по биологии. Подготовься как следует. Мама.»
    Посмотрел Вовочка на билеты, которых было штук эдак тридцать, и понял что все ему все равно не выучить. Решил он выучить только про блохи билет.
    На следующий день приходит Вовочка на экзамен. Тянет билет. В нем написано: «Собака». Начинает Вовочка отвечать:
    — Ну, собака это домашнее животное. У него есть голова, ноги четыре штуки, хвост, шерсть. А в шерсти есть блохи. А блохи…
    Сидит учитель
    cлушает и понять не может то ли знает Вовочка материал, то ли нет.
    Потом говорит:- Давай Вовочка потяни еще один билет. Тянет Вовочка второй билет. А в нем написано: «Кот».
    — Ну, кот это домашнее животное. А него, как и у собаки, есть голова, четыре ноги, два уха, хвост, шерсть. А в шерсти тоже есть блохи. А блохи это…
    Сидит учитель, смотрит на Вовочку и понять не может вроде и материал он знает, а вроде и не знает.
    — Давай, Вовочка, тяни последний билет. Если ответишь, поставлю тебе 5.
    Тянет Вовочка билет, а там написано: «Рыба». Подумал Вовочка немного и начал отвечать.
    — Рыба это рыба. Она живет в воде. У нее есть голова, глаза, хвост, плавники, чешуя. А была бы у нее шерсть – в шерсти были бы блохи. А
    блохи…

    Кого-то мне Вовочка напоминает.

    Вы знаете, Вы тут далеко не первый малограмотный фанатик, который, чувствуя глубокое оскорбление в душе и острое покалывание пониже, пишет что-то вида «Да я бы ух бы написал бы да бы ваще бы». Ключевой общий признак фанатиков СПО и майкрософтхейтеров — глубокая интеллектуальная импотенция, неспособность логически мыслить и изучать новое. Это целевая аудитория новодворских и фроловых с ключевым «дети не должны учиться, они должны служить линуксу и ненавидеть того, кого мы прикажем».

    Главное — не сдавайтесь. IE — плохо. Google — хорошо. Любой ценой. На Ваш счёт только что переведено ещё 3 доллара в рамках программы FSF «Поддержим пропаганду СПО в странах третьего мира, чтобы у них не было своего IT».

  2. dumalka :

    Данная криптография позволяет как минимум проводить аутенфификацию взаимодействующих субъектов. И как следсвие позволяет как минимум защитить формирование сессионных ключей, которые могут согласовываться не только посредством DH.
    ПОсредством упомянутого RSA ключи также могут быть согласовыны без применения DH, что кстати говоря, в SSL и имеет быть таковым.
    Это и есть общее.
    Естественно, есть много тонкостей, но речь сейчас не о них.

    >Вы не понимаете разницу между DH и RSA? Это уныло, совсем притом.

    как это соотносится с написанным выше? Где причинно-следственная выкладка, кроме «отсюда очевидно следует»?

    >Вы опять пытаетесь подменить понятия. Вначале утверждаете, что они _технически_ оба одинаковы (“есть транспорт”)

    Маэстро, вы в своем уме, уважаемый?
    Если самолет и автомобиль я назову транспортом, но это никаки не говорит о том, что я заявляю об их технической идентичности.
    Но в то же время оба транспорта как минимум выполняют функцию для надежной передачи.
    ipsec и ssl как минимум имеют общее в том, что позволяют аутентифицировать, контролировать целостность и безопасность передачи данных. И это одни из целей их создания.

    В остальном, естественно, имеют разницу как самолет и автомобиль.

    >Кстати, а по какому определению “легче стырить” пользовательскую информацию в SSL без PFS, чем с оным?

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

    > Данная криптография позволяет как минимум проводить аутенфификацию взаимодействующих субъектов.
    И как следсвие позволяет как минимум защитить формирование сессионных ключей.

    Это RSA-то защищает формирование ключей? Т.е. что, сам DH формирует ключи небезопасно? Скажите, а как же тогда работает например TLS_DH_анон_с_DES_CBC_SHA? Там что, небезопасно формируются сессионные ключи, в отличии от варианта с RSA?

    > ПОсредством упомянутого RSA ключи также могут быть согласовыны без применения DH, что кстати говоря, в SSL и имеет быть таковым.

    В SSL ключи согласовываются без DH? Вы наркозависимый?

    > ipsec и ssl как минимум имеют общее в том, что позволяют аутентифицировать, контролировать целостность и безопасность передачи данных. И это одни из целей их создания

    Какая неуклюжая очередная попытка уйти от изначального утверждения. Вы стартово пытались объяснить, что мол раз PFS нужен в одной технологии защиты данных, то априори нужен и в другой. Доказать не удалось, сейчас уходите на нейтральное «ну они же оба примерно одно и то же делают». Неудачно, совсем. Утверждения разные.

    > В рамках одной сессии, естественно, задача «стырить» не облегчается.

    Ах вот оно что, оказывается. :)))). Слушайте, а где прорыв в безопасности-то, который состоял в том, что гугл сделал дефолтным ECDHE_RC4 — при том, что ещё в XP был ECDHE_AES, плюс оставив в хроме только уязвимые протоколы TLS 1.0 и SSL 3.0? Ну, речь-то шла вроде как о плюсах для пользователей. В чём они в итоге-то? :))

    1. dumalka:

      >> ПОсредством упомянутого RSA ключи также могут быть согласовыны без применения DH, что кстати говоря, в SSL и имеет быть таковым.
      >В SSL ключи согласовываются без DH? Вы наркозависимый?

      Интересен ваш подход в методах дискуссии.
      Но на это уже можно и не обращаить внимания 🙂

      Повторяю — в SSL согласование ключей в самых распространенных на данный момент связках алгоритмов
      — тех, которые *_RSA_* без DH-, например, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA и т.д.
      (остальное можете продолжить сами)
      осуществляется ТОЛЬКО посредством криптографии с открытым ключем RSA.

      Как доказательство см.:

      В RFC
      7.4.7.1. RSA-Encrypted Premaster Secret Message

      Meaning of this message:

      If RSA is being used for key agreement and authentication, the
      client generates a 48-byte premaster secret, encrypts it using the
      public key from the server’s certificate, and sends the result in
      an encrypted premaster secret message. This structure is a
      variant of the ClientKeyExchange message and is not a message in
      itself.

      и вот да любой вкус для энифобов,
      https://developer.mozilla.org/en/Introduction_to_SSL#The_SSL_Handshake
      http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_1-1/ssl.html
      http://help.globalscape.com/help/secureserver3/FIPS_140-2_Certification.htm
      http://docs.redhat.com/docs/en-US/Red_Hat_Certificate_System/8.0/html/Deployment_Guide/SSL-TLS_ecc-and-rsa.html
      http://technet.microsoft.com/en-us/library/cc785811(WS.10).aspx

      И уж где где, так даже в википедии по этому поводу правда написана 🙂

      И еще раз для слишком принципных — без DH можно успешно согласовывать ключи с использовании RSA и других алгоритмов криптографии с открытым ключем, что и делается на практике!

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

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

        DH — это когда две стороны «с нуля» генерят ключ. Не передают от одной к другой, а совместно создают новый. Вы путаете это с RSA, притом даже не читаете, что копипастите:

        the client generates a 48-byte premaster secret, encrypts it using the public key from the server’s certificate, and sends the result in an encrypted premaster secret message.

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

        1. dumalka:

          Я ни разу не упомянул термин «генерация».

          «ПОсредством упомянутого RSA ключи также могут быть согласовыны». Согласованы, это значит не _сгенерированы_, а именно _согласованы_!

          И что, теперь любую ссылку вы будите сводить к понятию «гугление»?
          Я в отличии от некоторых привел доказательства, а вы только голословие.
          Если, есть что опровергнуть, прошу в виде мат выкладок (матчасть же вам близка) с вашей стороны или пруф-линков.

          И вот теперь к Вам вопрос:
          В SSL _согласование_ ключей на основе каких алгоритмов осуществляется?
          По вашему без DH никуда?

          А то пиздеть — не мешки ворочать.

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

            Можно фиксировать — на данный момент хром — один из самых небезопасных браузеров. Полностью проигрывает IE по всем параметрам, связанным с криптографией — поддержка TLS, выбор cipher suites. Применение его опасно, т.к. у него, например, нет ни одного протокола SSL/TLS, в которых не было бы уязвимостей. До сих пор не реализованы стандарты от 2006 года. В плане шифрования данных пользователя гугл осознанно ослабляет настройки. Всё это подробно расписано и доказано.

            Но, понятное дело, далёкие от криптографии фанатики бренда «гоогле», которым наплевать на безопасность (в ней они особо не разбираются), пиарят оный, правда, с предсказуемыми фейлами, но тут не привыкать. И Ваше:

            «А нука научи меня чё такое вся ента криптография а то ни паверю»

            тут выглядит вполне логично и к месту. Chrome полностью проиграл IE в плане безопасности — почему бы не поучиться, действительно? 🙂

          2. dumalka:

            Приходит как-то Вовочка домой, смотрит а на столе записка: «Вовочка! У тебя завтра экзамен по биологии. Подготовься как следует. Мама.»
            Посмотрел Вовочка на билеты, которых было штук эдак тридцать, и понял что все ему все равно не выучить. Решил он выучить только про блохи билет.
            На следующий день приходит Вовочка на экзамен. Тянет билет. В нем написано: «Собака». Начинает Вовочка отвечать:
            — Ну, собака это домашнее животное. У него есть голова, ноги четыре штуки, хвост, шерсть. А в шерсти есть блохи. А блохи…
            Сидит учитель
            cлушает и понять не может то ли знает Вовочка материал, то ли нет.
            Потом говорит:- Давай Вовочка потяни еще один билет. Тянет Вовочка второй билет. А в нем написано: «Кот».
            — Ну, кот это домашнее животное. А него, как и у собаки, есть голова, четыре ноги, два уха, хвост, шерсть. А в шерсти тоже есть блохи. А блохи это…
            Сидит учитель, смотрит на Вовочку и понять не может вроде и материал он знает, а вроде и не знает.
            — Давай, Вовочка, тяни последний билет. Если ответишь, поставлю тебе 5.
            Тянет Вовочка билет, а там написано: «Рыба». Подумал Вовочка немного и начал отвечать.
            — Рыба это рыба. Она живет в воде. У нее есть голова, глаза, хвост, плавники, чешуя. А была бы у нее шерсть — в шерсти были бы блохи. А
            блохи…

            Кого-то мне Вовочка напоминает.

  3. dumalka :

    Сможешь доказать свои слова?

    Я вот могу.
    Внимание (тут барабанная дробь….)
    Открываем http://www.ietf.org/rfc/rfc5246.txt
    Там лежит описание The Transport Layer Security (TLS) Protocol Version 1.2.
    И о ужас, слова PFS там не встречается. Казалось бы стоит снять шляпу перед маэстро. Но что-то подсказывает, что не стоит жонглировать аббревиатурами и поискать просто по наитию
    Perfect Forward Secrecy.

    И о ЧУДО
    «F.1.1.2. RSA Key Exchange and Authentication

    With RSA, key exchange and server authentication are combined. The
    public key is contained in the server’s certificate. Note that
    compromise of the server’s static RSA key results in a loss of
    confidentiality for all sessions protected under that static key.
    TLS users desiring Perfect Forward Secrecy should use DHE cipher
    suites. The damage done by exposure of a private key can be limited
    by changing one’s private key (and certificate) frequently.»

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

    Маэстро Ваш ход.

    Максимум, о чём сие может сказать — так разве что о Вашей неграмотности и попытке передёрнуть.

    Речь, если что, о том, что у гугла не реализован TLS старше 1.0, а Вы достаёте цитату из стандарта про TLS 1.2. Как наличие чего-то в нём влияет на безопасность того же хрома, который не поддерживает данный протокол? :). А IE — отлично поддерживает.

    Или, наверное, от этого поддерживаемые IE комплекты вида ECDHE+AES внезапно стали хуже назойливо навязываемого гуглом ECDHE+RC4? И эпический слив гугла вида «да, нам надо продолжать воровать данные, поэтому мы ослабили шифрование, но пропиарим, будто это прорыв» перестал быть таковым?

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

    Тут соглашусь — Вы действительно не понимаете, о чём повествуете. Характерный у Вас ход такой для не владеющих матчастью — быстро попытаться нагуглить, не понимая, увидеть несколько «примерно таких» аббревиатур и закопипастить. В результате лишь подчёркиваете, что с темой не знакомы.

    Криптография — это не «линуксбезопасность», когда можно «десять лет порты на файрволе открывать и закрывать, поэтому я эксперт в безопасности», это достаточно сложная штука, поэтому с ней надо внимательнее, паническим гуглением делу не помочь. Подумайте над этим.

    1. dumalka:

      Маэстро, Вы это о чем?
      Какой гугл, какой RC4, какие IE?

      Я упомянул только ipsec, ssl и PFS. Где Вам остальное мерещится?

      И ответил на ваше обвинение в мой адрес, что дескать «не сможете срывать покровы про известную, судя по RFC, только Вам актуальность PFS в TLS».

      В ответ привел обоснованную стандартом актутальность по первоисточнику. Это как доказательство того, что Вы окончательно запутались.

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

      Почитал соседние ветки — ржал!
      А если честно, то завидую Вам, что так уверенно можете пиздеть да на полном серьезе и в таких объемах, когда Вам же указывают на Ваши же ошибки.

      Короче, давай отвечать за свои слова.

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

        Про IPSec, кстати, Вы не упоминали — упоминал про него я, для аналогии.

        Вы же пытались утверждать, что:

        > Не вижу принципиального отличия необходимости применения PFS для ipsec и ssl. И там и там одинаково актуален.

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

        > Оба протокола – есть транспорт.

        С такой логикой можно сравнивать по защите SMB и Bluetooth, потому что оба они в принципе данные переносят. 🙂

        «Актуальность PFS» фразой «TLS users desiring Perfect Forward Secrecy should use DHE cipher suites» не показывается. Ей показывается (если читать именно что написано), что в случае, если для конкретного использования TLS 1.2 (т.е. уже не обсуждаемый случай совершенно, т.к. у гугла нет TLS 1.2) по не указанной причине нужен необязательный в общем случае PFS, то для его использования есть дополнительное требование к выбору cipher suite — наличие в оном DHE. Это никак не связано с тем простым и неприятным фактом, что гугл осознанно уменьшает безопасность, делая предпочтительным алгоритмом шифрования RC4. Т.е. тут Вы тоже мимо, притом сильно. Хоть бы прочитали без ошибок…

        Ваши попытки передёрнуть вида:

        — Прививка от свинки не помогает от кариеса
        — Аааа, так ты пытаешься отрицать то, что прививка от свинки полезна!

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

        Ну а дальнейшая Ваша паника вообще показательна:

        > Кроме пустословия, которое до сих пор не подтверждено никаким стандартом,

        Всё отлично подтверждено в стандарте TLS 1.1, который выпущен в апреле 2006 года и до сих пор не реализован в google chrome, что в явном виде снижает безопасность и показывает злой умысел вендора. В то, что у гугла нет денег и ресурсов написать реализацию TLS 1.1 и добавить её в браузер, я не верю, извините уж.

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

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

        > более ни чем жонглировать не можете.

        Это потому что я не жонглёр. Зато в криптографии неплохо разбираюсь, в отличии от Вас, к примеру.

        Не обижайтесь только, ОК, что я Вас так публично унизил? Вы должны понимать, что с Вашим уровнем знаний это нормально, да думаю, и привыкли уже. 😉

        1. dumalka:

          То, что по Вашему «SSL и IPSec изначально по разному позиционируются.» абсолютно не отменяет тот факт, что в отличии от ваших примеров с SMB и блютусом у них есть общая ключевая основа.
          Она заключается в том, что оба протокола используют криптографию с открытыми ключами для защиты формирования прямым или косвенным образом сессионные ключи. Последние и надо защищать от прохлопывания ушами приватных.
          PFS не более чем метод.
          И чем же скажите на милость информация, передавая по каналам с IPSec, о банковских реквизитах пользователя, важнее той, которую я буду передавать в свой банк через SSL?
          И то и другое без PFS по определению легче стырить, т.е. считаю, что защищать надо одинаково эффективно и то и другое.

          Т.е. пиздеж типа «Применение PFS в IPSec – да, там понятен профит. В SSL – … — не совсем понятно.» не доказательство, а частное мнение, типа «отсюда очевидно следует».

          И не примешивайте к моим высказываниям свое гуглофобское видение мира.

          1. > То, что по Вашему «SSL и IPSec изначально по разному позиционируются.» абсолютно не отменяет тот факт, что в отличии от ваших примеров с SMB и блютусом у них есть общая ключевая основа.

            Это не по-моему, а изначально. Их для разных задач делали. Поэтому технологии для их защиты — тоже разные. Какая, кстати, у SSL и IPSec общая основа, если не секрет?

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

            Ох пошли откровения. Это когда это у нас криптография с открытыми ключами использовалась для формирования сессионных ключей? Вроде как она — ну, RSA там всякий — используется для другой цели. Вы не понимаете разницу между DH и RSA? Или всё, что не с секретным ключом — то с открытым? Это уныло, совсем притом.

            > И чем же скажите на милость информация, передавая по каналам с IPSec, о банковских реквизитах пользователя, важнее той, которую я буду передавать в свой банк через SSL?

            Вы опять пытаетесь подменить понятия. Вначале утверждаете, что они _технически_ оба одинаковы («есть транспорт»), теперь, когда наглядно показана Ваша техническая неграмотность — рассуждаете с точки зрения контента. Это другое совсем. С точки зрения контента надо, чтобы его не могли прочитать. Для этого методов существует масса, из этого никак не следует, что технология X, нужная в одном случае, эффективна в другом.

            > И то и другое без PFS по определению легче стырить, т.е. считаю, что защищать надо одинаково эффективно и то и другое.

            Ключевое — Вы считаете. Судя по Вашим предыдущим постингам, ценность этого — околонулевая. Эту мысль разделяют авторы стандартов TLS, где PFS не применяется как штатное средство усиления защиты данных.

            Кстати, а по какому определению «легче стырить» пользовательскую информацию в SSL без PFS, чем с оным? Вы повторяете мантру гугла «мы приказываем вам считать, что ваши данные стали защищённее», а не думали изучить — что именно может улучшиться в плане защиты, когда PFS включат, и почему его включение не является обязательным в TLS?

            > И не примешивайте к моим высказываниям свое гуглофобское видение мира.

            Почему ж гуглофобское? Гугл откровенно проигрывает по безопасности своих сервисов, да ещё и умышленно снижает безопасность передачи данных в своих сервисах. Всё это подробно разобрано в данном и предыдущих постингах. Замена в декабре 2011 года AES-256 на RC4-128 является снижением уровня безопасности данных, это не гуглофобство, а констатация факта. На которое Вам возразить нечего, а хочется. А вот это уже напоминает гуглофилию, да. Молитвы на бренд и прочее. Почитайте про криптографию, это точно полезнее, чем с религиозным фанатизмом и минимумом знаний влезать в техническое обсуждение и мучаться.

          2. dumalka:

            >> Она заключается в том, что оба протокола используют криптографию с открытыми ключами для защиты формирования прямым или косвенным образом сессионные ключи.
            >Ох пошли откровения. Это когда это у нас криптография с открытыми ключами использовалась для сессионных ключей? Вроде как она – ну, RSA там всякий – используется для другой цели.

            Данная криптография позволяет как минимум проводить аутенфификацию взаимодействующих субъектов. И как следсвие позволяет как минимум защитить формирование сессионных ключей, которые могут согласовываться не только посредством DH.
            ПОсредством упомянутого RSA ключи также могут быть согласовыны без применения DH, что кстати говоря, в SSL и имеет быть таковым.
            Это и есть общее.
            Естественно, есть много тонкостей, но речь сейчас не о них.

            >Вы не понимаете разницу между DH и RSA? Это уныло, совсем притом.

            как это соотносится с написанным выше? Где причинно-следственная выкладка, кроме «отсюда очевидно следует»?

            >Вы опять пытаетесь подменить понятия. Вначале утверждаете, что они _технически_ оба одинаковы (“есть транспорт”)

            Маэстро, вы в своем уме, уважаемый?
            Если самолет и автомобиль я назову транспортом, но это никаки не говорит о том, что я заявляю об их технической идентичности.
            Но в то же время оба транспорта как минимум выполняют функцию для надежной передачи.
            ipsec и ssl как минимум имеют общее в том, что позволяют аутентифицировать, контролировать целостность и безопасность передачи данных. И это одни из целей их создания.

            В остальном, естественно, имеют разницу как самолет и автомобиль.

            >Кстати, а по какому определению “легче стырить” пользовательскую информацию в SSL без PFS, чем с оным?

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

  4. Опять учёный изнасиловал журналиста…

    «В настоящее время PFS считается опциональной фичей и редко используется в качестве опции HTTPS, и Google стал первой крупной компанией, которая внедрила его по умолчанию. Система perfect forward secrecy реализована во всех HTTPS-сервисах Google (это Gmail, Google+, Google Docs, SSL Search) и поддерживается браузерами Chrome и Firefox. К сожалению, браузер IE пока не поддерживает сочетание ECDHE и RC4.»

    http://habrahabr.ru/blogs/crypto/133268/

    1. Идёт вагон передёргиваний и вранья.

      IE не поддерживает связку достаточно нового ECDHE и очень старого RC4, потому что он поддерживает нормальные современные связки — ECDHE с AES. Технологии развиваются последовательно, поэтому когда-то были связки вида DES+RSA512, и нормально работало, а сейчас актуально другое. Делать экзотическую криптографическую связку и выдавать применение её, а не более стойкой и современной ECDHE+AES, как прорыв — обман клиента. Можно аналогично выдать сертификат SSL с 8192 битовым ключом и шифровать RC2-40bit, и сказать, что клиенты очень выиграли, потому что дураку понятно же, что 8192 бита — в два раза круче, чем 4096 (тихо замяв, что сами данные закрываются RC2). Речь как раз про это.

      Теперь про PFS.

      PFS является опциональным алгоритмом в TLS/SSL потому что прямой выгоды в плане безопасности он не несёт. Разработан он в 1998 году и с тех пор особо не менялся. Если хочешь — можешь открыть RFC по TLS 1.0-1.2 и убедиться, что там в плане PFS как-то очень тихо. Это не потому что там неосиляторы собрались и враги гугла, а потому что нет профита особого. Применение PFS в IPSec — да, там понятен профит. В SSL — он по идее будет «помогать» в такой ситуации — засниффили весь трафик, угадали все сессионные ключи и выкрали закрытый ключ сервера, к которому идёт подключение. Такое в случае какого-нибудь редхата вполне возможно (и было в 2008 году), но вот как это защитит данные пользователей почты google например — не совсем понятно.

      Поэтому и говорится, что гораздо более очевидным и 100% рабочим плюсом было бы явное отключение гуглом старых алгоритмов шифрования и повышение «нижней планки» в плане защиты, ну и внедрение TLS нормальных, новых версий. Пока же гугл пиздит реализации криптографии из openssl и отмазывается, притом неудачно.

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

      В копилку пиздежа гугла можно добавить, таким образом, новое заявление — подачу как kill-feature добавления в старый SSL старого PFS. Круто, да. IE так не может.

      1. dumalka:

        Не вижу принципиального отличия необходимости применения PFS для ipsec и ssl. И там и там одинаково актуален.
        Оба протокола — есть транспорт.
        В чем ты видишь ее?
        По поводу «угадали все сессионные ключи» пиздите. Их просто извлекут из трафика на основе закрытого ключа. От этого PFS и защищает.
        Дальше уже вообще какой-то голословный онанизм.

        1. Достаточно тривиальное заблуждение.

          SSL и IPSec изначально по разному позиционируются. Один защищает конкретные сессии, другой — сервисы. Т.е. SSL — это «пять вкладок в браузере на один URL открыто — три обычных, две SSL’ных». IPSec — это «правило, которое весь трафик на порт X протокола Y хоста Z защищает». Разное позиционирование, разные задачи. Криптография и то разная — у того же IPSec, допустим, можно хоть MD2, хоть MD4 хэш использовать, а в SSL такого нет, но зато в IPSec шифры только блочные, там RC2 не включишь, а в SSL поточные RC2/4 вполне поддерживаются. В общем, у них, у ipsec/ssl скорее, общего мало. Учите матчасть, это несложно. «Всё, что шифровано и в ентернете, есть транспорт, следовательно примерно одинаково, следовательно одинаковые методы защиты должны иметь одинаковый эффект» — это незнание азов и логика вида «раз оно примерно про шифрование, добавим в кучу, авось хуже не будет». Запросто может стать хуже.

          А с онанизмом завязывайте — от этого, говорят, волосы на руках растут. Печатать будет неудобно, не сможете срывать покровы про известную, судя по RFC, только Вам актуальность PFS в TLS.

          Гугл как раз на такую логику, которую Вы показываете, и рассчитывает, обманывая наивных и не разбирающихся в матчасти клиентов.

          1. dumalka:

            Сможешь доказать свои слова?

            Я вот могу.
            Внимание (тут барабанная дробь….)
            Открываем http://www.ietf.org/rfc/rfc5246.txt
            Там лежит описание The Transport Layer Security (TLS) Protocol Version 1.2.
            И о ужас, слова PFS там не встречается. Казалось бы стоит снять шляпу перед маэстро. Но что-то подсказывает, что не стоит жонглировать аббревиатурами и поискать просто по наитию
            Perfect Forward Secrecy.

            И о ЧУДО
            «F.1.1.2. RSA Key Exchange and Authentication

            With RSA, key exchange and server authentication are combined. The
            public key is contained in the server’s certificate. Note that
            compromise of the server’s static RSA key results in a loss of
            confidentiality for all sessions protected under that static key.
            TLS users desiring Perfect Forward Secrecy should use DHE cipher
            suites. The damage done by exposure of a private key can be limited
            by changing one’s private key (and certificate) frequently.»

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

            Маэстро Ваш ход.

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