HTTPS: основы и влияние на производительность

Краткое содержание для тех, кому покажется, что “многабукф”: HTTPS помогает поддерживать безопасность в Интернете за счет шифрования данных приложений и веб-сайтов во время передачи.

Однако некоторые особенности производительности нужно учитывать. Возможно ускорить работу приложения за счет закрытия SSL-туннеля ближе к пользователю, если использовать сеть доставки приложений (ADN) или сеть доставки контента (CDN).

HTTPS постепенно становится все более распространенным. В этой статье мы рассмотрим, от чего этот протокол защищает, каким образом он поддерживает безопасность, в чем его недостатки, посмотрим, что нас ждет в обозримом будущем, а также познакомимся с Fly.

При посещении сайта, защищенного с помощью HTTPS, трафик HTTP передается по зашифрованному с помощью Secure Socket Layer/Transport Layer Security (SSL/TLS) соединению. Чтобы установить HTTPS-соединение, клиент (посетитель) выполняет три шага, известных как “SSL/TLS-рукопожатие” (Handshake) с сервером хостинга.

Каждый раз при обращении по имени хоста по протоколу HTTPS за доли секунд происходит обмен открытыми ключами:

Посетитель передает приветствие clientHello, а затем предлагает криптографический метод, или набор шифров, для совместного использования.→
Сервер отвечает своим приветствием serverHello, соглашается с набором шифров и генерирует свой открытый ключ, связанный с закрытым ключом, затем отправляет свой открытый ключ клиенту.←
Клиент получает открытый ключ от сервера, затем зашифровывает и передает серверу информацию о своем секретном ключе с помощью открытого ключа сервера.→
Клиент уведомляет сервер о том, что его действия завершены.→
Сервер подтверждает клиенту, что его действия тоже завершены.←
Зашифрованная информация передается между посетителем и сервером.←→

HTTPS означает Secure HTTP — безопасный HTTP

Если вы создаете приложение, которое содержит конфиденциальные пользовательские данные, важность безопасности очевидна. При разборе безопасности приложения возникает множество вопросов.

Защиту какого типа предоставляет HTTPS?
От чего вы защищены?
Каковы нюансы и риски?
Нужно ли использовать HTTPS при размещении чего-то вроде блога или простой статической страницы?
Как настроить HTTPS на сайте или в приложении?

Мы дадим вам некоторые ответы без лишних слов.

Неприятные, дикие вещи

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

В 2015 году Google совместно с Калифорнийским университетом Беркли обнаружили, что ежедневно более 5% уникальных IP-адресов, попавших в поисковую выдачу Google, подверглись атакам, известным как “ad injection”, или “инъекция рекламы”.

Цифры пугающие!

В содержимое незашифрованных страниц злоумышленник может вставить ложные ссылки «Купить» для сбора данных кредитных карт или просто изменить кнопку «Зарегистрироваться», чтобы украсть личную информацию посетителей. Независимо от того, отправляются ли ваши открытые HTTP-пакеты по общедоступным сетям Wi-Fi, через маршрутизаторы вашего провайдера или на последнем отрезке до вашего центра обработки данных, их можно использовать для проведения атаки.

Хуже всего, что уязвимость к инъекциям опасного контента — не единственная проблема. HTTP-пакеты передаются открытым текстом. Любое лицо, находящееся между клиентом и сервером (Человек-В-Середине), может прочесть передающиеся данные, как если бы это был обычный текст.

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

HTTPSecure: во благо

Давайте рассмотрим некоторые ключевые преимущества, которые можно получить, шифруя трафик приложений.

Во время первоначального обмена открытыми ключами SSL/TLS посетители проверяют подлинность имени хоста назначения. Это подтверждает целостность, так как пользователь знает, что при подключении к https://fly.io он подключается именно к https://fly.io, а не к чему-то непонятному между ним и https://fly.io.
После обмена сертификатами зашифрованные данные приложений передаются от посетителя к узлу. Пакеты, содержащие конфиденциальные данные, не могут быть прочитаны или перехвачены. Благодаря шифрованию принадлежащие пользователям учетные или платежные данные защищены от посторонних глаз и остаются в безопасности.
Google Chrome отключает мощные и полезные функции в небезопасных приложениях. Безопасное соединение обязательно для таких отличных инструментов, как геолокация, ориентация устройства в пространстве или перемещение, EME, GetUserMedia, кэш приложений и уведомления.
Google присваивает сайтам, защищенным с помощью HTTPS, более высокие рейтинги в поисковой выдаче.

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

