Снятие SSL: Основы и варианты защиты

Протокол передачи данных Secure Sockets Layer (SSL) и его преемник, Transport Layer Security (TLS), являются одними из самых важных компонентов для безопасного присутствия в Интернете. Они шифруют информацию, которой обмениваются браузер и сервер по протоколу HTTP, перед отправкой информации — даже при переключении между зашифрованной HTTPS и незащищенной страницей. Это не только предотвращает стандартную передачу данных в открытом виде, но и предотвращает отправку cookie, установленных по протоколу SSL, при незашифрованном соединении. Эти полезные сертификаты SSL и TLS также гарантируют подлинность имени хоста сервера для запрашивающего клиента. Протокол TLS обеспечивает безопасность множеством способов, что делает его незаменимым при передаче конфиденциальной информации.

TLS вообще является одним из самых безопасных протоколов и до сих пор хорошо справлялся с попытками атак. Однако при определенных обстоятельствах специальные инструменты (например, sslstrip, запрограммированный для демонстрационных целей) способны получить доступ к передаче данных еще до начала шифрования. Такой тип несанкционированного доступа третьих лиц называется SSL stripping.

Еще в 2002 году разработчик Мокси Марлинспайк использовал sslsniff для программирования инструмента, который мог устранить SSL-шифрование. Прокси-программа позволяла проникать в потоки данных SSL и заменять сертификат сервера любым собственным сертификатом. Марлинспайк хотел использовать приложение, чтобы показать слабые места Internet Explorer, который на момент публикации был уязвим для атак типа «человек посередине».

Microsoft удалось устранить уязвимость, и другие популярные клиенты широко защищены от такого рода атак, при условии, что они имеют самую современную версию и правильную конфигурацию.

Марлинспайк представил программу sslstrip в 2009 году в рамках конференции по безопасности Black Hat DC. Как и его предыдущий инструмент, sslstrip представляет собой прокси-сервер, который располагается между клиентом и сервером и пытается обойти сертификацию на страницах браузера. Для этого инструмент ищет на веб-страницах, предоставляемых веб-серверами, встроенные ссылки и перенаправления, которые он перенаправляет на защищенную SSL страницу входа в систему, например, на следующую ссылку:

Если прокси находит такую ссылку, он модифицирует ее в эквивалентную HTTP-ссылку. Пользователь отправляет регистрацию через свой браузер, а не якобы зашифрованные обычные данные в открытом тексте. Потенциальный хакер может легко прочитать через sslstrip как промежуточную станцию и добраться до конфиденциальной информации. Поскольку SSL-стриппинг не создает недействительного соединения, никаких предупреждающих сообщений не выводится. Как правило, пользователь не получает предупреждения о том, что передаваемая им информация является незашифрованной.

Независимо от того, используется ли sslstrip или другое аналогично запрограммированное приложение, первое, что делает злоумышленник, это переключает прокси между браузером и веб-сервером. Программа также имеет возможность кодировать измененные URL с помощью SSL stripping, но только если она может перехватывать или пересылать потоки данных. В реализации распространены следующие три метода:

1. Неправильный ввод прокси в опциях браузера: Когда ваша система становится мишенью, целью часто является только браузер, а не весь компьютер. Тогда вредоносное ПО обеспечивает автоматический ввод внешнего прокси-сервера в настройки без ведома пользователя.
2. ARP или NDP Spoofing: В пределах подсети злоумышленник может прибегнуть к ARP-спуфингу (IPv4) или NDP-спуфингу (IPv6), чтобы задействовать свой прокси-сервер. Целью обоих протоколов является преобразование IP-адресов в соответствующие аппаратные адреса (также известные как MAC-адреса). Используя манипулированные сообщения этих протоколов, злоумышленник может заменить запрашиваемые аппаратные адреса на свой собственный системный адрес, а затем перехватить передаваемые пакеты данных.
3. Предоставление собственной точки доступа: Третий вариант заключается в том, что устройство, на котором работает прокси-сервер, может также выступать в качестве маршрутизатора. Будучи стандартным шлюзом, включая DHCP-сервер, он может назначать IP-адреса пользователям, а также читать и пересылать пакеты, которые отправляются за пределы подсети. Это обеспечивает идеальную основу для SSL-стриминга.

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

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

