План Б на случай новых угроз. Поиск альтернативы OpenSSL
Когда обнаруживаются опасные уязвимости в безопасности, способность переключиться на альтернативное ПО может иметь решающее значение.
Если вы еще не слышали, недавно была суматоха, вызванная утечкой информации в OpenSSL что может привести к компрометированию частных ключей злоумышленниками. Большинство поставщиков предоставили обновление OpenSSL в течении нескольких часов после того, как стало известно о проблеме и многие сайты пропатчили свое ПО достаточно быстро. Тем не менее, хорошо иметь план Б, чтобы не находится под угрозой, дожидаясь выхода заплатки безопасности. Например, большинство программных пакетов SSL/TLS поддерживают более одного алгоритма хеширования, шифрования и так далее. Если уязвимость обнаружена в одном (например RC4), вы можете переключиться на другой (например AES).
Тем не менее, программные пакеты сами по себе имеют проблемы. OpenSSL, GnuTLS, PolarSSL и тп, все они содержат ошибки в коде и в большей или меньшей мере подвержены различным уязвимостям и рискам. Если вы используете веб-сервер Apache, вы можете использовать mod_openssl и иметь mod_gnutls готовый для переключения на него, в случае, если уязвимость будет обнаружена в mod_ssl или в самом OpenSSL.
Альтернативы OpenSSL
Хорошая новость в том, что на сегодня доступно несколько зрелых продуктов-альтернатив OpenSSL. Некоторые из них распространяются в виде готовых пакетов, как GnuTLS и NSS, а некоторые нужно собирать из исходников, как PolarSSL. Если вы хотите должным образом поддерживать несколько криптографических библиотек, то нужно абстрагироваться от настроек. Например, некоторые библиотеки проверяют имена хостов и сертификаты по умолчанию, а некоторые нет.
Еще есть LibreSSL — это OpenBSD-проект. В типичной для OpenBSD манере, разработчики начали с разборки кода (например, удалили весь код, не нужный для OpenBSD) и решили известные бреши в безопасности. На сегодняшний день не ясно, будет ли LibreSSL поддерживать Linux в ближайшее время, если вообще когда-нибудь будет. Даже с очищенным кодом, LibreSSL имеет те же архитектурные недостатки, что и OpenSSL, так что я не уверен, что этот продукт ждет успех. Хотелось бы ошибаться.
Apache HTTPD хороший пример, как абстрагироваться для возможности горячей замены криптографических модулей — mod_ssl, mod_gnutls или mod_nss. Единственные изменения конфигурации, которые требуются — это включение соответствующего модуля в httpd.conf и замена конфигурационных файлов (например, mod_nss использует директиву SSLCipherSuite, а mod_nss использует NSSCipherSuite). Вы можете сделать этот шаг зависимым от того, какой из модулей загружается и вести единый конфигурационный файл, который поддерживает оба модуля.
Почему же так немного людей и приложений использует альтернативы OpenSSL? Простая экономика — разработка ПО с использованием одной криптографической библиотеки требует намного меньше ресурсов, чем поддержка нескольких криптографических библиотек. Большинство приложений, которые обеспечивают или поддерживают SSL/TLS, имеют OpenSSL вкомпилированный непосредственно в само приложение, хотя некоторые поддерживают использование других библиотек. Если, конечно, ваш план экстренного реагирования включает в себя перекомпилирование приложения, после чего остается только надеяться, что все будет работать, ведь у вас не будет времени на тестирование в экстренной ситуации.
Поддерживать две рабочие копии также довольно накладно. Поддержка двух вариантов ПО — одного с OpenSSL и одного с GnuTLS — очевидно потребует куда больше работы, чем просто использовать один вариант ПО. Поэтому, а также потому, что большинство прокси не поддерживает ничего, кроме OpenSSL, на самом деле, никто так не делает.
SSL and TLS proxies
Однако, существуют менее затратные способы поддержания криптографической гибкости, чем замена всего приложения или поддержание двух копий. Как видно из примера с Apache, если абстрагировать реализацию SSL/TLS, то вносить изменения намного проще. Так почему бы вообще не убрать SSL/TLS? Существует несколько SSL и TLS прокси, используя которые вы можете добиться конфигурации SSL и TLS любой сложности с одним сравнительно простым приложением (например, сравнительно с почтовым сервером).
Другое преимущество заключается в упрощении. Если у вас есть пять приложений, которые используют SSL/TLS, то прокси-сервер позволит использовать единый пакет SSL/TLS, чтобы справиться с этим. Очевидно, складывать все яйца в одну корзину опасно, но если у вас всегда есть резервная корзина яиц, такой подход может быть более безопасен в долгосрочной перспективе. Единственный недостаток с SSL/TLS прокси в том, что если вы используете клиентские сертификаты для аутентификации, то необходимо чтобы прокси пропускал информацию к бекенду. В случае с веб-сервером, это может быть реализовано с использованием специальных X-заголовков, например.
Stunnel and Stud
Stunnel — один из старейших SSL/TLS прокси, в то время, как Stud относительно недавняя разработка, но код не обновлялся уже два года. Оба, однако, имеют важный недостаток: они используют OpenSSL и насколько я знаю, не могут использовать GnuTLS без существенных изменений в коде. Я все таки надеялся, что кто-то должен был написать прокси, использующее GnuTLS
Я посмотрел более десятка SSL/TLS прокси и не смог найти таких, которые поддерживали бы что-то, кроме OpenSSL. Полагаю, это еще одна причина, почему так мало людей инвестируют в криптографические библиотеки, кроме OpenSSL. В мире открытого исходного кода, ваш выбор OpenSSL и вещи которые используют OpenSSL
Apache
Тем не менее, есть ПО, которое поддерживает различные SSL/TLS имплементации и имеет возможности прокси. Apache HTTPD с модулем mod_proxy поддерживает HTTP, FTP, и HTTP CONNECT. Таким образом, вы можете покрыть web, FTP и любые другие клиенты, которые поддерживают HTTP CONNECT. Чтобы пустить через прокси веб-сайт, нужно просто активировать mod_proxy и настроить его, примерно так:
ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/
Чтобы поддерживать метод CONNECT вам потребуется модуль mod_proxy_connect и конфигурация:
AllowConnect port X
где X — это порт (по умолчанию доступны только 443 и 563, HTTPS и NNTP поверх SSL соответственно)
Компиляция с GnuTLS
Здесь дела из плохих становятся просто ужасными. Я проверил довольно много программных пакетов и хотя большинство из них поддерживают OpenSSL, очень мало поддерживают что-либо еще. Вот цитата с сайта Dovecot:
Dovecot был первоначально разработан для поддержки как OpenSSL так и GnuTLS. Однако, с GnuTLS возникли проблемы и в настоящее время он вообще не поддерживается. Патчи, которые могли бы исправить ситуацию, приветствуются.
Я подозреваю, проблема в том, что OpenSSL работает достаточно хорошо, чтобы не вкладывать много времени и усилий на поддержку второй реализации.
Вывод
Откровенно говоря, эта статья пошла вовсе не так, как я рассчитывал. Я надеялся, что мне удастся найти программное обеспечение, вроде Stunnel, которое поддерживает GnuTLS. Я собирался описать процесс его установки и конфигурации прокси для работы HTTP и других протоколов, как POP и IMAP. Тогда вы могли бы поставить все это и в следующий раз, когда возникнет проблема с OpenSSL, вы смогли бы легко переключиться на GnuTLS до разрешения проблем. К сожалению, это был не тот случай. Вместо этого, оказалось, что кроме нескольких приложений, в основном, все поддерживают SSL и только OpenSSL. Я надеюсь, что ситуация изменится со временем.
