Pull to refresh

TLS в HTTP/2

Reading time 3 min
Views 18K
Original author: Daniel Stenberg
image

Я написал обзор «http2 explained» и сделал несколько выступлений по поводу HTTP/2. После я получил много вопросов по поводу связки TLS и HTTP/2, поэтому я хотел бы ответить на некоторые из них в данной статье.

TLS не обязателен


В одобренной спецификации HTTP/2, которая скоро станет официальным RFC, нет ничего об обязательном использовании TLS. Наоборот, там рассказывается, как можно передавать данные открытым текстом TCP, и как – через TLS.

По факту TLS будет использоваться всегда


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

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

Если вы разрабатываете сервер для HTTP/2, то вам, в общем-то, придётся реализовывать его для HTTPS, чтобы у вас были какие-то пользователи. А реализация без шифрования не будет особенно сильно тестироваться…

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

Более строгая реализация TLS


При описании HTTP/2 через TLS, спецификация выдвигает более жёсткие требования, чем те, что были сделаны для HTTP 1.1 через TLS. Например, TLS обязана быть версии не ниже 1.2. Спецификация запрещает сжатие и ренегоциации. Определяет минимально возможные размеры ключей. Проще говоря, в HTTP/2 будет использоваться более безопасная версия TLS.

Кроме прочего, в спецификации обязательна поддержка ALPN – относительно нового расширения TLS, RFC 7301, которая помогает определять новую версию HTTP без потерь времени или отправки лишних пакетов.

Обязательность TLS поощряет HTTPS


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

Я считаю, что это хорошо и правильно – и так же считают все, кто заботится о пользователях и об их праве на приватность, и праве избегать массовой слежки.

А почему не сделать TLS обязательным?


При создании спецификации мы не достигли соглашения по вопросу обязательности этого протокола. Многие были против. До этого TLS никогда не был обязательным.

Люди объясняли свои возражения по-разному.

1. Возможная необходимость отслеживания трафика

Некоторые говорят о том, что иногда нужно отслеживать трафик. Тюрьмы, школы, антивирусные программы, защита копирайта, законные требования, и т.д. Кроме того, иногда необходимо кеширование – нельзя сделать прилично работающий интернет в самолёте или через спутник и т.п. без кеширования, а значит, без перехвата трафика.

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

2. Вспомните про малышей

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

3. Сертификаты – это дорого

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

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

Сегодня для работы TLS требуется инфраструктура открытых ключей, где есть организации, подписывающие сертификаты. В результате браузеры доверяют нескольким сотням организаций. Не думаю, что всем это нравится, и что это – наилучшее решение для безопасности. Некоторые считают, что эту проблему надо решать через DANE (DNSSEC), другие работают над заплатками вроде Certificate Transparency OCSP.

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

Как насчёт «безопасности по возможности» (opportunistic security)?


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

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

В Firefox будет включена поддержка таких соединений для HTTP по умолчанию, начиная с версии 37.
Tags:
Hubs:
If this publication inspired you and you want to support the author, do not hesitate to click on the button
+21
Comments 23
Comments Comments 23

Articles