image

В начале года я рекомендовал обновить SSL/TLS сертификаты, имеющие подпись с алгоритмом SHA-1. Теперь это стало не просто рекомендацией, а предупреждением.

Недавние новости показали — оценка того, что получение коллизии для SHA-1 будет вполне доступно для криминального мира уже к 2018 году, оказалась оптимистичной. Марк Стивенс, Пьер Карпмэн и Томас Пейрин (надеюсь они простят меня за такой перевод их имен) опубликовали статью и пресс-релиз, в которых призывают как можно скорее отказаться от SHA-1. Они показывают, что создание поддельной подписи, основанной на SHA-1 сейчас может стоить около 100$ тыс., что вполне по карману преступному миру, а не 700$ тыс., как рассчитывал на 2015 год известный криптограф Брюс Шнайер.

Оценка стоимости производится на основании прайса Amazon EC2 на графические ядра, ведь именно они наиболее эффективно справляются с задачей подсчета хэша.

Важно отметить, что исследователям удалось получить коллизию в функции внутренней компрессии алгоритма хэширования, так называемая freestart коллизия, когда вектор инициализации может выбираться произвольно. Поэтому, если быть корректным, то полученный результат — не коллизия в SHA-1. Вычисления заняли 10 дней и потребовали непрерывной работы 64 графических ядер. По расценкам Amazon EC2 это примерно 2000$. По расчетам экспертов, полная атака на SHA-1 потребует от 49 до 78 дней работы кластера из 512 графических ядер, что, несомненно, гораздо дороже и дольше, однако срок уже вполне разумный и в некоторых случаях такая атака может достичь целей, преследуемых злоумышленниками.

С учетом того, что эксперты продемонстрировали метод, который напрямую не ведет к получению коллизии SHA-1 в произвольном случае, криптограф Брюс Шнайер заявил:
Не паникуйте, а готовьтесь к будущей панике.

Шаг за производителями операционных систем и браузеров. Они будут вынуждены пересмотреть свои планы на отказ от работы с сертификатами с SHA-1 и скорее помечать все такие сертификаты как небезопасные, поскольку отсчет идет уже не на года, а, возможно, на месяцы.

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

