Прямая секретность или как достичь максимальной безопасности сайта

В свете недавно раскрытых фактов массового слежения, ранее обделенная вниманием особенность SSL/TLS, известная как «прогрессивная или прямая секретность» (Forward Secrecy, FS), вдруг стала очень актуальной. Чем же так интересна и важна сегодня прямая секретность?

---

Обмен ключами сеанса для соединения по SSL

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

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

Хотя, в некоторых случаях, подобный побочный эффект даже необходим. Многие устройства сетевой безопасности поддерживают возможность расшифровки передаваемых данных и таким образом могут мониторить трафик, при условии, что известны закрытые ключи сервера. Без этой информации, системы обнаружения и предотвращения вторжений (IDS/IPS) и файрволы веб-приложений (WAF) не имеют возможности просматривать трафик, а поэтому не могут гарантировать защиту. В контексте массового слежения, обмен ключами по алгоритму RSA заставляет серьезно задуматься о последствиях.

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

Алгоритм Диффи-Хеллмана – более надежный способ обмена ключами

Существует альтернативный метод ключевого обмена: использовать эфемерные ключи Диффи-Хеллмана. Это медленный метод, но ключи при обмене генерируются таким образом, что только две участвующие стороны могут получить к ним доступ. Действительно, никто, даже обладатель закрытого ключа сервера.

Злоумышленник, заполучивший закрытый ключ сервера, может провести активную атаку типа «человек посередине» (MITM-атаку) и получить контроль над сервером. Но это возможно только непосредственно во время сеанса связи. У злоумышленника нет возможности скопировать горы данных и впоследствии расшифровать их. По закрытии сеанса связи, обе стороны уничтожают ключи сеанса, и поэтому единственно возможный способ расшифровки переданных данных – взломать сами ключи сеанса. В этом и заключается суть повышенного режима безопасности сайта, известного как «прогрессивная или прямая секретность» или forward secrecy.

Также данный режим известен как «совершенная прямая секретность» (в англоязычном варианте - perfect forward secrecy). Тем не менее, когда существует даже минимальный риск расшифровки переданных данных путем взлома сеансовых ключей, то, очевидно, что секретность нельзя назвать совершенной. Очевидно, что взломать ключи сессии куда сложней, чем получить доступ к закрытому ключу сервера, особенно, если вы можете получить формальный доступ к ключу. Еще более усложняет задачу тот факт, что теперь, чтобы декодировать переданные данные, вашему недоброжелателю придется заполучить не один ключ – ключ сервера, а все ключи для каждого отдельного сеанса связи.

Прямая секретность и SSL

В протоколе SSL осуществлена возможность поддержки прямой секретности по двум алгоритмам: по стандартному Диффи-Хеллмана (Diffie-Hellman, DHE) и по его адаптированной версии – криптосистеме на основе эллиптических кривых (Elliptic Curve Cryptography, ECDHE). Почему же все поголовно не используют их? Потому, что даже при наличии желания запустить режим прогрессивной секретности и необходимых знаний и умений, остается две проблемы:

• Алгоритм DHE требует значительных временных затрат. Веб-администраторы часто отключают наборы шифров Диффи-Хеллмана, чтобы поднять производительность сайта. Кроме того, не все браузеры поддерживают все необходимые наборы шифров. Например, IE 9 и 10 поддерживает алгоритм DHE только в связке с устаревшими DSA-ключами.
• Алгоритм ECDHE несколько быстрее алгоритма DHE. Но с другой стороны, алгоритмы ECDHE – новая технология, которая имеет ограниченную поддержку. Так, алгоритмы были добавлены в открытый доступ на OpenSSL совсем недавно и только в версиях 1.х.

Если вы решите, что готовы реализовать оба алгоритма, ECDHE и DHE, тогда скорее всего вы сможете обеспечить режим прямой секретности любому клиенту. Но даже если задействовать только алгоритм ECDHE, вы сможете покрыть достаточное количество своих пользователей. Решение за вами. Большинство сайтов Google, к примеру, сконфигурировано без шифров Диффи-Хеллмана.

Конфигурация прямой секретности

Активация режима прогрессивной (прямой) секретности осуществляется в два шага:

1. Настроить сервер на автоматический выбор наиболее подходящего набора шифров из списка, предоставленного клиентами SSL.
2. Расположить шифры ECDHE и DHE в начале списка. Такое расположение немаловажно: шифры ECDHE требуют меньших затрат по времени, поэтому использовать их предпочтительней (если они поддерживаются клиентами).

Поскольку некоторые браузеры не поддерживают все шифры, используемые для режима прямой секретности, довольно непросто определить какие шифры следует активировать и разместить в начале списка, а какие не стоит. Прояснить ситуацию вы можете, собрав информацию о тех, кто уже реализовал режим прямой секретности. Сделать это можно, просканировав сайт на тестере от SSL Labs (https://www.ssllabs.com/ssltest/). Например, для одного из серверов Google показатели следующие:


Следующие несколько шифров вам, возможно, следует активировать и дать первые места в списке:

1. TLS_ECDHE_RSA_WITH_RC4_128_SHA 2. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 3. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 4. TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

Список составлен исходя из того, что у вас есть RSA-ключ, а он есть практически у всех. Существует ряд шифров ECDHE, которые необходимо активировать, когда используется алгоритм цифровой подписи на эллиптических кривых (ECDSA-ключ). В данный момент, мы советуем не добавлять шифры в режиме счетчика Галуа (Galois/Counter Mode, или GCM) по причине ограниченной совместимости.

Также мы рекомендуем воздержаться от применения кода Рона RC4 против потенциальной атаки BEAST по той же причине несовместимости со всеми устройствами клиентов. В качестве дополнительной помощи в том же тестере SSL Labs был добавлен симулятор рукопожатия. Симулятор может определять характеристики наиболее известных браузеров, давать выбор вероятных шифров и советовать, какие из них будут совместимы с режимом прогрессивной секретности. Ниже показан скриншот Симулятора в действии для того сервера Google:



 Если все сделано правильно, на верхней панели появится сообщение о том, что режим работает:

 

Более детальные инструкции по конфигурации сервера под прогрессивную секретность Вы найдете в статье "Настройка прямой секретности на Apache, Nginx и OpenSSL".

Другие возможные векторы атак

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

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

Еще один немаловажный момент. Существует дополнительный механизм управления сеансами, получивший название билет сеанса (session ticket), который предполагает использование отдельных ключей шифрования, которые редко обновляются (в худших случаях, никогда). Если вы не разбираетесь в механизмах управления своими ключами досконально, эту функцию лучше отключить, дабы избежать ненужного риска.