В сентябре Почта Mail.Ru включила HTTPS-шифрование для всех пользователей.
Преимущества безопасного соединения очевидны всем разработчикам крупных интернет-проектов.
Большинство современных веб-серверов (nginx, Apache и т. д.) и браузеров поддерживают HTTPS. В то же время не так уж много сайтов, где безопасный протокол всегда включен по умолчанию.
Почему это так? С какими проблемами мы столкнулись при поддержке HTTPS? Читайте под катом.
Особенности SSL на высоконагруженных системах По сути, HTTPS — это обычный протокол HTTP поверх сетевого уровня SSL, который позволяет сделать незащищенный сетевой канал безопасным посредством шифрования.
Что нужно сделать для поддержки SSL? Казалось бы, все, что вам нужно сделать, это заказать сертификат, раздать его по серверам, включить опцию в nginx и добро пожаловать в мир защищенного трафика.
Но на самом деле все не так просто.
Вернее, не так: все было бы просто, если бы нам по какой-то причине нужно было закрепить статическую страницу с текстом «Hello world».
А вот для высоконагруженной системы с большим количеством разнообразного контента, такой как Почта Mail.Ru, все самое интересное начинается сразу после того, как сертификаты уже куплены и распространены.
Чем отличается Почта Mail.Ru от гипотетической страницы «Привет, мир»? По сути, с точки зрения поддержки HTTPS есть два основных различия.
Во-первых, Почта содержит много страниц — десятки: список писем, сами письма, настройки, адресная книга и т. д., причем на каждой странице сотни элементов (картинки, JS-ники, CSS и т. д.).
Во-вторых, Почта работает с огромной нагрузкой, обрабатывая сотни тысяч HTTP-запросов в секунду (включая, конечно же, статические запросы).
Именно из-за этих двух аспектов реализация поддержки HTTPS была такой сложной.
Как эти аспекты влияют на поддержку? Первый аспект дает следующий эффект: когда страница всего одна, на сервере есть сертификат, браузер его понимает, все работает. Проблемы начинаются, когда страниц много и тем более, когда на этих страницах есть внешние элементы, выполняющиеся в контексте этой страницы.
Браузер считает соединение безопасным только в том случае, если каждый последний элемент на странице был обработан по защищенному протоколу: это относится ко всем изображениям, JS, CSS и т. д. Если хотя бы один элемент был отправлен по незащищенному протоколу, браузер будет считать всю страницу небезопасной и сообщать об этом пользователю.
Вторая проблема, которую создает высокая загруженность Почты, заключается в том, что шифрование и дешифрование — достаточно затратные операции, как с точки зрения процессора, так и с точки зрения памяти.
Процессорное время тратится на шифрование и дешифрование.
Память тратится на SSL-кеш, увеличение буферов Nginx и большое количество рабочих веб-серверов, которые дольше висят в памяти из-за длительной обработки запросов.
SSL — зверь, который съест много «камня» и памяти и не подавится этим.
Как с этим справиться? Баннерная система Почта — неоднородная конструкция.
У нас есть собственная баннерная система.
Это не просто почтовая система, а общая баннерная система портала Mail.Ru, который о HTTPS ничего не слышал.
Учитывая, что нам пришлось обслуживать все данные со всех страниц через HTTPS, баннерную систему пришлось существенно доработать.
Помимо того, что мы научили веб-серверы обслуживать все баннеры, скрипты и статический контент по HTTPS, нам пришлось разобраться с партнерскими пикселями.
Пиксель — это картинка размером 1х1, которую предоставляет партнер и которая дергается при показе баннера.
Стоит отметить, что не все наши партнеры работают по HTTPS, и, как я уже отмечал, на странице не должно быть небезопасных элементов, даже если они имеют размер 1х1 пиксель.
Конечно, можно было пропустить все пиксели через прокси, но мы сначала пошли по более простому пути.
Мы договорились с нашими партнерами, объяснили им, насколько это прекрасно и нужно, и теперь они поставляют нам HTTPS-пиксели.
Это была, конечно, непростая задача, но она сработала.
Правда, теперь необходимо научить новых партнеров тому, что ссылка на картинку должна быть безопасной.
Есть еще одна проблема с баннерами: их могут вводить не только технические специалисты, но и другие сотрудники с разным уровнем компьютерной грамотности.
Соответственно, существует вероятность того, что вместе с баннером на странице могут появиться не-SSL-изображения, JS и небезопасные счетчики.
Чтобы решить эту проблему, мы прошлись по всем баннерам один раз и заменили все небезопасные на безопасные.
Однако это не гарантирует, что в будущем ничего не изменится.
Поэтому мы усовершенствовали баннерную систему: создали бит SSL-ready, который присваивается каждому проекту.
Пока он установлен только на почте.
Наличие этого бита указывает на то, что в этом проекте не будут отображаться баннеры, содержащие небезопасный контент. Все баннеры, которые отображались в Mail, также получили бит готовности к SSL. А наша система для таких баннеров запрещает менять безопасный контент на небезопасный или добавлять небезопасный контент на уровне ввода в админку.
Это полностью исключило человеческий фактор при редактировании баннера: если кто-то создаст новый баннер с небезопасным содержимым, он не сможет показать его в Mail, поскольку не сможет пометить его как безопасный.
А если человек поменяет старый баннер, который уже отображается в Почте, то админка не позволит сделать его небезопасным.
Повсеместный HTTPS Далее нам пришлось поддерживать HTTPS везде, где это возможно.
Контента, который должен подаваться по HTTPS, много, и он неоднороден: это все картинки, статические изображения, аватары, вложения.
Одно дело поддерживать SSL на серверах, которые обслуживают эти изображения, а другое дело — гарантировать, что ссылки корректны и не зависят от протокола (режим HTTPS не является обязательным, поэтому ссылка должна быть корректной независимо от того, является ли текущий протокол безопасным или нет).
нет).
Соответственно, нам пришлось изменить значительное количество шаблонов, не предназначенных для этого.
Работали мы в полуавтоматическом режиме: сначала через скрипты, потом всё подчищалось вручную.
Естественно, план тестирования претерпел существенные изменения: теперь наши тестировщики все проверяют, редактируют, запускают автотесты и так далее.
Помимо всего этого, мы разработали прокси для изображений.
Дело в том, что большая часть изображений, отправляемых пользователю в письмах, являются внешними, и мы пока не можем заставить работать весь Интернет по HTTPS. Поэтому был создан быстрый, легкий, однопоточный прокси, который пропускает через себя все внешние ссылки и всегда предоставляет пользователю HTTPS-контент в браузере.
Как это работает. Прокси-сервер получает URL-адрес HTTP и получает от него либо контент, либо перенаправление.
Во втором случае прокси проходит редиректы на какое-то значение, указанное в конфиге.
Если в конечном итоге он получает перенаправление HTTPS, он отправляет его клиенту, то есть браузеру.
Браузер показывает изображение оттуда напрямую.
Если контент отображается в конце, то мы тянем все содержимое изображения к себе, оборачиваем его в SSL и отдаем браузеру.
Таким образом, все картинки отображаются абсолютно безопасно, даже если они из небезопасного места.
Хочу отметить, что мы реализовали антибрутфорс и защиту от злонамеренного использования прокси.
Кроме того, нам пришлось перевести на SSL часть проекта «Мой Мир», с которого Почта получает аватары, а также серверы, на которых развернута система логирования.
Также на SSL перешли Веб-агент и серверы, с которых загружаются вложения и их превью.
Еще одна интересная вещь, которую следует отметить: мы реализовали интеллектуальную поддержку SSL на мобильных устройствах.
Не все мобильные устройства корректно работают с SSL, и мы разработали систему, которая определяет тип устройства по серверному коду и действует на основе результата.
В настоящее время поддержка включена на iPhone и iPad, на других мобильных устройствах есть проблемы, над которыми мы работаем.
Недалек тот час, когда Почта Mail.Ru по умолчанию будет работать по протоколу HTTPS на всех современных мобильных устройствах.
Оптимизация Ну и последнее, о чем я хотел поговорить, это оптимизация.
Можно было бы, конечно, купить железо и покрыть возросшие затраты процессорного времени и памяти, но это не наш метод. Оптимизировали, как обычно, начиная с узких мест. Что является самым большим узким местом в SSL? Это соединение, потому что при соединении происходит рукопожатие.
После установления связи клиент и сервер получают некоторые данные, которые можно использовать для шифрования и дешифрования в рамках этого конкретного соединения.
На самом деле, поскольку рукопожатие очень дорогое, каждое соединение обходится системе очень дорого.
Чтобы уменьшить количество подключений, мы установили время Keepalive равным 2 минутам (вместо одной секунды, как было раньше).
Затем мы создали кэш SSL, чтобы сократить время самого рукопожатия за счет повторного использования ключевых данных для одного IP-адреса в течение короткого периода времени.
И напоследок расскажу о небольшом хаке, который тоже существенно увеличил производительность.
Мы сделали ссылку /dev/random на /dev/urandom. Это работает быстрее, потому что /dev/random блокируется, а /dev/urandom не блокируется.
Следовательно, время ожидания ввода-вывода сокращается.
А поскольку диски на наших веб-серверах достаточно загружены (из-за логгирования, входящей статики, сохранений-атак и т. д.), дополнительное ожидание ввода-вывода оказывает существенное влияние на работу сервера в целом.
Заключение SSL в большом, высоконагруженном проекте с множеством коммуникационных компонентов — это настоящая ракетостроение, и это не так просто, как кажется на первый взгляд. Речь идет не только о выкладывании сертификатов.
Это много-много, казалось бы, маленьких задач.
Это немного похоже на сбор пазла; разница в том, что однажды собранный пазл не сломается, а в нашем случае даже замена одного компонента может привести к неожиданным последствиям.
Поэтому важно выделить время и ресурсы для дополнительного мониторинга, провести большое количество тестов, в том числе автоматических, чтобы система продолжала радовать пользователя зеленым замком безопасного соединения.
Если у вас остались вопросы по реализации HTTPS в условиях высокой нагрузки, задавайте их в комментариях, буду рад ответить.
Денис Аникин, Технический директор Почты Mail.ru Теги: #почта #высоконагруженные проекты #HTTPS #SSL-сертификаты
-
Messagebox Для Avaloniaui
19 Oct, 24 -
Я Технический Руководитель. Что Делать?
19 Oct, 24 -
Что Вы Программируете Чаще Всего?
19 Oct, 24