Однако уже довольно давно адресные строки браузеров дают подсказки различными способами: В старых версиях Microsoft Internet Explorer для идентификации сайтов с защищенным соединением адресная строка была полностью зеленой. Другие браузеры просто подсвечивали прежнее название компании, пока этот тип идентификации — распространенный с первыми мобильными устройствами с поддержкой Интернета — не был заменен на привычные сегодня символы, такие как типичный замок безопасности. Однако эти визуальные подсказки не всегда гарантируют, что посещаемый сайт не был скомпрометирован такими инструментами, как sslstrip. Поскольку злоумышленник контролирует всю передачу данных, он может поставить символ, похожий на favicon, чтобы довести свой обман до совершенства.

Сложность обнаружения вредоносных страниц делает атаки SSL stripping столь опасными для пользователей: сертификаты шифрования, которые должен использовать каждый внимательный оператор сайта, означают безопасность и надежность, и они не дают посетителям повода для беспокойства о раскрытии конфиденциальной информации. В принципе, SSL обеспечивает необходимую защиту, поскольку возможность чтения и перехвата пакетов данных возникает не из-за бреши в протоколе, а из-за того, что само шифрование предотвращено. Для защиты от SSL-полосок каждый пользователь должен принудительно строить зашифрованные HTTPS-соединения. Способы сделать это можно увидеть в следующих примерах:

1. Ввести URL вручную: Громоздкая, но эффективная мера — ввод URL HTTPS в браузере.
2. Расширение браузера: Существует несколько расширений браузера, которые могут помочь вам получить доступ к зашифрованным версиям, если они существуют. Например, расширение HTTPS Everywhere использует списки доменов и правил для обработки любых вызовов страниц через HTTPS-соединения. Версии для Firefox, Android, Chrome и Opera можно найти на сайте Electronic Frontier Foundation, который разрабатывает и поддерживает расширение вместе с проектом Tor.
3. Сохраняйте защищенные URL в закладках: Если вы обычно пользуетесь защищенными SSL веб-сервисами (онлайн-банкинг, облачное хранилище и т.д.), вы можете сохранить HTTPS-версию в закладках и всегда обращаться к ней таким образом. Условием для этого является то, что при создании закладки вы находитесь в защищенной сети, иначе вы можете добавить уже измененный URL в список избранного.

Вы также можете бороться со снятием SSL в качестве оператора веб-проекта. Например, основным шагом может быть включение шифрования для всех текущих страниц и принуждение входящих HTTP-соединений защищать свои страницы. То же самое относится и к файлам cookie: Если вы не хотите использовать практические записи данных для веб-анализа, убедитесь, что они не отправляются обратно через незащищенные HTTP-соединения. Для этого просто записывайте куки с атрибутом ‘secure’, убедившись, что ваш сервер получает обратную связь только через HTTPS. Еще одной мерой безопасности является стандарт IETF HSTS, который более подробно описан в следующем разделе.

Через три года после того, как Марлинспайк указал на уязвимость SSL-сертифицированных веб-сайтов с помощью своего программного обеспечения sslstrip, IETF (Internet Engineering Task Force) в RFC 6797 определила механизм безопасности HSTS (http Strict Transport Security). Это позволяет веб-серверам предупреждать клиентов, устанавливающих соединение, о том, что они получают доступ к веб-сайту исключительно через HTTPS-соединение в течение определенного периода времени. Для этого сервер использует поле ‘Strict Transport Security’ в обычном заголовке ответа HTTP, а также директиву ‘max age’, которая определяет период действия заявления в секундах. Чтобы защитить домен и сделать его доступным только по зашифрованному соединению в течение одного года, http-ответ веб-сервера должен содержать что-то вроде следующей строки:

Параметр ‘includeSubDomains’ можно использовать для распространения команды на все поддомены сайта, чтобы обеспечить принудительное использование SSL/TLS. Если браузер получает сообщение от контрактного веб-сервера с утверждением ‘Strict Transport Security’, все незашифрованные запросы автоматически преобразуются в зашифрованные при последующих соединениях с соответствующими доменами. Если соединение не является безопасным, отображается сообщение об ошибке и запрашиваемая страница не вызывается.

HSTS — это постоянное решение для защиты веб-сайта и потенциальных посетителей от SSL-стримов и подобных атак. Однако, как уже говорилось ранее, всегда существует самая первая структура соединения, которой можно манипулировать до того, как защитный механизм сможет вмешаться. Чтобы противостоять этой проблеме, компания Google ввела для своего браузера Chrome список предварительной загрузки, содержащий веб-проекты, доступные только через HTTPS. Другие производители браузеров приняли этот принцип и внедрили списки предварительной загрузки HSTS на основе списка Chrome. Чтобы добавить свой сайт в список, вы можете отправить запрос на страницу проекта, созданную Google.