-
Notifications
You must be signed in to change notification settings - Fork 0
Руководство по оценочному анализу SSL серверов
Протокол SSL (сокращение от англ. Secure Sockets Layer) является стандартом шифрования данных для передачи по каналам связи. Мы считаем, что удивительно мало внимания уделяется тому, как настраивается протокол SSL, учитывая его широкое использование. SSL относительно прост, но в процессе его использования можно наткнуться на "подводные камни". Это руководство направлено на создание простой методологии оценки, позволяющей администраторам уверенно оценивать качество конфигурирования SSL сервера без необходимости быть экспертами SSL.
Наш подход заключается в выполнении следующих шагов:
- Сначала проверяется сертификат, чтобы убедиться, что он действителен и имеет необходимый уровень доверия.
-
Мы проверяем три параметра конфигурации сервера:
- Поддержка протокола
- Поддержка обмена ключами
- Поддержка шифрования
- Мы объединяем оценки параметров сервера в общий балл (выраженный числом от 0 до 100). Ноль в любой категории дает нулевой общий балл. Затем вычисляется литеральная оценка, с использованием таблицы ниже.
- Затем мы применяем ряд правил (описанных в разделе «Изменения») для обработки некоторых аспектов конфигурации сервера, которые не могут быть выражены в численном виде. Большинство правил уменьшают оценку на один пункт (до A-, B, C, D, E или F), если они выявляют негативное свойство. Некоторые правила могут повысить оценку на один пункт (например до A+), чтобы отметить экстраординарные конфигурации.
- В определенных случаях мы избегаем стандартных оценок A-F, если мы думаем, что мы столкнулись с необычной ситуацией. К таким таким случаям можно отнести оценку "M" (несоответствие имени сертификата) и оценку "T" (сертификат сайта не доверен). Когда нет доверия к сертификату, фактический уровень безопасности не имеет значения, так как хакеры могут взломать защиту такого соединения.
| Численный результат | Грейд |
|---|---|
| оценка >= 80 | A |
| оценка >= 65 | B |
| оценка >= 50 | C |
| оценка >= 35 | D |
| оценка >= 20 | E |
| оценка < 20 | F |
Первоначально наша методология была простой и лаконичной, но, к сожалению, со временем усложнилась. Этот документ не был полностью обновлен, чтобы отразить изменения. В следующем релизе мы начнем разработку с нуля, чтобы вернуться к первоначальной простоте.
Наша основная цель - сосредоточиться на тех проблемах безопасности, присутствие которых можно определить удаленно и без ручной оценки. Это полностью автоматизированный подход, позволяющий проводить крупномасштабную оценку конфигураций SSL. Наша цель - произвести сканирование всех SSL-серверов в общедоступном Интернете. Сфокусировавшись на автоматизации, мы решили не тратить силы на второстепенные проблемы. Мы перечислим эти проблемы в этом руководстве и, надеюсь, найдем способы улучшить нашу автоматизацию, чтобы включить их в будущую версию этого руководства. Некоторые из этих проблем перечислены здесь:
Качество сертификатов В настоящее время используются три типа сертификатов: сертификаты, подтвержденные доменом, сертификаты с подтверждением организации и повышенной надежности (EV). Это руководство требует, чтобы сертификат был правильным, но не выходит за рамки этого основного требования. Сертификаты для домена и сертификаты для организации, обычно обрабатываются одинаково текущим поколением браузера и, таким образом, обеспечивают аналогичную гарантию для пользователей. Сертификаты EV обрабатываются значительно лучше, и, как правило, они рекомендуются для серьезных веб-сайтов. Однако, без надежного способа определения цели веб-сайта мало что может сделать это руководство для оценки соответствия сертификата, используемого на конкретном сайте, для его целей.
Проблемы с захватом сессии в веб-приложениях Существует несколько способов, которыми веб-приложения могут дискредитировать SSL и сделать его менее эффективным. Например, cookie файлы сессий, которые не помечены как защищенные, могут быть получены определенным злоумышленником, что приведет к захвату сессии и, следовательно, к компрометированию приложения. Такие проблемы не являются ошибкой SSL, но тем не менее они влияют на ее практическое применение. Обнаружение проблем, связанных с веб-приложениями, является нетривиальным для автоматического выполнения, и в этой версии мы не пытаемся это сделать. Мы оставляем эту проблему для рассмотрения в будущем. Тем временем, чтобы устранить любые сомнения, которые могут возникнуть в отношении серьезности вышеупомянутых проблем, мы укажем, что любому приложению, которое неправильно реализует распространение токена сессии, должен быть присвоен нулевой балл.
Мы не знаем. Чтобы узнать, правильно ли настроен сервер SSL, нам нужно знать, что делает ваш сайт. Поскольку разные веб-сайты имеют разные потребности, мы не можем выбрать какую-либо одну конфигурацию и сказать, что она работает для всех. Но мы можем сделать две вещи. Во-первых, мы можем дать вам общий совет по настройке и рассказать вам, чего вы никогда не должны делать. Во-вторых, мы можем дать вам общее руководство, используя примеры того, что делают другие веб-сайты. Если это вас интересует, перейдите к концу этого документа для получения дополнительной информации.
Нет. Нетривиальный веб-сайт не может быть защищен, если он не реализует SSL, но одного SSL недостаточно. SSL имеет только один аспект безопасности, и это безопасность канала связи между веб-сайтом и его пользователями. SSL не позволяет и не может решить ряд возможных проблем безопасности, которые могут существовать на веб-сайте. Рассматривайте SSL в качестве фундамента, но только одного фундамента недостаточно.
Сертификат сервера часто является самой слабой точкой конфигурации SSL сервера. Сертификат, который не является доверенным (то есть, в конечном счете не подписан известным центром сертификации), не позволяет предотвратить атаки типа «человек-в-середине» (MITM) и делает SSL бесполезным. Сертификат, который стал некорректным по каким-либо другим причинам (например, с истекшим сроком), подрывает доверие и в долгосрочной перспективе ставит под угрозу безопасность всего Интернета.
По этим причинам любая из следующих проблем немедленно приводит к нулевой оценке:
- Несоответствие доменных имен
- Сертификат еще не действителен
- Истек срок действия сертификата
- Использование самоподписанного сертификата
- Использование сертификата, которому не доверяют (неизвестный CA или другая ошибка проверки)
- Использование отозванного сертификата
- Небезопасная подпись (метод шифрования) сертификата (MD2 или MD5)
- Небезопасный ключ
Замечание
Некоторые организации создают свои собственные (частные) сертификаты CA, что является полностью законным, если такие сертификаты CA распространяются безопасным образом (например, с помощью настройки браузеров) всем тем, кто в этом нуждается. Без доступа к таким сертификатам мы не сможем проверить, что сайт, который мы проверяем, имеет доверенный сертификат, но мы думаем, что такие сайты будут относительно редкими. Такие случаи можно рассматривать индивидуально.
SSL - это сложный гибридный протокол с поддержкой многих функций на нескольких этапах обработки. Чтобы учесть все аспекты, мы оцениваем конфигурацию SSL-сервера в трех категориях, как показано ниже. Мы вычисляем итоговый результат как комбинацию показателей в отдельных категориях, как описано выше в разделе «Методология».
| Категория | Оценка |
|---|---|
| Поддержка протокола | 30% |
| Обмен ключами | 30% |
| Криптостойкость шифра | 40% |
В следующих разделах объясняется система оценивания для каждой из категорий.
Сначала мы рассмотрим протоколы, поддерживаемые сервером SSL. Например, оба протокола SSL 2.0 и SSL 3.0 имеют известные слабые стороны. Поскольку сервер может поддерживать несколько протоколов, мы используем следующий алгоритм для получения окончательного результата:
- Начинаем с оценивания лучшего протокола
- Производим оценку худшего протокола
- Получаем среднее арифметическое оценок
| Протокол | Оценка |
|---|---|
| SSL 2.0 | 0% |
| SSL 3.0 | 80% |
| TLS 1.0 | 90% |
| TLS 1.1 | 95% |
| TLS 1.2 | 100% |
Фаза обмена ключами выполняет две функции. Одна из них - выполнить аутентификацию, позволяющую хотя бы одной стороне проверить личность другой стороны. Другая цель - обеспечить безопасное генерирование и обмен секретными ключами, которые будут использоваться в течение оставшейся части сеанса. Уязвимости на этапе обмена ключами влияют на сессию двумя способами:
- Обмен ключами без аутентификации позволяет активному злоумышленнику выполнить атаку MITM, получая доступ к полному каналу связи.
- Большинство серверов также полагаются на общедоступную криптографию для обмена ключами. Поэтому, чем сильнее секретный ключ сервера, тем труднее взломать соединение в фазе обмена ключами. Слабый ключ или процедура обмена, которая использует только часть ключа (так называемые экспортные обмены ключами), может привести к ослаблению защиты на этапе обмена ключами, что облегчит компрометирование секретных ключей сессии. На некоторых серверах используются механизмы обмена ключами, которые не зависят от частного ключа (ключ все еще используется для аутентификации). Двумя популярными алгоритмами являются эфемерный алгоритм обмена ключами Диффи-Хеллмана (DHE) и его эллиптическая криптографическая вариация ECDHE. Если используется отдельный механизм обмена ключами, общая стойкость будет зависеть от его стойкости механизма и самого закрытого ключа.
| Аспект обмена ключами | Оценка |
|---|---|
| Слабый ключ (уязвимый Debian OpenSSL) | 0% |
| Анонимный обмен ключами (без аутентификации) | 0% |
| Сила ключа или DH параметра <512 бит | 20% |
| Экспортируемый обмен ключами (ограниченный до 512 бит) | 40% |
| Сила ключа или DH параметра <1024 бит (например, 512) | 40% |
| Сила ключа или DH параметра <2048 бит (например, 1024) | 80% |
| Сила ключа или DH параметра <4096 бит (например, 2048) | 90% |
| Сила ключа или DH параметра > = 4096 бит (например, 4096) | 100% |
Замечание
Для конфигураций, которые полагаются на обмен ключами DHE или ECDHE, сила DH параметров учитывается при определении защищенности фазы рукопожатия в целом. Многие серверы, поддерживающие DHE, используют параметры DH с 1024 битным ключом шифрования. На таких серверах защищенность фазы обмена ключами никогда не будет превышать 1024 бит, даже если закрытый ключ сильнее (обычно 2048 бит).
Чтобы взломать сеанс связи, злоумышленник может попытаться взломать симметричный шифр, используемый для большей части сообщения. Более стойкий шифр обеспечивает более защищенное шифрование и, следовательно, увеличивает необходимый для его взлома объем усилий. Поскольку сервер может поддерживать шифры различной стойкости, мы пришли к системе оценивания, которая снижает общую оценку за использование слабых шифров. Чтобы вычислить оценку для этой категории, мы следуем этому алгоритму:
- Сначала оцениваем самый стойкий шифр
- Добавляем оценку самого слабого шифра
- Получаем среднее арифметическое
| Криптостойкость шифра | Оценка |
|---|---|
| 0 бит (без шифрования) | 0% |
| < 128 бит (например, 40, 56) | 20% |
| < 256 бит (например, 128, 168) | 80% |
| >= 256 бит (например, 256) | 100% |
Совет по конфигурации из оригинального документа был заменен отдельным документом с полным охватом этой темы. Вы можете ознакомиться с ним тут.
Протокол Secure Sockets Layer (SSL) является стандартом для шифрованной сетевой связи. Он был придуман в Netscape в 1994 году; Версия 2.0 была первой публичной версией. SSL позднее был обновлен до версии 3.0 и с последующими незначительными улучшениями был стандартизирован под именем TLS (Transport Layer Security). TLS v1.2, самая последняя версия, определяется спецификацией RFC 5246.
Оригинал этой статьи на английском языке можно найти тут
Первая версия этого руководства была написана Иваном Ристиком и впоследствии дополнена вкладами следующих лиц, перечисленных в алфавитном порядке: Кристиан Бокерманн, Кристиан Фолини, Роберт Хансен, Офер Шезаф, Колин Уотсон, Юрий Васин.
SSL Labs - это исследовательское направление компании Qualys целью которого является изучение SSL/TLS и PKI, а также разработка инструментов и документации для их оценки и настройки. С 2009 года, когда была запущен SSL Labs, сотни тысяч оценок были выполнены с использованием бесплатного онлайн-инструмента. Другие проекты, выполняемые SSL Labs, включают периодические интернет-опросы по тематике SSL и SSL Pulse, ежемесячное сканирование около 170 000 наиболее популярных в мире сайтов с поддержкой SSL.
Qualys, Inc. (NASDAQ: QLYS) является пионером и ведущим поставщиком решений для обеспечения безопасности на основе облачных вычислений с более чем 9300 клиентами в более чем 100 странах, включая большую часть компаний из Forbes Global 100 и Fortune 100. Платформа Qualys Cloud и интегрированный пакет решений помогают организациям упростить операции безопасности и снизить затраты на соблюдение требований, предоставляя критически важную информацию по безопасности по запросу и автоматизируя полный спектр аудита, соответствия и защиты IT-систем и веб-приложений. Компания Qualys, основанная в 1999 году, установила стратегические партнерские отношения с ведущими поставщиками услуг и консалтинговыми организациями, включая Accenture, BT, Cognizant Technology Solutions, Deutsche Telekom, Fujitsu, HCL, HP Enterprise, IBM, Infosys, NTT, Optiv, SecureWorks, Tata Communications, Verizon и Wipro. Компания также является одним из основателей Cloud Security Alliance (CSA). Для получения дополнительной информации посетите сайт www.qualys.com.
Qualys, логотип Qualys и QualysGuard являются торговыми марками Qualys, Inc. Все остальные продукты или названия могут быть товарными знаками соответствующих компаний.