TLS в HTTP/2

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

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

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

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

TLS-обязательства в действии

В то время как спецификации никого не принуждает к реализации HTTP/2 по TLS, но позволяет сделать это в течение открытого TCP текста, представители из Firefox и разработчики Chrome выразили намерения в реализации HTTP / 2 через TLS. Это означает, что URL-адреса HTTPS: //  - единственные, которые позволят HTTP/2 для этих браузеров. Представители Internet Explorer заявили, что они намерены также поддерживать новый протокол без TLS, но когда они отправили свою первую тестовую версию в рамках Tech Preview для Windows 10, этот браузер также поддерживал только HTTP / 2 по TLS. На момент написания статьи, не было ни одного браузера, который бы работал с HTTP/2. Большинство существующих серверов поддерживает только 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 трафика по различным причинам. Тюрьмы, школы, анти-вирус, IPR-защиты, требования по местному законодательству, каким бы упомянуты. Абсолютное требование для кэширования вещей в прокси также часто сопровождает это, сказав, что вы никогда не сможете построить достойную сеть на самолете или спутниковой связи и т.д., без кэширования, что должно быть сделано с перехватывает.

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

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

Маленькие устройства не могут справиться с дополнительной нагрузкой TLS

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

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

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

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

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

4. Система СА разбивается

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

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

Кто были против обязательного TLS?

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

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

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

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

Firefox поддерживает оппортунистическое безопасности для HTTP и она будет включена по умолчанию из Firefox 37.