The OpenNET Project / Index page

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

В OpenSSL выявлены уязвимости, позволяющие вклиниться в транзитный трафик и организовать выполнение кода

05.06.2014 17:54

Опубликованы корректирующие выпуски OpenSSL 1.0.1h, 1.0.0m и 0.9.8za, в которых устранена опасная уязвимость (CVE-2014-0224), позволяющая совершить MITM-атаку, которая может привести к расшифровке и модификации на транзитном шлюзе проходящего в рамках защищённого SSL/TLS-соединения трафика.

Информация об уязвимости была направлена команде разработчиков OpenSSL исследователем безопасности Масаси Кикути (Masashi Kikuchi) из Lepidum Co. Ltd, выявившем наличие проблемы. До выхода исправления сведения об уязвимости не разглашались публично. По мнению Кикути уязвимость присутствует в коде с самых первых выпусков OpenSSL и оставалась незамеченной из-за недостаточно полного рецензирования и аудита кода проекта экспертами, досконально разбирающимися в реализации TLS/SSL.

Атака может быть успешно проведена только при использовании уязвимой версии OpenSSL одновременно на стороне сервера и клиента, между которыми организован канал связи. Уязвимость в клиентской части присутствует во всех версиях OpenSSL, в то время как на сервере уязвимость проявляется только при использовании веток OpenSSL 1.0.1 и 1.0.2-beta1. Проблема вызвана тем, что OpenSSL принимает сообщения ChangeCipherSpec (CCS) вне ненадлежащей стадии установки соединения. Метод проведения атаки достаточно сложен и требует подстановки ChangeCipherSpec-сообщений клиенту и серверу в определённые моменты установки соединения, что приводит к использованию пустого предварительного главного ключа (pre master secret key) и созданию сеансовых ключей на её основе. Популярные браузеры (IE, Firefox, Chrome, Safari) не подвержены проблеме, так как в них не используется OpenSSL.

Помимо MITM-уязвимости, в новых выпусках устранена уязвимость в коде обработки фрагментов DTLS (CVE-2014-0195), которая потенциально может быть использована для организации выполнения кода на стороне сервера или клиента через отправку специально оформленных DTLS-фрагментов. Проблеме подвержены только приложения, использующие OpenSSL в качестве DTLS клиента или сервера.

Кроме того, в новых выпусках устранено несколько менее существенных уязвимостей:

  • CVE-2014-0221 - возможность совершения DoS-атаки (крах процесса) через возврат пытающемуся соединиться клиенту специально оформленных DTLS-пакетов. Проблема затрагивает только клиентские приложения, использующие DTLS;
  • CVE-2014-0198 - ошибка в функции do_ssl3_write, позволяет удалённому атакующему вызвать отказ в обслуживании через инициирование разыменования NULL-указателя. Проблема затрагивает только OpenSSL 1.0.0 и 1.0.1 с включенной опцией SSL_MODE_RELEASE_BUFFERS, которая не используется по умолчанию;
  • CVE-2010-5298 - условия гонки в функции ssl3_read_bytes позволяют удалённому атакующему добиться подстановки своих данных в рамках сеанса или вызвать отказ в обслуживании. Проблема проявляется только в многопоточных приложениях, использующих OpenSSL 1.0.0 и 1.0.1 с включенной опцией SSL_MODE_RELEASE_BUFFERS, которая не используется по умолчанию;
  • CVE-2014-3470 - TLS-клиенты, использующие анонимный набор шифров ECDH, могут быть подвежены DoS-атаке.
  • CVE-2014-0076 - техника атаки по восстановлению параметров ECDSA через атаку по сторонним каналам (восстановление данных из кэша при помощи техники FLUSH+RELOAD). Проблема ранее была исправлена в выпуске OpenSSL 1.0.1g, а теперь устранена и в версиях OpenSSL 1.0.0m и OpenSSL 0.9.8za.

Обновления пакетов с устранением уязвимостей доступны для FreeBSD, Ubuntu, CentOS, RHEL, SUSE Enterprise Linux, CRUX, Fedora, Debian, openSUSE, Slackware. Пока недоступны обновления для Gentoo, NetBSD, OpenBSD.