HTTPS и производительность сервера

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

Шифрование требует дополнительной работы со стороны сервера. Существует мнение, что результирующая задержка от дополнительных затрат, связанных с шифрованием и увеличенным количеством запросов за счет handshake, делает HTTPS не стоящим усилий, затраченных на внедрение. Тем не менее, размер доли производительности процессора, используемой для SSL/TLS, является спорным. С 2010 года, с тех пор как Google перенес популярное почтовое приложение Gmail на HTTPS, дебаты поутихли.

Google обнаружил, что нагрузка на рабочие front-end сервера увеличилась менее чем на 1% для процессоров и менее чем на 2% для сети при обращении по SSL/TLS. Сотрудники Google отметили, что их аппаратное обеспечение готово к внушительному числу в 1500 handshake-подтверждений для SSL / TLS в секунду на ядро, до оптимизации.

Обратите внимание, что Google использовал ключи длиной 1024 бита. Использование более стойкого 2048-битного или 4096-битного ключа SSL увеличит нагрузку на процессор.

HTTPS и скорость отображения страниц

Итак, претензии по утечке ресурсов процессора преувеличены. Давайте рассмотрим, что влияет на время отрисовки страниц. Здесь ситуация более острая. Время отображения информации для пользователя является важным фактором при оценке опыта взаимодействия. По данным многочисленных наблюдений, Amazon обнаружила, что каждые 100 мс задержки приводят к снижению продаж на 1%.

Чтобы изучить время отображения информации, проведем быстрый эксперимент. Мы можем использовать curl для определения времени, необходимого для формирования стандартного TCP-соединения, и сравнить его со временем соединения по HTTPS. Установка соединения HTTPS содержит 3 дополнительных обмена, которые мы разобрали в рамках обмена открытыми ключами.

goodroot@flyio ~$ curl -kso /dev/null -w "tcp:%{time_connect}, ssldone:%{time_appconnect}\n"

tcp:0.033 seconds, ssldone:0.132 seconds

Важно отметить, что задержка при передаче пакетов протокола SSL/TLS зависит только от «обертки» пакетов. Ваши данные приложения внутри “обертки” в конечном итоге определят, являются ли общие периоды отрисовки удовлетворительными.

Мы видим, что при обычном TCP-соединении время отклика равнялось 0,033 секунды, а при соединении SSL – 0,123 секунды. Это показывает увеличение на 0,099 секунды при запросе по SSL/TLS, то есть увеличение на 300%! Если ваше приложение делает несколько безопасных запросов во время работы пользователя, общее время суммируется.

К счастью, имеются достижения, которые в обозримом будущем должны привести к общим улучшениям.

HTTP/2 и TLS V1.3: новый Speedy-гонщик

HTTP/2 представляет головокружительные улучшения протокола HTTP. Давайте рассмотрим три полезных изменения в HTTP/2, которые улучшают производительность HTTPS.

HTTP/2-хост может выполнять многоадресную рассылку; сервер может обрабатывать несколько запросов и ответов параллельно. Ранее HTTP/1.x мог обрабатывать только один запрос за раз.
В рамках SSL/TLS-соединения требуется меньшее количество подтверждений в обоих направлениях. Для посетителей, которые подключились ранее, handshake не требуется.
HTTP/2 применяет сжатие к заголовкам пакета, что повышает безопасность и улучшает производительность.

Усовершенствования SSL/TLS в HTTP/2 настолько значительны, что передача будет происходить намного быстрее, чем передача незашифрованных данных с использованием HTTP/1.x. Вместо того чтобы снизить производительность из-за расходования ресурсов на защиту приложения, современная реализация HTTPS через HTTP/2 может сделать ваше приложение быстрее.

