Skip to content

Concrete5 на русском языке

Переход на https, не жертвуя скоростью загрузки

Быстрая загрузка сайта это критически важный аспект для хорошего отношения пользователей к сайту. Настолько важный, что несколько лет назад Google объявил, что они будут использовать скорость загрузки страницы в качестве фактора поискового ранжирования. Недавно, Google также объявил, что они будут продвигать сайты, использующие Transport Layer Security (TLS) в поисковом ранжировании.  TLS шифрует трафик вебсайта, предохраняя от мониторинга передачи данных "шпионскими" службами. Тем не менее, добавление этой меры предосторожности делает и сайт более сложным, и общение с посетителями, потенциально замедляя взаимодействие с сайтом и негативно влияя на удобство пользователей. В этой статье я покажу как использовать TLS, чтобы сайт оставался быстрым и гибким. 

Соглашения и отказ от ответственности

Прежде чем мы начнем, кратко отмечу, что TLS чаще можно услышать под названием SSL. SSL был разработан компанией Netscape в середине 90-х как протокол шифрования. TLS протокол произошел из SSL и продолжает развиваться и улучшаться, в то время как SSL постепенно сдает позиции. В прошлом, SSL и TLS были взаимозаменяемыми понятиями. Но  в последней версии SSL, SSLv3, были найдены уязвимости. Все версии SSL были не достаточно безопасны и никто не должен использовать никакие версии SSL. Чтобы не вводить вас в заблуждение я больше не буду упоминать термин SSL, а буду говорить только о TLS. 

Дополнительно, в то время как TLS помогает защищать посетителей сайта от злоумышленников, он не может магически сделать ваш сайт "безопасным" от утечек вызванных скриптами внедраяемых злоумышленниками или от SQL внедрений. Если вы храните персональные данные пользователей или собираете коммерческие данные на сайте, вам нужно более тщательно подбирать методы защиты. 

