Время чтения: 18 мин.

Перевод на русский язык статьи Криса Палмера и Яна Жу с сайта EFF.
Creative Commons Attribution License
Распространяется по лицензии Creative Commons Attribution License.
Оригинальная статья: How to Deploy HTTPS Correctly

Интернет-технологам всегда было известно, что HTTP небезопасен и приводит к множеству рисков для пользователей. HTTP-трафик не зашифрован, поэтому любые данные, передаваемые по HTTP могут прочитаны и изменены кем угодно, у кого есть доступ к сети. Как стало известно из документов Сноудена об электронном шпионаже АНБ, HTTP-трафик также может собираться и изучаться правительственными агенствами без уведомления пользователей или веб-мастеров. Имея в виду данные риски, EFF считает, что каждый сайт должен включить HTTPS на всех страницах как можно быстрее.

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

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

Основные сведения

HTTPS дает три гарантии безопасности:

  • Аутентификация сервера дает пользователям некоторую уверенность, что они общаются с настоящим сервером приложения. Без этой гарантии нельзя гарантировать конфиденциальность и целостность.

  • Конфиденциальность данных означает, что перехватчик сообщений не может понять содержимое сообщений между браузером пользователя и веб-сервером, потому что данные зашифрованы.

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

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

Способы атаки и защиты

Однако пользователи выходят в интернет, и существует множество людей, кто может атаковать их — подглядывая за ними, выдавая себя за них, манипулируя с их сообщениями, или все вместе. администратор сети Wi-Fi может делать это; любой интернет-провайдер по пути от клиента до сервера может делать это; любой, кто может перенастроить Wi-Fi или другой маршрутизатор может делать это; и часто, любой, кто пользуется той же сетью может тоже это делать.

Firesheep – пример пассивной сетевой атаки: оно подслушивает трафик сетевого обмена между браузером и сервером, но не перенаправляет или модифицирует его. Правительственные программы электронного шпионажа вроде XKeyscore, также осуществляют пассивную атаку на HTTP-трафик, собирая огромные массивы данных онлайн-коммуникации.

Но в свободном доступе есть и другие утилиты для выполнения активных сетевых атак, где атакующий может модифицировать содержимое сообщений и/или перенаправлять их. Эти утилиты разнятся от серьезных, вроде sslstrip, до шуточных, вроде Upside-Down-Ternet. Хотя Upside-Down-Ternet и веселый розыгрыш, технически оно равно потенциально более опасным атакам, таким как инъекция вредоносного кода или неправильной информации в веб-страницы; в то же время оно демонстрирует, что такие атаки достаточно просты, чтобы быть шутками. Многие бесплатные Wi-Fi-точки известны тем, что динамически включают рекламу в страницы, просматриваемые пользователем, означая, что активные сетевые атаки являются жизнеспособной бизнес-моделью. Утилиты вроде Cain and Abel дают возможности для осуществления широкого спектра атак, включая перенаправление локального сетевого трафика через систему злоумышленника. (См. также Arpspoof и dsniff).

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

Однако, существует несколько потенциальных подводных камней, которые веб-мастера должны избежать, чтобы безопасно развернуть HTTPS.

Смешанное содержимое

При работе веб-приложения через HTTPS не должно быть смешанного содержимого; да, все содержимое на странице должно загружаться через HTTPS. Часто можно увидеть частичную поддержку HTTPS на сайтах, где основные страницы загружаются по HTTPS, но некоторые или все медиа-элементы, таблицы стилей и JavaScript на странице загружаются по HTTP.

Это небезопасно, поскольку, хотя и загрузка страниц защищена от активных и пассивных атак, не защищен ни один из этих ресурсов. Если страница загружает некоторый код JavaScript или CSS по HTTP, атакующий может подменить этот код вредоносным и получить контроль над DOM страницы после ее загрузки. При этом пользователь возвращается к ситуации отсутствия безопасности. Это основная причина, по которой все основные браузеры предупреждают пользователей о страницах, которые загружают смешанное содержимое. Небезопасно и ссылаться на изображения по HTTP: что если в приложении веб-почты атакующий поменял местами иконки «Сохранить сообщение» и «Удалить сообщение»?

Веб-приложение полностью должно работать по HTTPS. Перенаправляйте HTTP-запросы кодами 301 или 302 на эквивалентный ресурс, доступный по HTTPS.

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

К сожалению, множество сайтов сегодня загружает содержимое с внешних сайтов и CDN, не поддерживающих HTTPS. Если невозможно загружать данные ресурсы со своего собственного домена, вы должны поторопить эти сайты, чтобы они немедленно начали поддерживать HTTPS.

Безопасность и куки

Как было описано Крисом Палмером в работе о безопасном управлении сессиями для веб-приложений, веб-мастера обязаны ограничивать область кук (особенно используемых для аутентификации) безопасным источником. Если область куки слишком широкая (с атрибутом Domain в заголовке Set-Cookie:), она может «протекать» на другие хосты или приложения в том же домене, потенциально менее защищенные хосты или приложения.

Также, приложение должно указывать атрибут Secure при установке куки. Данный атрибут указывает браузеру, что посылать куку можно только через защищенное (HTTPS) соединение, никогда через незащищенное (HTTP).

Используйте HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) — расширение протокола HTTP, которое позволяет сайту указать браузеру ожидать, что сайт использует HTTPS.

Несмотря на то, что не все браузеры пока еще поддерживают HSTS, EFF призывает поторопиться тех, кто еще нет — в особенности мы смотрим на вас, Apple и Microsoft — последовать примеру Google, Opera и Mozilla, и добавить данный механизм безопасности. Да, в конечном итоге мы ожидаем, что HTTPS (и, возможно, более новые протоколы, вроде SPDY и QUIC) полностью вытеснит HTTP, так же как SSH вытеснил Telnet и rsh.

