SSL.com желает всем нашим клиентам и посетителям счастливых, безопасных и здоровых праздников, а также благополучного 2021 года! Мы надеемся, что новый год окажется немного меньше, ммм… интересный чем до 2020 года, но мы уверены, что не пройдет и месяца без важных новостей из мира сетевой безопасности, цифровых сертификатов и PKI.
Уязвимость OpenSSL DoS
Мы рассмотрели эту проблему в блоге ранее в этом месяце, но стоит повторить. Уязвимость высокой степени опасности в OpenSSL было обнаружено, что влияет на все версии OpenSSL 1.0.2 и 1.1.1 до 1.1.1i. Эта уязвимость может быть использована для создания атаки типа «отказ в обслуживании» (DoS). ОпенSSL 1.1.1i, выпущенный 8 декабря 2020 г., включает исправление.
Пользователи OpenSSL должны как можно скорее обновить свои установки. Исправление можно применить двумя способами:
- Пользователи OpenSSL 1.1.1 и неподдерживаемых пользователей 1.0.2 должны перейти на 1.1.1i.
- Клиенты с премиальной поддержкой OpenSSL 1.0.2 должны перейти на 1.0.2x.
OpenSSL в настоящее время установлен на большинстве веб-серверов HTTPS. Вы можете узнать больше об уязвимости в SSL.com Блог, а в проекте OpenSSL Советы по безопасности.
Cloudflare защищает новые протоколы конфиденциальности
Тим Андерсон переправу в Регистре, что Cloudflare «настаивает на принятии новых интернет-протоколов, которые, по его словам, сделают« Интернет с уважением конфиденциальности ». Эти протоколы включают улучшенную конфиденциальность DNS через HTTPS (DoH), дополнительное шифрование для TLS рукопожатие, а также улучшения безопасности для обработки паролей пользователей.
Забывчивый DoH
DNS через HTTPS (DoH) устраняет слабое звено в конфиденциальности в Интернете, шифруя запросы и ответы DNS, которые исторически отправлялись в виде открытого текста. Забывчивый DoH (ODoH) продвигает защиту конфиденциальности DNS на шаг вперед, не позволяя серверам DoH знать IP-адрес клиента:
Суть ODoH заключается в том, что он вводит сетевой прокси между клиентом и сервером DoH. Прокси-сервер не видит DNS-запрос, который может быть прочитан только сервером DoH. Сервер не знает IP-адрес клиента. Запрос является частным, если прокси и сервер не вступают в сговор.
Cloudflare уже заявила о поддержке ODoH, который был разработан инженерами Cloudflare, Apple и Fastly. Вы можете узнать больше, посмотрев их бумага на arxiv.org.
Зашифрованное приветствие клиента (ECH)
Зашифрованное приветствие клиента (ECH) предлагает улучшенное шифрование рукопожатия в TLS, выходя за рамки Зашифрованный SNI (ESNI), который защищает только указание имени сервера (SNI) в TLS рукопожатие. Инженер-исследователь Cloudflare Кристофер Паттон пишет,
Хотя ESNI сделал значительный шаг вперед, он не достигает нашей цели - полного шифрования рукопожатия. Помимо того, что он неполный - он только защищает SNI - он уязвим для несколько изощренных атак, которые, хотя и сложно осуществить, указывают на теоретические недостатки в конструкции протокола, которые необходимо устранить.
...
В конечном итоге цель ECH - гарантировать, что TLS подключения к разным исходным серверам за одним и тем же поставщиком услуг ECH неотличимы друг от друга.
Неудивительно, поскольку ECH «имеет смысл только вместе с DoH и в контексте CDN (сети распространения контента)», Cloudflare «считает себя вероятным поставщиком ECH». Вы можете узнать больше о ECH в IETF проект предложения.
НЕПРЫВНЫЕ пароли
OPAQUE пароли - «своего рода каламбур на забытой псевдослучайной функции (OPRF) в сочетании с обменом ключами с аутентификацией паролем (PAKE)» - это механизм, позволяющий полностью избежать передачи пароля пользователя на сервер. OPAQUE достигает этого, «когда сервер и клиент совместно вычисляют соленый хэш для сравнения с использованием промежуточной второй соли». Это гарантирует, что сервер не сможет узнать пароль пользователя во время аутентификации, а пользователь не узнает секретную соль сервера ».
Вы можете узнать больше о OPAQUE паролях в эта бумага [Ссылка в формате PDF] исследователями из Калифорнийского университета в Ирвине и IBM, а также инженером Cloudflare Татьяной Брэдли. блоге.
Утечка учетных данных FTP, возможно, связана с атакой SolarWinds
Если вы не провели последние несколько недель в удаленной, автономной кабине (неплохая идея сейчас, когда мы думаем об этом), вы, вероятно, уже много слышали о атака цепочки поставок это скомпрометировало программное обеспечение для мониторинга ИТ SolarWinds Orion и многих его пользователей в правительстве и промышленности. Рави Лакшманан 16 декабря История в Hacker News обсуждается, как злоумышленникам «вероятно, удалось скомпрометировать сборку программного обеспечения и инфраструктуру подписи кода платформы SolarWinds Orion еще в октябре 2019 года, чтобы доставить вредоносный бэкдор через процесс выпуска программного обеспечения».
Идея… заключалась в том, чтобы скомпрометировать систему сборки, незаметно внедрить собственный код в исходный код программного обеспечения, дождаться, пока компания скомпилировать, подписать пакеты и, наконец, проверить, отображаются ли их модификации в недавно выпущенных обновлениях, как ожидалось.
График на октябрь 2019 года совпадает с графиком исследователя безопасности Винота Кумера. открытиев ноябре 2019 г. из общедоступного репозитория GitHub с утечкой учетных данных FTP в виде открытого текста для сервера обновлений Solarwinds, и что этот сервер был доступен с паролем «solarwinds123». Репо, о котором идет речь, было открыто для общественности «с 17 июня 2018 года», что давало потенциальным злоумышленникам достаточно времени, чтобы обнаружить и использовать утекшие учетные данные.
Конечно, не помогло и то, что SolarWinds также посоветовал пользователям отключить меры безопасности:
Что еще хуже, вредоносный код, добавленный в обновление программного обеспечения Orion, мог остаться незамеченным антивирусным программным обеспечением и другими инструментами безопасности на целевых системах из-за собственной разработки SolarWinds. Консультации по поддержке, который заявляет, что его продукты могут работать неправильно, если их файловые каталоги не освобождены от антивирусного сканирования и ограничений объектов групповой политики (GPO).