Наряду с улучшениями в HTTP/2, сам протокол TLS скоро будет обновлен с версии 1.2 до 1.3. В TLS V1.3 во время обмена открытыми ключами требуется на одно действие меньше, и вводится понятие «0-RTT- данных«.С 0-RTT-данными пользователю не требуется повторный обмен подтверждениями, если он возвращается на сайт, где уже завершил обмен handshake.

К сожалению, TLS V1.3 пока не действует, и в HTTP/2 все еще существует задержка отрисовки SSL/TLS-соединений; задержка увеличивается в зависимости от расстояния до сервера. Но не беспокойтесь, есть возможность уменьшить задержку за счет прерывания SSL-соединения как можно ближе к пользователю.

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

Сокращение длины SSL/TLS-туннеля

Если у вас есть сервер в Чикаго, и пользователь из Франкфурта хочет воспользоваться вашим приложением, время отрисовки увеличится за счет расстояния. Каждый запрос будет становиться медленнее. Если учесть, что для установки связи по SSL/TLS требуется три подтверждения, опыт взаимодействия пользователя с приложением может стать негативным!

Например, каждый обмен добавляет по 50 мс к общему времени отклика. Тогда:

При трех обменах, необходимых для подтверждения SSL/TLS-соединения, вы получаете 150 мсдополнительной задержки.
На большем расстоянии это может вылиться, скажем, в 200 мс для одного обмена и 600 мс общей задержки для SSL/TLS.

То, что казалось относительно небольшой задержкой, с увеличением расстояния многократно растянулось и теперь наносит удар по опыту взаимодействия с пользователем.

Чтобы сократить задержку при подтверждении связи, можно использовать сеть доставки контента (CDN). CDN будет иметь расположенные по всему миру пограничные сервера, для сокращения длины туннеля SSL. Конец туннеля SSL — это то место, где данные SSL/TLS расшифровываются, формируя более быстрый незашифрованный поток данных. Окончанием SSL-соединения близко к пользователю мы сократили длину туннеля и уменьшили время задержки.

Например, ваша сеть CDN имеет пограничный сервер во Франкфурте. Время отклика до пограничного сервера составляет 40 мс, и в общей сложности потребуется 120 мс, чтобы завершить подтверждение соединения, вместо 600 мс, если устанавливать соединение напрямую с сервером в Воронеже.

Эти перехватывающие пограничные серверы CDN разрывают соединение раньше, а дальше отправляют незашифрованные данные туда, где находится сервер с приложением. Это громоздко. В то время как производительность отрисовки повышается, существует опасность, что данные будут скомпрометированы по пути их перемещения по CDN до приложения!

Fly!

Сюжет WikiLeaks по кабельному телевидению, выпущенный в 2013 году, ярко продемонстрировал то, как АНБ пытается запустить щупальца «за пределы балансировки нагрузки», туда, где заканчивается SSL-соединение, чтобы прослушивать незащищенный трафик в датацентрах Google. Жуть!

Шустрые стукачи! А теперь о том, как АНБ использовало балансировку нагрузки SSL-соединений, чтобы шпионить за незашифрованными данными в центрах обработки данных Google.

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

Во Fly мы создали агента, который поможет в этом. Мы назвали его “червоточина” (или “кротовая нора”). “Кротовая нора” находится рядом с вашим приложением. Когда посетитель делает запрос к приложению, он обращается к ближайшему пограничному серверу. После обращения пакеты проходят через безопасный SSH-туннель между вашим приложением и пограничным сервером, используя переадресацию удаленного порта SSH.

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

Туннель от нашего пограничного сервера до вашего приложения не инкапсулирует все пакеты TCP. Вместо этого он берет необходимые данные для запроса и ответа и отправляет их через туннель SSH, защищенный различными шифрами. Этот метод шифрования является безопасным и не приводит к снижению производительности. Самое приятное: это бесплатно, начните сейчас же.

Заключение

Использование HTTPS делает интернет более безопасным для всех. К сожалению, обеспечение безопасности приложения является непростой задачей. Улучшения в протоколах, такие как HTTP/2 и TLS V1.3, и такие сервисы, как CDN, помогут найти компромисс между доступностью, безопасностью и производительностью. Но уязвимые маршруты данных все еще остаются.

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

Эван Ларссон

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