Включаем и настраиваем HTTP/2 на IIS 10
Первым делом надо заметить, что не все IIS 10 одинаково полезны. IIS 10 Express нам, увы, не подойдёт – нам будет нужен только “полновесный” IIS 10, который есть на Windows Server 2016. Поддержка HTTP/2 будет в нём изначально – надо только её настроить.
Для демонстрации я создал тестовый сайт для настройки HTTP/2, сгенерил ему сертификат (т.к. работать мы будем поверх TLS), и поставил саму роль IIS на Windows Server 2016 TP5. Эта часть задачи тривиальна и к HTTP/2 не относится, покажу лишь картинки про итоговую конфигурацию.
Вот такой у нас сервер:
Binding’и выглядят так:
Как видно, всё абсолютно тривиально и не требует какого-то специального включения – более того, в конфигурации веб-сервера IIS 10 никаких явных настроек HTTP/2 найти не удалось. Впрочем, их удалось найти у нового драйвера http.sys, и будут они следующими:
Доступны три настройки, свежепоявившиеся именно в IIS 10 – это http2tcp и http2tls, соответственно включающие/выключающие поддержку работы HTTP/2 поверх обычного TCP (этот вариант есть в стандарте, но всё по факту идёт к тому, что все будут поддерживать только вариант поверх TLS) либо поверх TLS-сессии, и duo.
Настройка duo включает обработку специального заголовка HTTP 1.1, называемого Upgrade. Смысл отправки этого заголовка клиентом – “я хочу улучшить текущее соединение”, и запрос на улучшение может выражаться в “у меня plaintext, хочу TLS”, либо “хочу протокол новой версии”.
Первый вариант, хоть теоретически и возможен, по сути не используется (т.е. если вы хотите защищённое подключение, вы сразу подключаетесь по HTTPS, а не используете схему “начнём по HTTP, а потом попросим включить TLS”) в HTTP. Зато используется в LDAP, SMTP и FTP – там ситуация “подключились как обычно и позже запросили защиту, типа STARTTLS” бывает.
Второй вариант – как раз наш; он будет работать несложно, клиент будет инициировать подключение по HTTP 1.1 и посылатьUpgrade: h2c. Если сервер может переключиться на HTTP 2.0, то он будет уведомлять об этом кодом 101 Switching Protocol.
Мы включим работу поверх TLS и поддержку Upgrade – поддержку же HTTP 2.0 поверх TCP мы отключим, так как практического использования этой возможности нет, а лишний неиспользуемый сервис – дополнительные потенциальные проблемы.
Проверим через сервис KeyCDN – и видим, что всё ОК:
Мы поддерживаем HTTP/2 и даже с расширением ALPN. Что это за расширение?
ALPN и NPN
ALPN – это Application-Layer Protocol Negotiation, а NPN – Next Protocol Negotiation. Суть этих двух технологий схожа, а NPN вообще можно считать “предварительной” версией ALPN – так вот, нужны они для согласования “нам надо работать по безопасному соединению” (в этом плане они схожи с HSTS).
Если сервер поддерживает NPN, то он может, например, после установки HTTP 1.1-сессии – обычной, нормальной – сообщить клиенту “а я кстати поддерживаю SPDY, и вот на этом порту, и защищённый, поверх TLS”. ALPN (разработан инженерами Microsoft и Cisco в 2013 году) развивает эту идею, работая только поверх TLS, и на данный момент замещает собой NPN.
Так что надпись “Поддерживает ALPN” говорит о том, что наш сервер умеет подсказывать клиенту “переключайся на новый безопасный и более быстрый вариант” всеми доступными способами – и это хорошо.
Но что же с безопасностью? Ведь мы уже в курсе, что просто включить TLS мало, надо ещё и настроить.
Настраиваем безопасность работы HTTP/2 на IIS 10
Воспользуемся стандартным тестом от SSLLabs на качество защиты TLS, и посмотрим на результат (тестирование, напомню, идёт на “нулевом” Windows Server 2016 TP5 со всеми обновлениями на май 2016го):
Немножко грустно, но это всё ж дефолтные настройки, так что не переживаем.
Выключаем старые версии TLS, т.к. сейчас TLS 1.2 поддерживается уже всеми:
Тест нам также намекал, что надо выключить RC4 (удобная команда clean вычищает из ciphersuite’ов ненужные по заданной буквокомбинации):
ATcmd реализует такие штуки через прямое обращение к CryptoAPI, поэтому нам даже перезагружаться не надо будет.
Прогоняем тест ещё раз:
Лучше, но не особо – например, внезапно, IIS 10, который вроде как по умолчанию работает только с TLS, стал соглашаться на SSL 3.0 для ряда устаревших систем:
ОК, явно выключим сейчас SSL 3.0 (аналогично TLS, команды будут no ssl20 и no ssl30, плюс уберём ciphersuites с вариантами DES, чтобы совсем закрыть возможность упасть даже на “любимый” IIS’ом TLS_RSA_WITH_3DES_EDE_CBC_SHA, ну и до кучи уберём “короткий” 128ми битовый AES (команды будут clean DES, clean _128_). Замечу, что убирать весь 128 битовый AES нельзя, потому что в стандарте HTTP/2 явно указано, что среди поддерживаемых сервером должен бытьTLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
Кстати, обратите внимание, в тесте показывается работа ALPN/NPN – при согласовании TLS 1.2 указывается значок “>”, после которого пишется, на какой протокол пошло согласование – h2 будет обозначать HTTP/2.
Вот результат следующего прогона теста:
Лучше, но появилась новая проблема – наш IIS 10 начал согласовывать “blacklisted ciphersuites”.
Список этих ciphersuites есть в приложении A к RFC 7540, и, подчеркну, он необязательный – т.е. там стоит слово MAY, что значит “при согласовании кого-то из этого списка сервер МОЖЕТ сообщить INADEQUATE_SECURITY“, но в реальности нам надо избегать согласования ciphersuites из этого списка в целях лучшей совместимости с различной реализацией HTTP/2 over TLS у клиентов.
Поэтому выкидываем TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA и TLS_RSA_WITH_AES_256_CBC_SHA (скриншоты не делаю, потому что идентичная операция) и смотрим на результат. Он остаётся таким же, т.е. мы получаем A – наш единственный минус, что у нас есть шифрование с секретным ключом короче 256 бит (и если мы его выключим, мы выпадем из стандарта HTTP/2), а также есть обмен DH (а не только ECDH). Вопрос полного отключения DH обсуждаем в каждой конкретной ситуации, т.к. он повлечёт за собой несовместимость со множеством устаревших устройств и ОС (например в нашей ситуации удалениеTLS_DHE_RSA_WITH_AES_256_GCM_SHA384 приведёт к неработоспособности IE 11 на Windows 7, Windows 8, Windows 8.1 и на Windows Phone всех версий (исключая разве что 10ю) – если сие не критично, то, конечно, вы можете сократить список поддерживаемых ciphersuites ещё сильнее.
Впрочем, такой хардкор уже нуждается в серьёзном обосновании целесообразности – поэтому мы лишь включаем HTTP Strict Transport Security – ведь мы только поверх TLS и работаем, и прогоняем тест ещё раз.
Наш финальный балл – A+, и на этом операцию можно считать завершённой. В итоге HTTP/2 работает, поддерживает все последние расширения (ALPN), совместим не только с самыми последними ОС и браузерами, но и с чуть-чуть старыми, выполнены все требования стандарта HTTP/2 по части наличия необходимых ciphersuites и отсутствия blacklisted, и у нас максимальный балл по тесту SSLLabs.