В качестве дополнительной меры безопасности ваш сайт должен поддерживать предзагрузку HSTS, которая предотвращает перехват HTTP-запроса, если браузер еше не получил от сервера действительный заголовок HSTS. Предзагрузка HSTS реализована в виде добровольного списка доменов, который включен в Chromium, Google Chrome и Firefox. Посетите страницу Chromium, где описаны инструкции по включению вашего сайта в данный список. Обратите внимание, что вы также должны посылать заголовок HSTS с max-age большим, чем 18 недель, чтобы Firefox внес вас в их список предзагрузки HSTS.

Недавно мы включили HSTS и предзагрузку HSTS для eff.org. Это заняло меньше часа, и мы нашли способ сделать это без принудительного перенаправления пользователей на HTTPS, таким образом мы можем однозначно указывать на предпочтение доступа по HTTPS, тем временем по-прежнему предоставлять доступ по HTTP. Это работает замечательно, и теперь значительная часть наших пользователей автоматически заходит на наш сайт по HTTPS, скорее всего, даже не подозревая об этом.

Выбирайте стойкие протоколы и алгоритмы

Краткий список рекомендаций по выбору протоколов и алгоритмов шифрования при развертывании SSL:

  • Выключите поддержку SSLv2, SSLv3 и TLS 1.0.

  • Поддерживайте TLS 1.1 и 1.2.

  • Не используйте наборы алгоритмов NULL, aNULL и eNULL, так как они не позволяют одновременно шифрование и аутентификацию.

  • Используйте стойкие приватные ключи, по крайней мере, как 2048-битный RSA-ключ.

  • Отдайте предпочтение наборам алгоритмов, включающих обмен временными ключами Диффи—Хеллмана. Это позволяет получить важное свойство Perfect Forward Secrecy, которое предотвращает расшифровку старого веб-трафика, если ваш приватный SSL-ключ будет скомпрометирован в будущем.

  • Не используйте наборы алгоритмов с ключами для шифрования короче 128 бит.

  • Не используйте наборы алгоритмов, которые используют MD5 для хеширования. SHA-1 также не рекомендуется, но может быть необходим для совместимости с TLS 1.0 и SSLv3.

  • Не используйте наборы алгоритмов, использующие RC4 для шифрования. AES-CBC предпочтительнее RC4, но уязвим для атаки BEAST. Таким образом, чаще рекомендуется AES-GCM.

  • Отключите сжатие TLS, чтобы предовтратить атаку CRIME.

  • Поддерживайте только безопасные переустановки (renegotiation) соединения TLS, в соответсвии с RFC 5746, или отключите их полностью.

  • Qualys's SSL Server Test - полезное средство для проверки хорошо известных слабых мест в существующей конфигурации HTTPS.

Вопросы о производительности

Многие веб-мастера утверждают, что не могут перейти на HTTPS из-за вопросов с производительностью. Однако, большинство из тех, кто говорит такое, на самом деле не замеряли потерь в производительности, и могли вообще не замерять производительность, не профилировали и не оптимизировали поведение их сайта. Обычно сайты имеют задержки куда более высокие и/или пропускную способность более низкую, чем необходимо, даже при хостинге HTTP, показывая, что HTTPS не является проблемой.

Корень проблемы с производительностью часто лежит на уровне контента и довольно часто на уровне базы данных. Веб-приложения по природе своей очень зависят от I/O, в конце концов. Примите во внимание следующие разумные выводы команды разработчиков Gmail:

Сначала мы составили список всех транзакций между браузером и серверами Google, начиная с того момента, как нажата кнопка «Войти». Для этого мы использовали множество различных утилит для разработчиков, вроде Httpwatch, WireShark и Fiddler, а также наши собственные системы измерения производительности. [...]

Мы провели часы в тщательном изучении этих следов, чтобы понять, что именно проиходит между браузером и Gmail во время входа, и мы обнаружили, что небходимо от 14 до 24 HTTP-запросов, чтобы загрузить и отобразить «Входящие». Для сравнения, новостному сайту популярной сети требовалось выполнить около 180 запросов, чтобы полностью загрузиться, когда я проверял вчера. Но когда мы изучили наши запросы, мы поняли, что можем улучшить это. Мы решили атаковать проблему с нескольких сторон сразу: уменьшить общее количество запросов, сделать больше запросов кешируемыми браузером, и уменьшить затраты на каждый запрос.

Мы преуспели в каждом направлении. Мы уменьшили вес каждого запроса, избавившись или уменьшив область некоторых кук. Мы убедились, что все наши изображения кешируются браузером, и мы собрали маленькие изображения иконок к одно мета-изображение, которое называют спрайтом. Мы совместили несколько отдельных запросов в единственный запрос и ответ. В результате сейчас требуется выполнить всего 4 запроса от нажатия кнопки «Войти» до отображения вашего ящика.

Адам Лэнгли из Google делится дополнительными подробностями:

Чтобы сделать это нам не потребовалось дополнительных машин и никакого специального оборудования. На серверах нашего продакшн-фронтэнда, SSL/TLS отвечает менее чем за 1% нагрузки на CPU, менее чем за 10 КБ памяти на соединение и менее чем за 2% служебного сетевого трафика. Многие люди думают, что SSL требует много процессорного времени, и мы надеемся, что данные цифры (впервые опубликованные) помогут развеять данный миф.

Что удивительного в том, что Gmail прекрасно работает, при этом используя исключительно HTTPS? Веб-мастера могут заметить постепенные улучшения, шаг за шагом улучшая свои веб-приложения. Крис выступал с докладом об этом эффекте на Web 2.0 Expo 2009.

Заключение

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

QR Code
Темы заметок
access_time share