TLS в HTTP/2

Перевод статьи TLS in HTTP/2 с любезного согласия Daniel Stenberg

Я написал документ, поясняющий протокол http2. Также несколько раз я упоминал о HTTP/2 . В связи с этим я получил много вопросов о TLS в связи с HTTP/2, поэтому хочу ответить на некоторые из них здесь.

TLS – не обязательное условие

В одобренной спецификации HTTP/2, которая вот-вот станет официальным RFC, нет рекомендаций по использованию TLS для защиты протокола. Напротив, в спецификации четко объясняется, как использовать его как в открытом тексте (поверх обычного TCP), так и в TLS. TLS не является обязательным условием для функционирования HTTP/2.

TLS обязателен в силе

Хотя спецификация не заставляет внедрять HTTP/2 принудительно поверх TLS, но позволяет делать это поверх обычного текста TCP. Представители групп разработчиков Firefox и Chrome заявили о своем намерении реализовать HTTP/2 через TLS. Это означает, что URL-адреса, начинающиеся с HTTPS://, – единственные, которые включают HTTP/2 для этих браузеров. Разработчики из Internet Explorer намерены также поддерживать новый протокол без TLS. При этом, когда они отправили свою первую тестовую версию в рамках предварительной версии Windows 10, этот браузер также поддерживал только HTTP/2 через TLS. На момент написания этой статьи не было выпущено ни одного браузера, который бы читал открытый текст HTTP/2. Большинство существующих серверов взаимодействуют только по HTTP/2 посредством TLS.

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

Если вы развертываете сервер для HTTP/2, вам нужно сделать это для поддержки HTTPS, чтобы привлечь пользователей. 

Допустимым замечанием было бы то, что браузеры - не единственные пользовательские агенты HTTP/2, и есть несколько реализаций, не относящихся к браузеру. Они реализуют версию протокола без TLS: однако я все еще надеюсь, что влияние браузеров будет существенным.

Строгий TLS

При выборе передачи HTTP/2 через TLS спецификация требует четкого соблюдения требований TLS. Более строгих чем те, которые большинство клиентов когда-либо применяли для обычного HTTP 1.1 через TLS.

Это говорит о том, что TLS 1.2 или более поздняя версия НЕОБХОДИМЫ. Запрещается сжатие и пересмотр. Протокол определяет довольно подробные «худшие приемлемые» размеры ключей и наборы шифров. HTTP/2 будет просто использовать более безопасный TLS.

Еще одна деталь – то, что HTTP/2 по TLS требует использования ALPN –  относительно нового TLS-расширения (RFC 7301), которое помогает согласовывать новую версию HTTP, не теряя ценного времени или обращений к сетевым пакетам.

TLS сам по себе поощряет больше HTTPS

Поскольку браузеры используют HTTP/2 только по TLS (по крайней мере, пока), сайты, которые хотят включить HTTP/2, должны делать это через HTTPS, чтобы получить посещения пользователей. Это обеспечивает мягкое давление на сайты, предлагая HTTPS. Это подталкивает больше людей к сквозному зашифрованному TLS-соединению.

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

Почему TLS – не обязательно

Тот факт, что этот протокол не был включен в спецификацию как обязательный, объясняется тем, что не было единого мнения, что это хорошая идея для протокола. Достаточно большая часть участников рабочей группы высказалась против понятия обязательного использования TLS с HTTP/2. TLS раньше не был обязательным, поэтому отправной точкой было отсутствие обязательного TLS, и пока не удалось добраться до другой точки зрения.

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

Нет, правда, почему TLS – не обязательный протокол?

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

1. Желание проверять HTTP-трафик

Существует заявленная «необходимость» проверять или перехватывать HTTP-трафик по разным причинам. Тюрьмы, школы, антивирусы, защита прав интеллектуальной собственности, требования местного законодательства... С этим также часто связано требование кеширования данных в прокси – таким образом, что вы никогда не сможете установить приличную сеть в самолете или со спутниковой связью. Без кэширования, которое должно выполняться с перехватами.

Конечно, прокси-серверы MITMing, которые прерывают трафик SSL, в наши дни не редкость, и HTTP/2 мало что может сделать для ограничения использования таких механизмов.

2. Подумайте о самых маленьких

«Маленькие устройства не могут справиться с дополнительным бременем TLS». Либо из-за дополнительной загрузки ЦП, которая идет с TLS, либо из-за управления сертификатами в миллиарде принтеров / холодильников / маршрутизаторов и т. п. Сертификаты также регулярно истекают и требуют обновления.

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

3. Сертификаты слишком дороги

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

Недавно кто-то даже заявил, что HTTPS ограничивает свободу пользователей, так как нужно выдать личную информацию, чтобы получить сертификат для сервера. Это была не та цена, которую пользователь готов заплатить. Это, однако, не относится к простейшим видам сертификатов. Для сертификатов с проверкой домена (DV) вам нужно только доказать, что вы каким-то образом «контролируете» данный домен. Обычно нужно иметь возможность получать электронную почту для конкретного получателя в домене.

4. Система CA сломана

Для TLS сегодня требуется система PKI, в которой существуют доверенные центры сертификации, которые подписывают сертификаты, и это приводит к ситуации, когда все современные браузеры доверяют нескольким сотням CA. Я не думаю, что многие люди довольны этим и считают, что это идеальное решение для обеспечения безопасности. В Интернете есть аудитория, которая выступает за DANE (DNSSEC) для решения некоторых частей проблемы, в то время как другие работают над постепенными вспомогательными средствами, такими как прозрачность сертификатов и сшивание OCSP.

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

Кто был против внедрения TLS?

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

Как насчет оппортунистической безопасности?

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

Оппортунистическая безопасность для HTTP теперь реализуется за пределами спецификации HTTP/2 и позволяет клиентам обновлять обычные TCP-соединения, чтобы вместо этого выполнять соединения «без аутентификации TLS». И да: при оппортунистической безопасности никогда не должно быть символа «замка» или чего-либо, что указывало бы на то, что соединение является «безопасным».