Как мы реализовали HTTPS на главной странице портала Mail.Ru
Парадоксально: HTTPS существует уже много лет, но за все эти годы не стал стандартом по умолчанию для всех интернет-ресурсов, работающих с критичными с точки зрения безопасности данными. В прошлом году мы первыми среди крупных российских порталов включили HTTPS на главной странице.Теперь шифрование работает с первых шагов пользователя на портале Mail.Ru, а также включено всегда и по умолчанию. На наш взгляд, это просто must-have, ведь именно на главной странице находится форма ввода логина и пароля от почты. Хотя передача пользовательских данных при авторизации уже много лет происходит по HTTPS, но если главная страница загружается по HTTP, то на этапе ввода данных есть возможность перехватить их в ходе атаки SSLstrip, которая довольно популярна среди киберпреступников. Напомню, в чем её суть, взяв для примера несуществующий сайт example.com:
Допустим, пользователь заходит в интернет через публичный Wi-Fi и пишет в браузере example.com; Запрос уходит на серверы example.com, на которых формируется ответ. Он содержит в том числе ссылку на URL, где происходит авторизация (https://auth.example.com); Злоумышленник перехватывает ответ и меняет этот URL на любой другой (https://some-fraudlent-server.com). Без HTTPS хакер может не только «слушать» трафик, но и посылать клиенту поддельные данные от имени сервера; Злоумышленник передает поддельную страницу в браузер пользователя, который её отображает. Она выглядит абсолютно так же, как обычная страница; Ничего не подозревающий пользователь вводит там свои логин и пароль, затем нажимает «Войти»; Браузер переводит пользователя на действие формы авторизации. Если бы не действия злоумышленника, он бы перевёл его на httрs://auth.example.com, но из-за того что произошла подмена URL, браузер переведёт его на свою страницу httр://some-fraudlent-server.com, отослав туда логин и пароль пользователя. Сейчас, даже если пользователь окажется очень изобретательным (например, он сохранил в закладках http-адрес страницы — httр://mail.ru/ и попытается зайти на главную страницу по этой ссылке), а злоумышленник — очень настойчивым, — так вот, даже в этом случае данные пользователя будут защищены благодаря технологии Strict Transport Security. Это механизм, активирующий форсированное защищённое соединение через HTTPS. Он поддерживается большинством современных браузеров. Вот почему для нас было так важно реализовать HTTPS на главной странице.
Таким образом, переход на HTTPS защищает, во-первых, от прослушивания трафика и, во-вторых, от того, что код страницы может модифицировать MiTM. Им может оказаться как злоумышленник, так и, например, провайдер публичного Wi-Fi, который хочет показывать пользователю собственную баннерную рекламу. Такие баннеры могут перекрывать часть полезного контента, например, элементы навигации, — разумеется, это не всегда нравится пользователям. Кстати, теоретически провайдер с тем же успехом может внедрять и вредоносный контент, перехватывая пользовательские данные.
А теперь о том, как мы внедряли HTTPS на главной странице одного из самых крупных и посещаемых порталов рунета и с какими сложностями нам пришлось столкнуться.
Перевод контента на HTTPSПервым делом нужно было перевести на https весь отображаемый на главной странице контент. Большую часть информации мы получаем от других сервисов Mail.Ru (Новости, Погода и так далее). Некоторые из них еще не перешли на HTTPS. Но контент, а именно картинки, забираемые с других сервисов, физически перекладываются на наши сервера, поэтому проблемы с тем, чтобы получать их по HTTPS, или с возможным ростом нагрузки на эти сервисы не возникло.Сложнее было с общей баннерной системой, которая работает на портале Mail.Ru, так как в ней присутствует и внешний контент от партнёров. Это пиксели (прозрачные картинки размером 1×1 пиксель), которые дергаются для подсчёта статистики, когда демонстрируется баннер партнера. Еще когда мы внедряли HTTPS на Почте, мы сделали две вещи: во-первых, договорились с партнерами, чтобы они также перешли на HTTPS и, во-вторых, сделали так, чтобы показ баннеров с небезопасным контентом был технически запрещен на стороне нашей баннерной системы. Переводя на HTTPS главную страницу, мы использовали эти решения.
Еще один пример партнерского контента — это аудиторные счетчики. Если вы будете переходить на HTTPS, рекомендуем обязательно проверить весь такой контент на совместимость с безопасным протоколом.
Перед включением HTTPS на живых пользователей мы принудительно перевели на него сотрудников Mail.Ru Group. Это не могло дать какой-либо заметной нагрузки, но зато позволило ещё раз убедиться в том, что весь контент страницы загружается по безопасному протоколу.
Включение HTTPS на живых Главная проблема, к которой мы готовились: переход на HTTPS существенно повышает нагрузку на сервера. Помимо этого, он увеличивает общее время загрузки страницы за счёт увеличения времени соединения с сервером и времени на загрузку скриптов и статики. Таким образом, главные задачи, которые мы решали, — это, во-первых, постараться запуститься на текущем количестве «железа» и, во-вторых, по минимуму просесть в скорости загрузки страницы.Мы решили сделать проверку боем и включили HTTPS для части пользователей, померив, насколько вырастет нагрузка на железо. В течение нескольких дней мы постепенно увеличивали долю HTTPS и следили за графиками — CPU на сервере, временем загрузки страницы по блокам и аудиторными показателями (хитами и переходами на проекты с главной). Тут нужно заметить, что для главной страницы мы считаем необходимым держать многократный запас по нагрузке. Однако тестовый запуск показал, что этого запаса не будет при запуске HTTPS на 100% пользователей. И тогда настало время для оптимизации.
Во-первых, мы включили keep-alive, благодаря которому на установку повторного соединения с сервером не требуется времени. Поскольку главная страница Mail.Ru обращается к серверу за обновлениями информации по текущему пользователю раз в минуту, мы используем установленное соединение для ее обновления. Благодаря этому keep-alive позволил снизить количество устанавливаемых соединений. Как следствие, снизилась нагрузка и примерно на 30% уменьшилось среднее время ожидания ответа от сервера.
Во-вторых, мы сократили на треть количество запросов за обновлением пользовательских данных. Главная страница делает порядка 900 тысяч таких запросов в минуту. Однако в случае если пользователь был и остался неавторизован, то ровным счетом ничего нового мы не узнаем, сколько сервер ни пытай (это сродни тому, чтобы заглядывать в холодильник каждые пару минут, проверяя, не появилось ли там чего-то новенького). В результате мы стали обращаться за обновлениями пользовательских данных только тогда, когда предполагаем, что эти данные могли обновиться — когда пользователь авторизован или авторизация изменилась. Эти изменения позволили снизить нагрузку до приемлемого уровня и включить HTTPS на всех пользователей, обойдясь без добавления дополнительных серверов.
При включении HTTPS «на всех» мы следили за изменением аудиторных показателей, поскольку оно могло указать на какие-то проблемы с загрузкой страницы в нестандартных браузерах или ОС, если бы пользователи столкнулись с ними.
Был интересный момент: мы заметили рост количества показов мобильной версии главной страницы сразу после включения HTTPS. Этот рост, конечно, вызвал опасения. Оказалось, что при HTTPS происходит полная перезагрузка страницы, если пользователь возвращается на неё, нажав back в браузере. А пользователи возвращаются на главную таким образом часто — ссылки с мобильной версии главной открываются в том же окне, в отличие от большой версии. При HTTP страница в мобильных браузерах часто показывается из кеша (поведение зависит от OS и браузера). Поэтому количество засчитанных показов главной и выросло. Чтобы проверить эту гипотезу, мы построили график перезагрузок страниц по кнопке back (для некоторых браузеров), и он её подтвердил.
Итак, мы успешно перевели главную страницу нашего портала. Кроме того, мы внедрили HTTPS на наших контентных проектах, где хранится не так много пользовательских данных по сравнению, например, с Почтой, но присутствует форма авторизации. Сейчас безопасный протокол включен на Новостях, Авто, Cars, Hi-Tech, Погоде, Здоровье и Детях Mail.Ru, и в дальнейшем этот список продолжит расширяться (в одном из следующих постов расскажем, как их переход на HTTPS влияет на трафик с поисковых машин).
Мы надеемся, что наш пример вдохновит коллег, и за HTTPS постепенно окажутся все главные страницы более или менее крупных ресурсов. Защитим данные пользователей от SSLstrip-атак!
