НАО «Алматинский Университет Энергетики и Связи» Институт Систем Управления и Информационных Технологии Кафедра «Системы информационной безопасности» ОТЧЕТ по Расчетно-графической работе № 2-3 на тему: «Анализ защищенности протоколов SSL/TLS» Специальность: Системы Информационной Безопасности Выполнил: Анарбекулы А Группа: СИБ2-16-2 Принял: ст.преп. Омар Т.К. ______«______»_______2019 Алматы 2019 Содержание Введение ....................................................................................................................... 2 Задание ......................................................................................................................... 3 Выполнение работы .................................................................................................... 4 Заключение................................................................................................................. 30 Список литературы.................................................................................................... 33 1 Введение SSL — это сокращение от Secure Socket Layer — это стандартная интернет технология безопасности, которая используется, чтобы обеспечить зашифрованное соединение между веб-сервером (сайтом) и браузером. SSL сертификат позволяет нам использовать https протокол. Это безопасное соединение, которое гарантирует, что информация которая передается от вашего браузера на сервер остается приватной; то есть защищенной от хакеров или любого, кто хочет украсть информацию. Один из самых распространенных примеров использования SSL — это защита клиента во время онлайн транзакции (покупки товара, оплаты). SSL сертификаты используются для шифрования информации, передаваемой через сети общего доступа. Сертификаты применяют при построении почтовой системы, а также (значительно чаще) устанавливают на домены для получения доступа к сайту через интернет браузер по порту 443. Только посредством https соединения осуществляются любые денежные операции на сайтах систем онлайн торговли. В сертификате хранится следующая информация: полное (уникальное) имя владельца сертификата открытый ключ владельца дата выдачи ssl сертификата дата окончания сертификата полное (уникальное) имя центра сертификации цифровая подпись издателя Целью РГР является обучение методам и средствам анализа защищенности протоколов SSL/TLS. Защита транспортного уровня веб-приложения основана на использовании SSL/TLS, имеющих значительное количество механизмов, функций и параметров защиты, реализация и конфигурация которых определяет в конечном итоге уровень защищенности веб-приложения. Несмотря на то, что в настоящее время известно много автоматизированных средств тестирования защищенности SSL/TLS (например, сервис www.ssllabs.com, программы SSLscan и SSLyze), детали их реализации, как правило, неизвестны или требуют дополнительного исследования, что иногда не позволяет полностью доверять результатам их работы. Одним из низкоуровневых и надежных средств тестирования защищенности служб SSL/TLS является клиент OpenSSL. 2 Задание Выполнить тестирование защищенности служб SSL/TLS веб-сервера с условным названием - www.habr.com. 1. Выполнить базовые проверки SSL/TLS. 2. Идентифицировать все поддерживаемые протоколы SSL/TLS 3. Идентифицировать криптографические наборы (cipher suite), поддерживаемые сервером. 4. Проверить поддержку сервером механизма «Sever Name Indication » (SNI) 5. Для идентификации механизма «Secure Renegotiation» выполнить команду 6. Проверить наличие уязвимости к атаке «BEAST». 7. Проверить наличие уязвимости к атаке «Heartbleed» по косвенным признакам. 8. Проверить наличие уязвимости к атаке «CRIME» по косвенным признакам 3 Выполнение работы 1. Выполнить базовые проверки SSL/TLS. Установить последнюю версию пакета OpenSSL. Запустить сетевой анализатор Wireshark. Выполнить тестовое подключение к серверу: # openssl s_client –connect www.habr.com.:443 Рисунок 1 – Подключение к серверу 4 Рисунок 2 – Продолжение Версия протокола SSL/TLS: TLS 1.2 Используемый криптографический набор: ECDHE-RSA-AES123-GCMSHA256 Длина от крытого ключа сервера: 2048bit 5 Рисунок 3 – Взаимодействие с сервером wireshark Далее показан простой пример установления соединения, при котором сервер (но не клиент) проходит аутентификацию по его сертификату. Фаза переговоров: Клиент посылает сообщение ClientHello, указывая последнюю версию поддерживаемого TLS-протокола, случайное число и список поддерживаемых шифронаборов (методов шифрования, англ. cipher suites), подходящих для работы с TLS; Сервер отвечает сообщением ServerHello, содержащим: выбранную сервером версию протокола, случайное число, сгенерированное сервером, выбранный шифронабор из списка, предоставленного клиентом; Сервер посылает сообщение Certificate, которое содержит цифровой сертификат сервера (в зависимости от алгоритма шифрования этот этап может быть пропущен); Если переданных сервером данных недостаточно для выработки общего симметричного секретного ключа в рамках выбранного шифронабора, сервер передаёт сообщение ServerKeyExchange, в котором передаются необходимые данные. Например, в ServerKeyExchange передаётся серверная часть обмена для протокола ДиффиХеллмана; Сервер отсылает сообщение ServerHelloDone, идентифицирующее окончание первого раунда установления соединения; 6 Клиент отвечает сообщением ClientKeyExchange, которое содержит клиентскую часть протокола Диффи-Хеллмана или зашифрованный открытым ключом из сертификата сервера секрет (PreMasterSecret); Клиент и сервер, используя ключ PreMasterSecret и случайно сгенерированные числа, вычисляют общий секрет. Вся остальная информация о сеансовом ключе будет получена из общего секрета; Клиент посылает сообщение ChangeCipherSpec, которое указывает на то, что вся последующая информация будет зашифрована установленным в процессе подтверждения связи алгоритмом, используя общий секретный ключ. Это сообщение уровня записей и поэтому имеет тип 20, а не 22; Клиент посылает сообщение Finished, которое содержит хеш и MAC, сгенерированные на основе предыдущих сообщений процедуры подтверждения связи; Сервер пытается расшифровать Finished-сообщение клиента и проверить хеш и МАС. Если процесс расшифровки или проверки не удаётся, подтверждение связи считается неудавшимся, и соединение должно быть оборвано; Сервер посылает ChangeCipherSpec и зашифрованное сообщение Finished, и в свою очередь клиент тоже выполняет расшифровку и проверку. С этого момента подтверждение связи считается завершённым, протокол установленным. Всё последующее содержимое пакетов идёт с типом 23, а все данные будут зашифрованы. 2. Идентифицировать все поддерживаемые протоколы SSL/TLS, выполнив последовательно команды: # openssl s_client –connect www.ввв.com.:443 – tls1 # openssl s_client –connect www.ввв.com.:443 – tls1_1 # openssl s_client –connect www.ввв.com.:443– tls1_» 7 Рисунок 4 – tls ver. 1 8 Рисунок 5 – tls ver. 1 Версия протокола SSL/TLS: TLS 1 Используемый криптографический набор: ECDHE-RSA-AES128-SHA 9 Рисунок 6 – tls ver. 1 трассировка Wireshark 10 Рисунок 7 – tls ver. 1.1 Версия протокола SSL/TLS: TLS 1.1 Используемый криптографический набор: ECDHE-RSA-AES128-SHA 11 Рисунок 8 – tls ver. 1.1 трассировка Wireshark 12 Рисунок 9 – tls ver. 1.2 Версия протокола SSL/TLS: TLS 1.2 Используемый криптографический набор: ECDHE-RSA-AES128-GCMSHA256 13 Рисунок 10 – tls ver. 1.2 трассировка Wireshark 3. Идентифицировать криптографические наборы (cipher suite), поддерживаемые сервером. Для получения всех поддерживаемых клиентом криптографических наборов выполнить команду: # openssl ciphers –v 14 Рисунок 9 – Криптографические наборы сервера Для проверки поддержки, например, набора AES256-SHA выполнить следующую команду: # openssl s_client –connect www.ввв.com.:443 –cipher AES256-SHA 15 Рисунок 10 – AES256-SHA Проверить поддержку криптографического набора, содержащего шифр RC4: # openssl s_client –connect www.ввв.com.:443 –cipher RC4-SHA Рисунок 11 – Шифр RC4 16 Проверить, что при установке защищенного соединения криптографический набор выбирается в порядке, определяемом настройками сервера, а не клиента. Для этого из списка поддерживаемых сервером криптографических наборов выбрать несколько произвольных и выполнить команды, например: # openssl s_client –connect www.ввв.com.:443 –cipher 'AES256-SHA256,AES128-SHA,DES-CBC-SHA' # openssl s_client –connect www.ввв.com.:443 –cipher 'AES128-SHA256,AES256-SHA,DES-CBC-SHA' # openssl s_client –connect www.ввв.com.:443 –cipher 'DES-CBC-SHA,AES128-SHA,AES256-SHA256' Рисунок 12 – AES256-GCM-SHA384 17 Рисунок 13 – AES128-GCM-SHA256 18 Рисунок 14 – AES128-SHA При корректной настройке во всех случаях должен быть выбран набор AES256-SHA256. Проверить поддержку сервером Forward Secrecy на основе DHE и ECDHE: # openssl s_client –connect www.ввв.com.:443 –cipher 'ECDHE—RSA-AES256-SHA384' # openssl s_client –connect www.ввв.com.:443 –cipher 'DHE—RSA-AES256-SHA256' Совершенная прямая секретность (англ. Perfect forward secrecy, PFS) — свойство некоторых протоколов согласования ключа, которое гарантирует, что сессионные ключи, полученные при помощи набора ключей долговременного пользования, не будут скомпрометированы при компрометации одного из долговременных ключей. Совершенная прямая секретность (PFS) означает, что сеансовый ключ, генерируемый с использованием долговременных ключей, не будет скомпрометирован, если один или несколько из этих долговременных ключей будут скомпрометированы в будущем. Для сохранения совершенной прямой секретности ключ, используемый для шифрования передаваемых данных, не должен использоваться для получения каких-либо дополнительных ключей. 19 Также, если ключ, используемый для шифрования передаваемых данных, был получен (derived) на базе какого-то ещё ключевого материала, этот материал не должен использоваться для получения каких-либо других ключей. Рисунок 15 – ECDHE—RSA-AES256-SHA384 Рисунок 16 – DHE—RSA-AES256-SHA256 4. Проверить поддержку сервером механизма «Sever Name Indication » (SNI): # openssl s_client –connect www.ввв.com.:443 –servername www.ввв.com. «Sever Name Indication » - это недавнее расширение протокола TLS и SSL, позволяющее браузеру указывать, с каким хостом он ищет соединение в начале запроса HTTPS. Основным преимуществом SNI является то, что несколько сертификатов могут быть связаны с одним IP-адресом веб-сервера, тогда как без SNI требуется один отдельный IP-адрес для каждого сайта, защищенного SSL. Как работает SNI? 20 Протокол HTTP поддерживает концепцию виртуального хостинга на основе имен с версии 1.1. В своем первоначальном запросе браузер указывает, к какому имени хоста он стремится подключиться, и это имя хоста читается вебсерверами в заголовках запросов, отправляемых браузером. При просмотре по SSL невозможно прочитать заголовок узла, так как рукопожатие SSL и получение сертификата происходят до того, как данные браузера расшифрованы и сделаны читаемыми. В результате веб-сайты, размещенные на одном и том же IP-адресе, вынуждены использовать один и тот же сертификат SSL или иметь свой собственный IP-адрес каждый, что больше не является приемлемым вариантом при текущем истощении адресов IPv4. SNI является расширением протокола TLS, который отправляет запрошенное имя хоста как часть рукопожатия SSL / TLS. После этого веб-сервер сможет выбрать правильный веб-сайт и представить правильный сертификат браузеру. Рисунок 17 – Sever name 21 Рисунок 18 – Sever name Для определения поддержки сервером механизма «Session Resumption» выполнить команду: # openssl s_client –connect www.google.com.:443 –reconnect 22 Рисунок 14 – Session Resumption Рисунок 15 – Session Resumption Session Resumption кэширование. Когда мы в первый раз подключаемся к серверу, клиент передаёт ID сессии, сохраняющийся на сервере. И когда мы повторно подключаемся к нему, то при совпадении ID сессии уже не требуется выполнять SSL-переговоры, что ускоряет загрузку. 5. Для идентификации механизма «Secure Renegotiation» выполнить команду # openssl s_client –connect www.ввв.com.:443 |grep 'Secure Renegotiation' 23 Рисунок 14 – Secure Renegotiation(поддерживается) 6. Проверить наличие уязвимости к атаке «BEAST». Данная атака использует недостатки блочных шифров, работающих в режиме CBC, и существует во всех версиях протоколов SSL/TLS до версии TLS 1.1. Для того чтобы защититься от атаки BEAST, необходимо использовать шифр RC4 или протокол TLS версии 1.1 и старше. С другой стороны, шифр RC4 в настоящее время считается небезопасным, поэтому его использование нежелательно. Для защиты от атаки BEAST на практике предлагается два подхода: - первый из них носит название «Строгое ослабление» (Strict mitigation) и предполагает использование протокола TLS версии 1.1 и старше со всеми клиентами, которые его поддерживают; - второй подход называется «Приоритезация RC4» (RC4 prioritization) и заключается в повышении приоритета шифра RC4 для клиентов, поддерживающих только протоколы SSL 2.0, SSL 3.0 и TLS 1.0. Таким образом, необходимо убедиться, что клиенты SSL 3.0 или TLS 1.0, не поддерживающие шифр RC4, не смогут установить соединение: # openssl s_client –connect www.ввв.com.:443 –no_tls1_1 –no_tls1_2 –cipher 'ALL:!RC4' Рисунок 15 – Установка соединения не поддерживающие шифр RC4 Или что клиенты, поддерживающие шифр RC4, установят соединение, используя его # openssl s_client –connect www.ввв.com.:443 –no tls –no_tls1_1 –no_tls1_2 – cipher 'ALL:+RC4' 24 Рисунок 15 – Установка соединения поддерживающие шифр RC4 7. Проверить наличие уязвимости к атаке «Heartbleed» по косвенным признакам. Проверить поддержку сервером протокола «Heartbeat» через OpenSSL путем выполнения команды: # openssl s_client –connect www.ввв.com.:443–tlsextdebug 25 Рисунок 15 – Проверка протокола «Heartbeat» Атака реализуется через небольшой модуль Heartbeat расширения TLS библиотеки OpenSSL. TLS — протокол представления данных поверх TCP или UDP, рассчитанный, однако, только на непрерывный поток данных. Если же обмен данными состоит из запросов и ответов, появляется возможность определять какую-то информацию по активности связи, да и после длинного простоя надо будет заново устанавливать TLS-соединение. Чтобы справиться с проблемой, компьютеры «перебрасываются» туда-сюда пакетом случайной длины, и этим поддерживают связь в активном состоянии и «зашумляют» канал[2]. Чтобы сложнее было отличить «сердцебиение» от полезного трафика, пошли на хитрость: пакет состоит из контрольной строки и ничего не значащего «хвоста». Компьютер должен вернуть сообщение, состоящее из такой же строки и своей порции «шума». Длина контрольной строки задаётся 16-битным целым числом[2]. Если эта длина окажется больше, чем весь пакет, уязвимые версии OpenSSL читали память за пределами отведённого буфера (RFC предписывает не отвечать на такие пакеты). За пределами буфера могут встретиться любые данные, в том числе (очень редко) закрытые ключи шифрования сервера, данные других соединений, содержащие идентификационные cookie и многое другое. Heartbleed осуществляется отправкой некорректно сформированного Heartbeatзапроса, в котором реальный размер строки очень мал, а число, символизирующее длину передаваемой строки, очень велико. Так можно получить в ответ от сервера 26 больше всего скрытой информации. Таким образом, у жертвы возможно за один запрос узнать до 64 килобайт памяти, которая была ранее использована OpenSSL. Heartbeat-запрос выглядит так: «Верни мне слово тест, которое состоит из 4 букв», и получает ответ «тест». Heartbleed-запрос выглядит иначе: «Верни мне слово «тест», которое состоит из 500 букв», и получает ответ, состоящий из слова «тест» и еще 496 символов, лежащих у жертвы в активной памяти. Несмотря на то, что злоумышленник имеет некоторый контроль над размером блока памяти, он никак не может управлять положением этого блока, и поэтому единственным способом увеличить вероятность получения ценных данных — многократный повтор эксплуатации ошибки. Рисунок 15 – Проверка протокола «Heartbeat» 27 Рисунок 16 – отсутствие протокола «Heartbeat» wireshark Просмотреть трассировку в Wireshark и определить поддержку расширения «Heartbeat» Если сервер не возвращает в сообщениях данные о расширении «Heartbeat», то он не уязвим к данной атаке. Для того чтобы проверить, отвечает ли сервер на запросы Heartbeat, выполнить команды: # openssl s_client –connect www.ввв.com.:443 –msg 28 Рисунок 17 – Отсутствие протокола «Heartbeat» Рисунок 17 – Отсутствие протокола «Heartbeat» 29 8. Проверить наличие уязвимости к атаке «CRIME» по косвенным признакам. Данная атака основана на сжатии данных на уровне SSL/TLS. Для проверки достаточно выполнить команду: # openssl s_client –connect www.ввв.com.:443 –reconnect | grep 'Compression' Рисунок 18 – отсутствие уязвимости «CRIME» Используемая уязвимость представляет собой комбинацию выбранной атаки открытого текста и непреднамеренной утечки информации посредством сжатия данных, аналогичного описанному в 2002 году криптографом Джоном Келси . [3] Он полагается на то, что злоумышленник может наблюдать за размером зашифрованного текста, отправляемого браузером.в то же время побуждая браузер создавать несколько тщательно созданных веб-соединений с целевым сайтом. Затем злоумышленник наблюдает за изменением размера полезной нагрузки сжатого запроса, который содержит как секретный файл cookie, отправляемый браузером только целевому сайту, так и переменное содержимое, созданное злоумышленником, при изменении содержимого переменной. Когда размер сжатого содержимого уменьшается, можно сделать вывод, что существует вероятность того, что некоторая часть введенного содержимого соответствует некоторой части источника, которая включает в себя секретный контент, который злоумышленник желает обнаружить. Методы « разделяй и властвуй» могут затем использоваться для выявления истинного секретного контента в сравнительно небольшом количестве попыток проверки, которое кратно числу секретных байтов, которые необходимо восстановить.[1] [4] Эксплуатация CRIME была выдвинута Адамом Лэнгли [5] и впервые продемонстрирована исследователями безопасности Хулиано Риццо и Тай Дуонг, которые также создали эксплойт BEAST . [6] Эксплойт должен был быть полностью раскрыт на конференции по безопасности экопарти в 2012 году . [7] Риццо и Дуонг представили CRIME как общую атаку, которая эффективно работает против большого количества протоколов, включая, помимо прочего, SPDY (который всегда сжимает заголовки запроса), TLS (который может сжимать записи) и HTTP (который может сжимать ответы ). Профилактика [ править ] 30 CRIME может быть побежден путем предотвращения использования сжатия либо на стороне клиента, либо браузером, отключающим сжатие запросов SPDY, либо веб-сайтом, который запрещает использование сжатия данных для таких транзакций с использованием функций согласования протокола TLS. Как подробно описано в Протоколе безопасности транспортного уровня (TLS) версии 1.2 , [8], клиент отправляет список алгоритмов сжатия в своем сообщении ClientHello, а сервер выбирает один из них и отправляет его обратно в своем сообщении ServerHello. Сервер может выбрать только метод сжатия, предложенный клиентом, поэтому, если клиент предлагает только «нет» (без сжатия), данные не будут сжаты. Точно так же, поскольку все TLS-клиенты должны разрешать 'без сжатия', сервер всегда может отказаться от использования сжатия. 31 Заключение Появление серьёзных атак на протокол SSL/TLS свидетельствует о наличии проблем архитектуры протокола, слабостей используемых протоколом криптографических алгоритмов и ошибок в его реализации. Атаки осуществляются как на отдельные TLS сеансы, так и на TLS серверы, нанося при этом огромный моральный и материальный ущерб пользователям и организациям. Это обуславливает необходимость разработки методики тестирования безопасности протокола TLS и программного средства формирования и автоматического применения защищенных конфигураций протокола для клиентов и серверов. Проведенный анализ безопасности протокола SSL/TLS позволил выявить слабые конфигурационные параметры протокола, такие как устаревшие версии протокола, нестойкие совокупности крипто алгоритмов и небезопасные расширения. Проведенное исследование уязвимостей протокола TLS позволило определить небезопасные версии клиентского и серверного ПО, реализующего протокол. 32 Список литературы 1. Kent, IP Authentication Header // URL: https://tools.ietf.org/html/rfc4302 (дата обращения 10.04.19) 2. THC-SSL-DOS эксплойт // URL: https://www.thc.org/thcssl-dos/ (дата обращения 11.04.19) 3. ЗАО Позитив Текнолоджис. В. Кочетков. Как разработать защищенное веб-приложение и не сойти при этом с ума». // URL: https://www.leaderssl.ru/articles/207-vse-pro-openssl-za-5-minut (дата обращения 11.04.19) 33