Дополнение 1: В кодовой базе LibreSSL проблемы с SSL_MODE_RELEASE_BUFFERS были ранее устранены разработчиками, в то время как возможность MITM-атаки (CVE-2014-0224) скорее всего не была бы найдена в рамках проекта LibreSSL.

Дополнение 2: Разработчики OpenBSD и LibreSSL возмущены тем, что их проект проигнорировали при предварительной подготовке исправлений, из-за чего они не смогли оперативно подготовить обновление с устранением уязвимостей. OpenBSD не вошёл в число проектов, заранее получивших приватное уведомление о наличии проблемы. Такое уведомления получили Red Hat, Debian, FreeBSD, AltLinux, Gentoo, Canonical, IBM, Oracle, SUSE, Amazon AMI, NetBSD/pkgsrc и Openwall, что дало им возможность сразу представить обновления пакетов.

  1. Главная ссылка к новости (https://securityblog.redhat.co...)
  2. OpenNews: Разработка OpenSSL, OpenSSH и NTP будет профинансирована Фондом поддержки ключевых открытых проектов
  3. OpenNews: Проект OpenBSD представил LibreSSL, форк OpenSSL
  4. OpenNews: В OpenSSL обнаружена критическая уязвимость, которая может привести к утечке закрытых ключей
  5. OpenNews: Итоговые результаты расследования взлома сайта OpenSSL
Лицензия: CC-BY
Тип: Интересно / Проблемы безопасности
Ключевые слова: openssl
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (58) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Шиш (?), 18:51, 05/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Ну вот, опять...  Впрочем, трудно уже будет переплюнуть heartbleed.
     
     
  • 2.37, pavlinux (ok), 14:00, 06/06/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    HB - это был отвлекающий манёвр, от более толстых дыр! Ваша NSA!  
     

  • 1.4, Аноним (-), 19:09, 05/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +14 +/
    Раньше этот массив [redacted]кода никто особо не проверял, и с годами он сгнил. Heartbleed спровоцировал вокруг него некоторый ажиотаж, и вот теперь стали выявляться уязвимости.

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

     
     
  • 2.60, Аноним (-), 08:35, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > и с годами он сгнил.

    Позволю себе с этим поспорить. SSL/TLS гнилый by design сами по себе. Ибо переусложненные до ж...ы протоколы.

     

  • 1.6, Аноним (-), 19:28, 05/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Если до сих пор толком не проверялись такие значимые пакеты - значит это было кому то нужно...
     
     
  • 2.22, Аноним (-), 23:43, 05/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    возможно проверялись, но результаты проверки не обнародовались
     
  • 2.30, Аноним (-), 09:04, 06/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Если до сих пор толком не проверялись такие значимые пакеты - значит
    > это было кому то нужно...

    Значит, это было никому не нужно. Людям вообще мало что нужно кроме собственного благополучия.

     
     
  • 3.47, Аноним (-), 00:26, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    я тебя удивлю: очень многим хочется сунуть нос именно в чужое благополучие.
     
  • 2.39, Anonymous2014 (?), 16:03, 06/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Советую вам заглянуть в код OpenSSL, боюсь, что у вас тоже не появится желание проверять его код. Нужно иметь не только знания в программировании, но и в криптографических спецификациях.
     

  • 1.9, www2 (??), 19:49, 05/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А как там с LibreSSL от команды OpenBSD?
     
     
  • 2.13, Аноним (-), 20:20, 05/06/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А как там с LibreSSL от команды OpenBSD?

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

     
     
  • 3.24, Аноним (-), 23:54, 05/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> А как там с LibreSSL от команды OpenBSD?
    > Исправляют тож - так как товарищ Кикучи с ними не поделился инфой,
    > то буквально прямо сейчас. Некоторые патчи отличаются от закоммиченных в OpenSSL
    > (там целый набор уязвимостей по факту). В любом случае тем, кто
    > не хочет принимать участие в проекте LibreSSL за пределами OpenBSD, смотреть
    > сей форк в ближайшие месяцы смысла нет, так как пока нет
    > portable-обвязки.

    Вдогонку, поразмышлять о "забывчивости" (читай, порядочности) некоторых спецов по безопасности (нашедшему OpenBSD или LibreSSL на странице по первой ссылке - пирожок):

    http://seclists.org/oss-sec/2014/q2/466
    http://marc.info/?l=openbsd-tech&m=140199721323030&w=2

     
  • 3.32, the joker (ok), 10:23, 06/06/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > так как товарищ Кикучи с ними не поделился инфой

    Товарищ Кикути вообще ни с кем не поделился. Это не его дело. Уведомлением вендоров занимался кто-то из OpenSSL. И это логично. Так что не катите бочку на японца и не вмешивайте его в свои OpenSSL-vs-LibreSSL разборки.

     
  • 3.44, Ytch (ok), 21:53, 06/06/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > так как товарищ Кикучи с ними не поделился инфой

    и со мной, гад, не поделился! вот ведь сволочь - исследовал openssl и с ними же и поделился! вот как он мог не знать что в одном из древних проектов я использовал что-то издали похожее?

     
  • 3.59, Аноним (-), 08:34, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > то буквально прямо сейчас.

    ...через  месяц? Оперативный фикс..

     
  • 2.15, забыл (?), 22:25, 05/06/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В OpenBSD всё нормально: http://marc.info/?l=openbsd-cvs&m=140198794119051&w=2
     

  • 1.16, buper (?), 22:54, 05/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    OpenSSL is written by monkeys - M.Peereboom
    https://www.peereboom.us/assl/assl/html/openssl.html
     
     
  • 2.25, Аноним (-), 23:56, 05/06/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > OpenSSL is written by monkeys - M.Peereboom
    > https://www.peereboom.us/assl/assl/html/openssl.html

    Кстати, ASSL - весьма приятная обёртка, существенно упрощающая жизнь в тех случаях, когда не требуется фигурное управление SSL/TLS и не хочется заниматься кое-чем нетрадиционным с API OpenSSL.

     
     
  • 3.57, Аноним (-), 08:34, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Кстати, ASSL - весьма приятная обёртка,

    Если завернуть г-но в фантик, конфета из него все-равно не получится, сколько ни заворачивай. Хотя, возможно, вы просто хотели повысить продажи производителю фантиков?

     
  • 2.64, Bizdelnick (?), 12:12, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > OpenSSL is written by monkeys - M.Peereboom
    > https://www.peereboom.us/assl/assl/html/openssl.html

    www.peereboom.us uses an invalid security certificate. The certificate is not trusted because it is self-signed.

    P. S. Я бы даже сказал, by bald monkeys.

     

  • 1.18, Аноним (-), 23:19, 05/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Сколько ещё уязвимостей нужно, чтобы идиоты догадались наконец-то погуглить и открыли для себя GnuTLS?
     
     
  • 2.19, Аноним (-), 23:23, 05/06/2014 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Вы имели в виду Windows 8 Professional?
     
  • 2.21, iZEN (ok), 23:35, 05/06/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Сколько ещё уязвимостей нужно, чтобы идиоты догадались наконец-то погуглить и открыли для себя GnuTLS

    Давай я сделаю это за тебя... Даю ссылку для идиотов: http://www.gnutls.org/security.html
    Стало хорошо?

     
     
  • 3.46, hito (?), 22:58, 06/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Ну всё, теперь не уснёт теперь, подумал 's/Морфеус/iZEN/'.
    Жил не тужил...
     
  • 3.54, Аноним (-), 08:29, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Стало хорошо?

    Если сравнивать с OpenSSL - там все достаточно неплохо.

     
     
  • 4.61, Аноним (-), 08:36, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Стало хорошо?
    > Если сравнивать с OpenSSL - там все достаточно неплохо.

    Код закрыт, они юзают обсуфицированный openssl :)

     
     
  • 5.67, Аноним (-), 12:27, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Код закрыт, они юзают обсуфицированный openssl :)

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

     
  • 2.23, oops (ok), 23:48, 05/06/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    ну, в gnutls все граздо хуже
     
     
  • 3.68, Аноним (-), 12:27, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > ну, в gnutls все граздо хуже

    По списку багов не видно что-то.

     

  • 1.20, Аноним (-), 23:30, 05/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Chrome
    > в них не используется OpenSSL

    Да неужели?

     
     
  • 2.26, Анонист (?), 00:33, 06/06/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    на винде не используют.
     
     
  • 3.55, Аноним (-), 08:31, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > на винде не используют.

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

     
  • 2.29, Аноним (-), 09:02, 06/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    man nss
     

  • 1.27, Классический Анонимус (?), 05:28, 06/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вроде как кошерная замена OpenSSL не GnuTLS, а djB-шное NaCl. Другой вопрос, есть ли уже ssh-клиенты, использующие NaCl? Что-то не нашёл :(
     
     
  • 2.28, Классический Анонимус (?), 05:29, 06/06/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Точнее, как раз не ssh-клиенты, а ssh-сервер + ssh-клиент. Хочу защитить свой локалхост от злых агентов АНБ.
     
     
  • 3.56, Аноним (-), 08:32, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Точнее, как раз не ssh-клиенты, а ssh-сервер + ssh-клиент. Хочу защитить свой
    > локалхост от злых агентов АНБ.

    ssh-сервер был в соседней новости. И хоть и делался какими-то забавными кидями, но стиль мышления у таковых был весьма разумным.

     
  • 2.42, arisu (ok), 21:03, 06/06/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вроде как кошерная замена OpenSSL не GnuTLS, а djB-шное NaCl.

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

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

     
     
  • 3.48, NO_ID (?), 00:57, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > можно взять, например, PolarSSL.

    или http://wiki.musl-libc.org/wiki/Alternative_libraries#Crypto другую выбрать :)

     
     
  • 4.49, arisu (ok), 01:39, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > или http://wiki.musl-libc.org/wiki/Alternative_libraries#Crypto другую выбрать :)

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

     
  • 3.50, Аноним (-), 08:21, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Это не так, если удосужиться почитать описание апи либы Просто по дефолту подсу... большой текст свёрнут, показать
     
     
  • 4.62, arisu (ok), 09:21, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> нет. в NaCl строго один вид шифрования и хэширования,
    > Это не так, если удосужиться почитать описание апи либы.

    а если исходник — то так. точнее, почти так.

    >> алсо, если очень уж не хочется обмазываться OpenSSL, можно взять, например, PolarSSL.
    > "И вместо рака будет грыжа". В смысле, переусложненность и бестолковость SSL/TLS никуда
    > не делась, да и возможности по прострелу пяток остались на месте.
    > И как раз аудит этого кода делался сильно меньшим количеством народа.

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

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

    найми эксперта, кто запрещает?

    > хватит уже пудрить людям мозги что оно от чего-то там защищает.

    это ты к кому обращаешься вообще?

     
     
  • 5.69, Аноним (-), 15:17, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Во первых, есть несколько реализаций с одинаковым API Как минимум, в природе ... большой текст свёрнут, показать
     
     
  • 6.72, arisu (ok), 04:41, 08/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> а если исходник — то так. точнее, почти так.
    > Во первых, есть несколько реализаций с "одинаковым API".

    ты прямо написал NaCl.

    > 1) NaCl - непосредственно от дяденьки Берштейна. Там таки несколько разных алгоритмов
    > в ряде вызовов возможны. Например, crypto_hash() может использовать 2 алгоритма, etc.

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

    >>> И как раз аудит этого кода делался сильно меньшим количеством народа.
    >> PolarSSL достаточно мелкая для того, чтобы можно было проаудитить самостоятельно.
    > Скажем прямо, я не испытываю желания самостоятельно аудитить ни одну реализацию TLS
    > вообще.

    тогда молись, постись и всё такое. потому что это использовали и использовать будут ещё долго.

    > Хороший пример - CurveCP.

    плохой пример. оно, конечно, получше и попроще, но с багами в спеках. которые djb чинить не хочет. например, там возможно послать сообщение без данных, но невозможно сделать ему ACK. соответственно, при установке соединения клиент или сразу должен посылать что-то бесполезное, или бомбить сервер initiate-пакетами, надеясь на то, что оттуда придёт ACK по id'у (хотя в ответе поле lastid вообще не предназначено для ACK-ов, и если по нему убирать пакеты — чикага немного сходит с ума).

    также там не предусмотрены простейшие keep-alive пакеты (то есть, их опять можно сделать только безжалостными хаками, чтобы не поломать совместимость с другими реализациями). а для UDP через NAT это иногда весьма полезно, иначе порт может закрыться.

    CurveCP — это такая академическая игрушка, proof-of-concept.

    > В таких вещах и апликушникам сложно лохануться

    да, как я написал — достаточно облажаться авторам спеков. ;-)

     

  • 1.31, MPEG LA (ok), 09:26, 06/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    т.е. уязвимость можно эксплуатировать только если OpenSSL с обеих сторон соединения - верно?
     
     
  • 2.52, Аноним (-), 08:25, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > т.е. уязвимость можно эксплуатировать только если OpenSSL с обеих сторон соединения - верно?

    У атакующего с его стороны всегда будет то что ему удобно и выгодно. Во всяком случае, вы должны действовать как будто это всегда так.

     

  • 1.34, Аноним (-), 10:47, 06/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    http://www.openwall.com/lists/oss-security/2014/05/02/7

    => Тео сам себе Злобный Буратино

     
     
  • 2.51, Аноним (-), 08:24, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    OpenBSD секурная! Самая секурная! Но критикал патч прое...ли почти на месяц. Орлы, итить.
     

  • 1.35, Аноним (-), 13:19, 06/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну вот, пожалуйста, Tor и I2P ломается точно также.
     
     
  • 2.43, arisu (ok), 21:06, 06/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну вот, пожалуйста, Tor и I2P ломается точно также.

    I2P не использует OpenSSL, и не использует SSL вообще.

     

  • 1.36, lucentcode (ok), 13:23, 06/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Хорошо, что народ стал активной искать уязвимости в таком важном проекте, и из закрывать.
     
     
  • 2.53, Аноним (-), 08:27, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Хорошо, что народ стал активной искать уязвимости в таком важном проекте

    Горбатого могила исправит. Проект, где авторы нисколько не сомневаясь напрямую выдают вывожд аппаратного RNG приложениям, даже не пытаясь подмешивать стороннюю энтропию - пишется ламерьем и дилетантами, которые в криптографии разбираются меньше чем свинья в апельсинах. И желание использовать такую криптографическую либу можно объяснить или склонностью к мазохизму, или склонностью к очковтирательству.

     
     
  • 3.63, arisu (ok), 09:37, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Горбатого могила исправит. Проект, где авторы нисколько не сомневаясь напрямую выдают вывожд
    > аппаратного RNG приложениям, даже не пытаясь подмешивать стороннюю энтропию - пишется
    > ламерьем и дилетантами, которые в криптографии разбираются меньше чем свинья в
    > апельсинах.

    use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom.

    не надо ничего туда «подмешивать», там уже всё есть.

     
     
  • 4.65, Bizdelnick (?), 12:19, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom.
    > не надо ничего туда «подмешивать», там уже всё есть.

    /dev/random, а не /dev/urandom.

    Причём в OpenSSL его и используют. Среди прочего.

     
     
  • 5.73, arisu (ok), 05:01, 08/06/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom.
    >> не надо ничего туда «подмешивать», там уже всё есть.
    > /dev/random, а не /dev/urandom.

    use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom.

    могу повторять до просветления, раз поисковики — чересчур сложно. random(4) — это бредятина в стиле «мы сами не местные», но даже там есть умное предложение: «If you are unsure about whether you should use /dev/random or /dev/urandom, then probably you want to use the latter.» а поскольку ты вряд ли читал и понял реализацию в ядре, то use /dev/urandom.

    > Причём в OpenSSL его и используют. Среди прочего.

    для сидирования своего генератора. что не имеет никакого глубокого смысла, потому что ядро само отлично справляется с накапливанием энтропии и периодическим ресидированием /dev/urandom.

     
  • 4.70, Аноним (-), 17:06, 07/06/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom. use /dev/urandom.

    У openssl есть возможность попросить аппаратную акселерацию. Вот они и акселерировали аппаратно, бэть!!! В том числе и генерацию случайных чисел. Руки за такую "акселерацию криптографии" обрывать.

    > не надо ничего туда «подмешивать», там уже всё есть.

    Ну вот некоторым хочется быть святее папы Римского. С понятным результатом...

     

  • 1.38, beerseller (ok), 14:03, 06/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    В NSS такого нету? Я надеюсь.
     
  • 1.40, arisu (ok), 20:56, 06/06/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    решето наконец-то решили хорошенько потрясти? мне это старый анекдот напоминает. про то, как мужик думал, что проще: этих детей отмыть, или новых сделать.
     
     
  • 2.45, guper (?), 22:12, 06/06/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Лучше новых сделать, но не ему )
     

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



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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