Комментарии (42)


  1. TrueBers
    09.10.2015 03:22
    +1

    Хром давно уже, вроде, предупреждает об этом и грозится в будущих версиях вообще выбросить поддержку подписи SHA1.


    1. JIghtuse
      09.10.2015 06:20
      +3

    1. nmk2002
      09.10.2015 10:49

      Вы вот это почитайте. Там спецы из Symantec, Entrust, Microsoft, Trend Micro предлагают отодвинуть дэдлайн до которого еще будут выпускаться сертификаты с SHA-1.


      1. lexore
        09.10.2015 13:32
        +13

        a very small number of very large enterprise customers have disclosed to us that they simply cannot complete this work before the issuance deadline.
        Классика.
        Вылет самолета задерживается, т.к. один из клиентов бизнес класса застрял в duty free.


  1. ReklatsMasters
    09.10.2015 07:52
    +4

    > появится услуга поиска коллизий SHA1
    идея для стартапа!


  1. Scratch
    09.10.2015 08:18
    +28

    Коллизия для SHA-1 за 10 дней


    Поэтому, если быть корректным, то полученный результат — не коллизия в SHA-1.


    Вот как с такими людьми быть, а?


    1. nmk2002
      09.10.2015 10:39
      +2

      Исправил на: Коллизия для SHA-1 за 100$ тыс.

      Так более корректно?


      1. owniumo
        12.10.2015 06:24

        "$100 тыс."

        «100 $ тыс.» пробел обязателен
        «100 тыс. $» тоже криво


  1. Akr0n
    09.10.2015 08:35
    +1

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


  1. eyeofhell
    09.10.2015 09:29

    Это печалька. Навскидку, sha-1 используется в git, websocket, майкрософтовских сертификатах формата x.509 :( Или уже нет?


    1. Aclz
      09.10.2015 10:35

      В W2008R2 для CA генерит SHA-256, в стандартных шаблонах «Web Server» и подобн. SHA-1.


    1. JIghtuse
      09.10.2015 10:46
      +5

      Git использует SHA-1 не для безопасности, а для проверки целостности.

      wiki
      Revision control systems such as Git and Mercurial use SHA-1 not for security but for ensuring that the data has not changed due to accidental corruption. Linus Torvalds has said about Git:

      «If you have disk corruption, if you have DRAM corruption, if you have any kind of problems at all, Git will notice them. It's not a question of if, it's a guarantee. You can have people who try to be malicious. They won't succeed.
      [...]
      Nobody has been able to break SHA-1, but the point is the SHA-1, as far as Git is concerned, isn't even a security feature. It's purely a consistency check. The security parts are elsewhere, so a lot of people assume that since Git uses SHA-1 and SHA-1 is used for cryptographically secure stuff, they think that, OK, it's a huge security feature. It has nothing at all to do with security, it's just the best hash you can get.
      [...]
      I guarantee you, if you put your data in Git, you can trust the fact that five years later, after it was converted from your hard disk to DVD to whatever new technology and you copied it along, five years later you can verify that the data you get back out is the exact same data you put in.
      [...]
      One of the reasons I care is for the kernel, we had a break in on one of the BitKeeper sites where people tried to corrupt the kernel source code repositories.»

      Nonetheless, without the second preimage resistance of SHA-1, signed commits and tags would no longer secure the state of the repository as they only sign the root of a Merkle tree.

      en.wikipedia.org/wiki/SHA-1#Data_integrity


      1. nmk2002
        09.10.2015 11:08
        +2

        (Если SHA-1 используется для проверки целостности данных) = (скоро будет возможна, или уже возможна, подмена данных с получением того же хэша)


        1. Greendq
          09.10.2015 12:33
          +5

          Да, но при этом очень маловероятно, что эти данные будут являться корректным текстом. Почему-то все об этом забывают. А компилятор на мусор в исходниках будет вопить сразу :)


          1. nmk2002
            09.10.2015 12:35
            +1

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


            1. Greendq
              09.10.2015 12:44

              Можно, но я оооочень сомневаюсь, что там будут строго текстовые символы :)

              Думаю, как только появится пруф — то быстро сменят на sha256, например :)


              1. Alexeyslav
                09.10.2015 14:29
                +1

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


                1. Greendq
                  09.10.2015 15:09
                  -1

                  Может, им места жалко. Длиннее хеш — больше места требуется, считать сложнее.


            1. akirsanov
              09.10.2015 18:42

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


              1. nmk2002
                09.10.2015 19:02

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


        1. DaylightIsBurning
          09.10.2015 12:54
          +3

          но зачем? Вы вики читали?

          ensuring that the data has not changed due to accidental corruption


        1. batyrmastyr
          09.10.2015 15:41

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


      1. stepik777
        10.10.2015 00:55

        Линус сам себе противоречит, сначала говорит, что это не security feature, а потом, что хэш защищает от целенаправленных атак:

        You can have people who try to be malicious. They won't succeed.
        [...]
        One of the reasons I care is for the kernel, we had a break in on one of the BitKeeper sites where people tried to corrupt the kernel source code repositories.


  1. miriarder
    09.10.2015 12:07
    -8

    А ведь все в курсе, что SHA-1 используется в качестве единственного алгоритма хэширования для Windows 7? Windows 8+ Понимает уже Sha-256. Таким образом, проверять целостность драйверов, основываясь на целостности подписи будет нельзя.
    Учитывая, что валидная цифровая подпись разаработчика драйвера на черном рынке стоит порядка 20к$ волноваться пока рано, но…


    1. Scratch
      09.10.2015 12:19
      +5

      Вот это новости!
      Sha256 поддерживается в сертификатах, начиная с XP SP3+


  1. david_mz
    09.10.2015 14:31
    +5

    Открытка Яндекс.Деньгам, которые до сих пор на SHA-1.


  1. batyrmastyr
    09.10.2015 15:14

    Так, а что делать счастливым пользователям StartSSL у которых корневой сертификат — SHA-1, а промежуточные — SHA-2?


    1. nmk2002
      09.10.2015 15:15
      +1

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


      1. batyrmastyr
        09.10.2015 15:21

        Они-то не проверяются, но нет ли риска, что кто-то создаст промежуточный сертификат и сертификат сайта якобы от StartSSL и, взломав сайт, подставит их вместо настоящих? Ну а там почти идеальный MiTM, если владельцы сайта заранее «гвоздями не прибили».


        1. nmk2002
          09.10.2015 15:25
          +1

          Промежуточный сертификат будет подписан SHA-2.
          Если ваш браузер «увидит» в цепочке корневой сертификат, отличный от того, что хранится в доверенных корневых (или не подписанный другим доверенным корневым), то выдаст предупреждение.
          Еще раз: браузер не будет проверять подпись корневого УЦ, а просто проверит, есть ли он в списке доверенных.


          1. batyrmastyr
            09.10.2015 15:33

            Видимо я чего-то упорно недопонимаю, но кто мешает злоумышленнику создать промежуточный сертификат SHA-2 который якобы подписан тем самым корневым SHA-1? Браузер и система увидят отпечаток доверенного корневого и пропустят подделку. Как я это вижу.


            1. nmk2002
              09.10.2015 15:45
              +1

              Возможно, я не понимаю вас. Поправьте, если не прав:
              — Вы создаете свой корневой УЦ, который имеет такую же подпись, как и один из доверенных (SHA-1).
              — Вы подписываете этим корневым УЦ сертификат (SHA-2).

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


              1. batyrmastyr
                09.10.2015 15:52

                Да, последовательность именно такая. Теперь понял, что зря нервничаю )


    1. mrgall
      09.10.2015 22:27

      У них есть корневой сертификат с SHA-2: www.startssl.com/certs


      1. grossws
        09.10.2015 23:40

        Есть ли он в основных ОС, mozilla ca-certificates, jre? Если нет — то он пока нафиг никому не сдался. А intermediate ca с sha-2 уже есть у большинства нормальных ca.


        1. mrgall
          09.10.2015 23:50
          +1

          Mozilla добавила его в 2012 году: bugzilla.mozilla.org/show_bug.cgi?id=602750
          У Qualys SSL Test к нему нет замечаний.


          1. grossws
            10.10.2015 00:01

            Спасибо за информацию. Проверил, у меня он есть в списке.

            Удивился, т. к. rehashing был в 2010, а class 1 они подписывали старой цепочкой (от старого root ca с sha-1). Как сейчас — не знаю.


        1. navion
          11.10.2015 15:15

          А в JRE они вообще есть?


          1. grossws
            11.10.2015 16:53

            В oracle jdk 8 не нашел. Кажется, раньше мы добавляли их root ca отдельно, но запамятовал, т. к. сейчас используем comodo, который есть из коробки. А наличие в openjdk зависит от политики дистрибутива, кто-то генерирует на основе mozilla ca-certificates, кто-то берёт cacerts по умолчанию.


            1. navion
              11.10.2015 17:18

              По-моему их там никогда не было, вот и удивился.


      1. batyrmastyr
        09.10.2015 23:56

        Любопытно. Ждут нормального распространения этого сертификата по системам или просто забыли создать свежие промежуточные сертификаты?


        1. mrgall
          10.10.2015 00:09

          У них вроде все есть и работает. Чего они ждут мне неизвестно.
          Результат с Qualys SSL Test: habrastorage.org/files/78e/f3b/09e/78ef3b09e1774d0daf030569326894c7.png