Наконец, любое руководство или статья о том как защитить сайт очень чувствительны ко времени публикации. Атакующие постоянно совершенствуют свои методы и придумывают новые. Советы по оптимизации TLS, которые  давали даже два года назад, сделали бы ваш сайт незащищенным (например, использование RC4. Вам все время надо быть начеку и пользоваться советами только из проверенных источников.

TLS сферы где нужен TLC

Есть две области TLS, которые могут повлиять на скорость:

  1. Шифрование данных. Данные посылаемые туда и обратно между браузером и вашим сервером должны шифроваться и дешифроваться. Если использовать неправильные настройки, то скорость загрузки страницы может значительно уменьшиться в сравнении с незашифрованным трафиком. 
  2. Установка безопасного соединения. Существует несколько этапов, которые должны быть пройдены, прежде чем браузер установит безопасное соединение с сайтом: Сертификаты должны быть подтверждены, выбран необходимый алгоритм и ключи должны быть обменены. Это называется рукопожатие TLS, которое оказывает существенное влияние на скорость загрузки сайта. 

Мы должны подарить каждому из этих этапов заботу и ласку (Tender Loving Care (TLC)), чтобы оптимизировать производительность. Давайте детально обсудим каждый шаг

Оптимизация Шифрования Данных

Когда используется TLS, вы добавляете еще 2 шага к процессу коммуникации браузера и сервера. Отправитель должен зашифровать данные перед отправкой, а получатель должен дешифровать их перед обработкой. И поскольку эти две операции происходят постоянно со всем трафиком, то нужно, чтобы этот обмен был настолько эффективным, насколько это возможно. 

Существует большое количество шифров, которые могут использоваться для выполнения этого шифрования / дешифрования. Некоторые из них, такие как 3DES, изначально были разработаны для аппаратного обеспечения и могут медленно выполняться при использовании программного обеспечения на вашем компьютере или в браузере телефона. Другие, такие как AES, настолько популярны, что производители процессоров, такие как Intel, добавили специальные инструкции к своим чипам, чтобы заставить их работать быстрее.

Десять лет назад шифрование данных TLS привело к значительным накладным расходам. Сегодня закон Мура и специальная поддержка определенных шифров в процессорах существенно устранили эти накладные расходы, если вы выберете правильный шифр. Консенсус от разработчиков и администраторов безопасности, которые запускают большие веб-сайты TLS, заключается в использовании AES с 128-битными ключами. Из приведенной ниже диаграммы видно, что AES, работающий на процессоре, который поддерживает встроенные инструкции AES (обозначается ярлыком AES-NI), на сегодняшний день является самым быстрым шифром, который вы можете использовать.

Диаграмма скорости загрузки страницы

Указание того, какой шифр и варианты использования могут быть довольно сложными и запугивающими. К счастью, Mozilla создала отличную страницу с примерами конфигураций шифров для обеспечения быстрых и безопасных соединений. Эти примерные конфигурации работают со всеми браузерами, и по умолчанию они используют более быстрые алгоритмы, такие как AES. Они постоянно обновляются, когда появляются новые угрозы безопасности, и я настоятельно рекомендую следовать их указаниям.

Как уже упоминалось, чтобы получить максимальную отдачу от AES, вашему веб-серверу необходимо будет использовать процессор, который поддерживает специальные инструкции AES, известные как AES-NI. Большинство серверных процессоров, сделанных за последние 5 лет, таких как линейка Intel Xeon, поддерживают AES-NI. Однако старые виртуализированные серверы и облачные серверы часто не поддерживают эти инструкции. Класс M1 экземпляров EC2 от Amazon не поддерживает AES-NI, тогда как текущий класс экземпляров M3 от Amazon поддерживает. Если вы используете размещенную службу, обратитесь к своему хостинг провайдеру с вопросом о том, какие параметры TLS они поддерживают, и поддерживает ли ваш хостинг AES-NI.

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

Контрольный список по оптимизации

  • Включите AES в качестве предпочтительного шифрования, следуя рекомендациям Mozilla.
  • Убедитесь, что веб-сервер работает в системе с процессором, поддерживающим инструкции AES-NI.

Оптимизация согласования (рукопожатия) TLS

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

  • Идентификация сервера и, возможно, клиента
  • Рассказывая друг другу, какие шифры, подписи и другие варианты поддерживает каждая сторона, и соглашаясь на использование подходящих для обеих сторон вариантов
  • Создание и обмен ключей, которые будут использоваться позднее во время шифрования данных

Рукопожатие TLS показано на этой технической диаграмме:

Рукопожатие TLS

Не волнуйтесь. Несмотря на то, что на диаграмме много деталей, выгода заключается в том, что полное рукопожатие TLS включает в себя 2 маршрута туда и обратно между клиентом и сервером. Из-за разницы между задержкой и пропускной способностью, более быстрое подключение к Интернету не ускоряет эти маршруты. Это рукопожатие обычно занимает от 250 миллисекунд до половины секунды, но может длиться и дольше.

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

Водопад - результат теста скорости загрузки страницы

Рукопожатие TLS, показанное фиолетовым для каждого шага здесь, добавляет 750 мс задержки ко времени, которое требуется для получения начальной HTML-страницы. В этом примере загрузка HTML-страницы через TLS занимает в два раза больше времени, чем получение этой же страницы по незашифрованному соединению! Хуже того, браузер не может ничего сделать, пока не получит эту начальную HTML-страницу. Он не может загружать и другие ресурсы параллельно, например, файлы CSS или изображения, поскольку он не получил эту начальную HTML-страницу, в которой говорится о других ресурсах. Это верно для каждой защищенной веб-страницы, которую вы посещаете: браузер не получает этот первый ответ HTML. К сожалению, рукопожатие TLS увеличивает время, в течение которого браузер не может ничего сделать, замедляя производительность вашего сайта.

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

К сожалению, в процессе рукопожатия TLS не так много лишних или ненужных данных, которые мы можем оптимизировать. Основным аспектом, который мы можем оптимизировать, является шаг «подтверждения идентичности сервера». Для этого браузер смотрит на то, что называется цепочкой сертификатов.

Цепочка сертификатов

Когда вы посещаете https://www.example.com, откуда вы знаете, что действительно видите www.example.com? Сертификаты TLS решают эту проблему. Вы получаете сертификат, сообщающий вашему браузеру «да, это www.example.com. Доверяй мне». Но откуда вы знаете, что можете доверять сертификату, отправленному сервером?

Именно здесь нужна цепочка сертификатов. Ваш сертификат будет подписан цифровой подписью каким-либо сертификатом другого лица, что, по сути, говорит: «example.com классный, я поручился за него, вот мой сертификат». Это называется промежуточным сертификатом. Браузеры имеют встроенный список из тысяч сертификатов, которым они доверяют. Если браузер доверяет этому промежуточный сертификат, мы закончили. Однако, возможно, браузер не доверяет сертификату вашего веб-сайта или промежуточному сертификату.

Что происходит тогда? Просто! Затем браузер посмотрит, кто подписал промежуточный сертификат, и кто подписал его, и так далее ... В основном браузер будет «ходить» по этой цепочке сертификатов, видя, кто ручается за кого, пока не найдет сертификат того, кому он доверяет, из этого встроенного списка, упомянутого выше.

Цепочка сертификатов выглядит примерно так:

цепочка сертификатов SSL

Здесь мы видим сертификат для моего сайта app.zoompf.com. Мой сертификат был подписан сертификатом «DigiCert Secure Server CA». Браузер не доверяет этому сертификату, так как он не находится в его предварительно построенном списке. Однако сертификат «DigiCert Secure Server CA», в свою очередь, был подписан сертификатом «DigiCert Global Root CA», который находится в этом списке и, таким образом, проверен. Поэтому в этом случае длина моей цепи сертификата равна 3.

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

Когда будете покупать сертификат TLS, спросите продавца:

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

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

Чек лист по оптимизации

  1. Уменьшите длину цепочки сертификатов.
  2. Проверьте, чтобы все последующие сертификаты поставлялись с вашим сертификатом.
  3. Получите сертификат, который поддерживает OCSP.

Избегайте полных рукопожатий TLS

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

В этом случае возобновляется сеанс TLS. В принципе, возобновление сеанса TLS позволяет клиенту сказать: «Привет, сервер, мы недавно общались и сделали это, используя следующие параметры TLS ... Можно ли снова начать говорить, используя такие же варианты? " Это огромное улучшение производительности. Для установления безопасного соединения для полного соединения TLS требуется 2 раунда. Повторение сеансов TLS позволяет нам сделать это в 1 раунд.

Самое замечательное в возобновлении сеанса состоит в том, что это в основном бесплатный короткий отрезок. Когда клиент запрашивает сервер, «можем ли мы использовать эти предварительно согласованные настройки?», Он делает это как часть первого раунда в настройке полного рукопожатия TLS. Если сервер согласен, отлично, выполняется короткое рукопожатие, и никакое дальнейшее установление связи не требуется. Если по какой-либо причине сервер не согласен с запросом возобновления сеанса, то рукопожатие TLS продолжается как обычно и завершается в 2 раунда. Нет причин, чтобы отказываться от возобновления сеанса.

Существует два разных механизма для возобновления TLS. Первый - идентификаторы сеанса, а второй - сессии. Оба делают то же самое. Разница между ними заключается прежде всего в том, какая сторона должна отслеживать ранее согласованные варианты. Все веб-браузеры поддерживают оба, но некоторые веб-серверы, такие как Microsoft IIS, поддерживают только идентификаторы сеансов. Идентификаторы сеансов являются немного более старым механизмом и могут потенциально подвергать ваш сайт атакам типа «отказ в обслуживании». Включение идентификаторов сеансов или сессий осуществляется с помощью конфигурации вашего веб-сервера и довольно просто. Проконсультируйтесь с вашим администратором о включении этих параметров.

Чеклист по оптимизации

  1. Включите возобновление TLS на своих веб-серверах.
  2. Если возможно, избегайте использования идентификаторов сеансов, чтобы уменьшить подверженность атакам «Отказ в обслуживании».

Другие опции TLS

Есть еще несколько вариантов и нюансов в TLS, которые мы отметим: Какой асимметричный алгоритм вы должны использовать? Какой протокол обмена ключами вы должны использовать? Какой размер ключа следует использовать для вашего симметричного шифра? Должны ли вы использовать совершенную прямую секретность? Это важные решения с точки зрения безопасности, и у каждого разные потребности. С точки зрения производительности, они в значительной степени спорны. Лучше оставить выбор за тем, кто управляет вашим сервером, или следовать советам Mozilla на странице, указанной выше.

Минимизация TLS общего времени рукопожатия

Как мы видели, рукопожатия TLS, при необходимости, могут повлиять на вашу производительность:

  • Они могут задерживать загрузку важных ответов, таких как загрузка HTML страницы.
  • Они могут происходить несколько раз для одной страницы.
  • Мы не можем их хорошо оптимизировать.

Хотя возобновление сеанса может сократить время рукопожатия TLS пополам, все же лучше избегать рукопожатий TLS. Вы можете сделать это, минимизируя количество HTTP-соединений, которые браузер делает при посещении вашего веб-сайта. К счастью, многие традиционные меры по оптимизации производительности, которые вы должны в любом случае делать, могут помочь. Это делает оптимизацию производительности фронтенда еще более важной на сайтах, защищенных TLS. Давайте сосредоточимся на 4 мерах по оптимизации, которые особенно важны для сайтов, использующих TLS.

1. Постоянное соединение

Постоянные соединения позволяют HTTP выполнять несколько запросов по одному HTTP-соединению. Постоянные соединения позволяют браузеру быстрее загружать страницу, поскольку она может быстрее выполнять запросы. Но он также может сократить количество рукопожатий TLS. Рассмотрим этот водопад, на который мы смотрели раньше:

 

Водопад - результат теста скорости загрузки страницы

Посмотрите, как практически каждый HTTP-запрос имеет фиолетовый раздел? Этот фиолетовый раздел является рукопожатием TLS. Почему это происходит? Поскольку веб-сервер явно закрывает HTTP-соединение и, следовательно, базовое соединение TLS с каждым ответом. Мы можем увидеть это в ответе: Connection: close (Соединение закрыто), как показано ниже:

Закрытие соединения

Это ужасно для производительности в целом, но особенно плохо для сайта с использованием TLS. Ваш сайт должен использовать постоянные соединения.

2. Шардинг (разбивка) домена

Шардинг доменов - это метод, позволяющий обмануть посещаемый браузер, чтобы быстрее загружать ресурсы с вашего сайта. Он работает, имея один веб-сервер с разными именами хостов. Например, ваш сайт может быть назван example.com, но настроен для разрешения имен static1.example.com и static2.example.com на один и тот же сервер. Так как браузеры разрешают только ограниченное количество HTTP-подключений к одному имени хоста одновременно, использование нескольких имен хостов приводит к тому, что браузер загружает больше контента параллельно.

Проблема с шардингом домена заключается в том, что браузер не знает, что example.com, static1.example.com и static2.example.com - это все тот же сервер. Он будет создавать новые HTTP-соединения для каждого имени хоста и каждый раз выполнять полное рукопожатие TLS. В нашем примере мы потенциально делаем 3 рукопожатия TLS из-за наших раздельных имен хостов. Кроме того, информация о возобновлении сеанса для соединений по одному имени хоста не может использоваться соединениями с другим именем хоста, хотя под по сути все эти имена относятся к одному и тому же серверу.

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

3. Объединение CSS и JavaScript файлов

Объединение нескольких файлов CSS или JavaScript в один или два первичных файла - это огромная оптимизация производительности. Браузеры могут загружать один файл размером 100 КБ быстрее, чем 10 10-килобайтных файлов. Преимущество для сайтов TLS заключается в том, что если вы делаете меньше запросов, у вас меньше шансов получить дополнительные HTTP-соединения, для которых потребуется возобновление или полное рукопожатие TLS.

4. Кэширование ресурсов

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

Условные запросы являются плохими для TLS. Вы заставляете браузер создавать больше HTTP-соединений и, таким образом, выполнять больше рукопожатий TLS, просто чтобы проверить, не изменился ли контент. Кэширование ваших статических ресурсов, таких как изображения, CSS и JavaScript, будет иметь большой эффект и может предотвратить эти дополнительные подключения.

Чеклист по оптимизации

  • Включить постоянные подключения (keep-alive). Убедитесь, что ваше приложение или CMS не закрывают досрочно HTTP-соединения.
  • Используйте инструменты, такие как WebPageTest, чтобы узнать, действительно ли шардинг доменов улучшит производительность вашего веб-сайта с поддержкой TLS.
  • Скомбинируйте несколько JavaScrpt и CSS файлов в один, там где это возможно.
  • Закэшируйте статические ресурсы на 5 минут, даже если у вас нет системы управления версиями файлов. 
  • Если у вас есть инфраструктура и процессы на месте, используйте долгосрочное кеширование с системой управления версиями файлов, которая изменяет URL-адреса ваших ресурсов при их изменении.
  • Проверьте свой сайт, чтобы убедиться, что вы правильно выполняете оптимизацию производительности. 

Заключение

Google теперь поддерживает сайты, которые защищены с помощью TLS в рейтингах поисковых систем. TLS может повлиять на производительность, и эта статья показала вам шаги, которые вы можете предпринять для минимизации проблем.

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

По материалам сайта moz.com