Грядут большие перемены в основных протоколах Интернета

Марк Ноттинхем

Теперь основные протоколы Интернета претерпевают значительные изменения. На работу Интернета в общем и целом они не сильно повлияют (иначе бы их не приняли), но могут оказаться неприятным сюрпризом для тех, кто привык пользоваться недокументированными особенностями протоколов в неблаговидных целях... или просто привык рассчитывать на сохранение статус-кво. Когда протокол не может развиваться, потому что внедрение «заморозило» его точки развития, мы говорим, что он окостенел. Для предотвращения окостенения важно открыть протоколам возможность развиваться в соответствии с потребностями Интернета будущего; иначе случится т.н. трагедия общин, где действия некоторых сетей – пусть и лишенные злого умысла – могут подорвать «здоровье» всего Интернета.

Когда Интернет начал широко использоваться в 1990-х годах, большая часть трафика использовала всего несколько протоколов: IPv4 маршрутизировал пакеты, TCP превращал эти пакеты в соединения, SSL (а позднее TLS) эти соединения шифровал, DNS сообщал имена хостов для подключения, а протокол прикладного уровня HTTP все это использовал.
Шли годы, а эти протоколы – основные протоколы Интернета – изменились лишь в мелочах: в HTTP добавилось несколько новых заголовков и методов, TLS неспешно претерпел парочку мелких переработок, в TCP появился контроль перегрузки, а DNS обзавелся «фишечками» типа DNSSEC. Сами же протоколы в процессе передачи, как говорят – «на проводе» (on the wire), долгое время оставались практически теми же (за исключением IPv6, но эта тема и так получает достаточно внимания у сетевых операторов).
В результате сетевые операторы, поставщики услуг и законодатели, которые желают понять (а иногда и контролировать) Интернет, за долгие годы выработали ряд методов, основанных на «отпечатках» этих протоколов при передаче по каналу – и эти методы верно служат им для самых разных целей: будь то устранение неполадок, повышение качества обслуживания или навязывание политик.
Теперь же основные протоколы Интернета претерпевают значительные изменения. На работу Интернета в общем и целом они не сильно повлияют (иначе бы их не приняли), но могут оказаться неприятным сюрпризом для тех, кто привык пользоваться недокументированными особенностями протоколов в неблаговидных целях… или просто привык рассчитывать на сохранение статус-кво.
Зачем нам нужно менять Интернет
Причин тому немало.
Во-первых, основные протоколы Интернета подошли к границам своих возможностей, в первую очередь в части быстродействия. Из-за структурных проблем в протоколах прикладного и транспортного уровней сеть используется неэффективно, в результате чего страдает конечный пользователь (в первую очередь мы говорим о задержке).
Это уже само по себе весомый аргумент в пользу доработки или замены устаревших протоколов, поскольку имеется множество свидетельств того, какой весомый эффект дает даже небольшое повышение быстродействия (https://www.smashingmagazine.com/2015/09/why-performance-matters-the-perception-of-time/).
Во-вторых, развивать и модифицировать протоколы Интернета – на любом уровне – со временем становится все труднее, в немалой степени из-за того, что (как уже говорилось) сети не всегда используют их строго по назначению. Например, HTTP-прокси, компрессирующие ответы, усложняют развертывание новых методов сжатия, а оптимизация TCP в сетевых приставках затрудняет внедрение доработанных вариантов TCP.
Чтобы Интернет хорошо работал в долгосрочной перспективе, он должен приносить ценность конечным пользователям, не поддаваться окостенению и не мешать сетям работать.

И, наконец, сейчас Интернет повсеместно внедряет шифрование (https://static.googleusercontent.com/media/research.google.com/en/pubs/archive/46197.pdf) после откровений Эдварда Сноудена в 2013 году. Эта тема вообще отдельная; но здесь нельзя не отметить, что шифрование – один из лучших имеющихся у нас инструментов, обеспечивающих протоколам возможность развиваться.
Теперь поговорим о том, что случилось, что будет дальше, как это может повлиять на сети и как сети влияют на дизайн протоколов.

HTTP/2
HTTP/2 (выросший из Google SPDY) ознаменовал собой первую крупную реформу – ставший стандартом в 2015 году, этот протокол мультиплексирует запросы по одному соединению TCP, устраняя необходимость ставить запросы на клиенте в очередь, чтобы они не блокировали друг друга. Теперь этот протокол получил широкое распространение, поддерживается всеми основными браузерами и крупными веб-серверами.
С точки зрения сети, значительных изменений в HTTP/2 несколько. Во-первых, это двоичный протокол, т.е. любое устройство, которое примет его за HTTP/1.1, просто не будет работать.
В частности, поэтому в HTTP/2 введено еще одно крупное новшество: по сути, он требует шифрования. Дело в том, что при шифровании промежуточные устройства имеют меньше возможностей что-то напортить: либо обращаться с HTTP/2 как с HTTP/1.1, либо вносить менее заметные изменения, например, отрезать заголовки или блокировать новые расширения. Инженеры, участвовавшие в разработке нового протокола, столкнулись с обеими описанными ситуациями, и обе они вызвали значительные проблемы с поддержкой.
Кроме того, HTTP/2 требует использовать TLS/1.2 (и выше) для шифрования (http://httpwg.org/specs/rfc7540.html#TLSUsage), а также вносит в черный список (http://httpwg.org/specs/rfc7540.html#BadCipherSuites) шифронаборы, которые считает небезопасными — по сути, он допускает только эфемерные ключи. Вопрос о том, на что это может повлиять, мы обсудим в разделе, посвященном TLS 1.3.
И, наконец, HTTP/2 позволяет объединить несколько запросов хоста в одно соединение (http://httpwg.org/specs/rfc7540.html#reuse), повышая быстродействие за счет снижения числа подключений (а тем самым – и контекстов контроля перегрузки), необходимых для загрузки страницы.
Например, имеющееся подключение к www.example.com можно использовать для запросов к images.example.com. В будущих расширениях этого протокола, возможно, будет разрешено добавлять к соединению новые хосты (https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs), даже если они отсутствовали в исходном TLS-сертификате соединения. Получается, нельзя будет и дальше предполагать, что трафик по соединению ограничивается той целью, для которой это соединение было установлено.
Несмотря на перечисленные изменения, следует отметить, что HTTP/2 не обнаружил существенных проблем с совместимостью или помехами со стороны сетей.
TLS 1.3
TLS 1.3 сейчас находится в финальной стадии стандартизации и уже поддерживается некоторыми реализациями.
Разработчики стандарта излишне поскромничали, назвав его TLS 1.3, а не 2.0: перед нами фактически новая версия TLS, с полностью переработанным рукопожатием, позволяющим передавать данные приложений с самого начала (это часто называют 0RTT). Новый протокол также полагается на обмен эфемерными ключами, не используя статических.
Это обстоятельство встревожило часть сетевых операторов и поставщиков – в первую очередь тех, кому требуется видеть, что происходит внутри соединения.
Например, центр данных крупного банка по закону должен обеспечивать прозрачность трафика. У него на серверах стоит сниффер, который анализирует трафик и дешифрует его с помощью статических ключей, чтобы регистрировать законный трафик и выявлять незаконный – и атаки извне, и попытки сотрудников организовать утечку данных вовне.
Такую методику перехвата трафика TLS 1.3 не поддерживает, потому что это еще и одна из форм сетевых атак, для защиты от которых и предназначены эфемерные ключи (https://en.wikipedia.org/wiki/Forward_secrecy). Но ведь тот же самый закон, который требует от банков осуществлять мониторинг своих сетей, предписывает им использовать современные протоколы шифрования. И как тут быть?
Было сломано много копий в спорах о том, действительно ли закон требует именно статических ключей, могут ли альтернативные подходы оказаться не менее эффективными – и стоит ли ради потребностей относительно немногих сетей поступиться безопасностью всего Интернета. И действительно, дешифровка трафика TLS 1.3 возможна, но для этого нужны эфемерные ключи, а они по самой своей сути долго не живут.
На сей момент непохоже, что разработчики TLS 1.3 модифицируют его так, чтобы учесть потребности таких сетей, но есть разговор о том, чтобы создать еще один протокол, который позволит третьей стороне наблюдать за происходящим – а возможно, и не только – специально для таких случаев. Время покажет, что из этого вырастет и вырастет ли.

QUIC
В процессе работы над HTTP/2 обнаружилось, что TCP страдает от той же самой неэффективности. Поскольку TCP – протокол с сохранением порядка пакетов, потеря одного может сорвать доставку всех последующих: они так и останутся в буфере. При мультиплексировании это может означать катастрофическую потерю быстродействия.
QUIC – это попытка решить проблему, фактически воссоздав семантику TCP (вместе с частью потоковой модели HTTP/2) поверх UDP. Как и HTTP/2, QUIC первоначально разрабатывался Google, а теперь IETF развивает его, начиная с первоначального сценария использования «HTTP поверх UDP». Планируется сделать его стандартом к концу 2018 года. Однако поскольку Google уже внедрил QUIC в своем браузере Chrome и на своих сайтах, на него уже приходится более 7% интернет-трафика.
Помимо того, что столь значительный объем трафика перешел с TCP на UDP (т.е. сети должны адаптироваться к новой реальности), оба варианта QUIC – и Google QUIC (gQUIC), и IETF QUIC (iQUIC) – для работы требуют шифрования: незашифрованного QUIC не существует в принципе.
iQUIC использует TLS 1.3 для создания ключей сеанса, а потом шифрует ими каждый пакет. Но поскольку это надстройка над UDP, в QUIC шифруется множество того, что в TCP передается открыто – в частности, информация о сеансе и метаданные.
По сути, в нынешнем «коротком заголовке» (https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#short-header) iQUIC, который используется для всех пакетов, кроме рукопожатия, открыты только номер пакета, необязательный идентификатор соединения и бит состояния, используемый для таких вещей, как график ротации ключей шифрования и тип пакета (причем они сами могут быть зашифрованы).
Все остальное зашифровано, включая ACK – очень интересный сюрприз для атак путем анализа трафика (https://www.mjkranch.com/docs/CODASPY17_Kranch_Reed_IdentifyingHTTPSNetflix.pdf).
С другой стороны, теперь невозможна пассивная оценка RTT и потери пакетов путем наблюдения за соединением, для этого не хватает информации. Поэтому некоторые сетевые операторы категорически против перехода на QUIC, они утверждают, что подобные пассивные измерения необходимы для отладки сетей и понимания их работы.
Уже появилось предложение, призванное решить эту проблему – так называемый бит-перевертыш (Spin Bit) (https://tools.ietf.org/html/draft-trammell-quic-spin): бит в заголовке, который переворачивается один раз при передаче в оба конца, чтобы наблюдатель смог аппроксимировать RTT. Поскольку этот бит никак не связан с состоянием приложения, он не выдает никакой информации о конечных точках соединения, кроме грубой оценки их расположения в сети.
DOH
Последнее из новых веяний на горизонте – это DOH, или DNS поверх HTTP (https://datatracker.ietf.org/wg/doh/about/). Исследования показали, что DNS в сетях регулярно используется в качестве средства навязывания политик (https://datatracker.ietf.org/meeting/99/materials/slides-99-maprg-fingerprint-based-detection-of-dns-hijacks-using-ripe-atlas/) (как от лица сетевого оператора, так и от лица властей).
Некоторое время обсуждалась идея обойти этот вид контроля с помощью шифрования (https://datatracker.ietf.org/wg/dprive/about/), но недостатком такого решения (по крайней мере, с некоторых точек зрения) является возможность выделить подобный трафик из общей массы – например, заблокировать его по номеру порта.
DOH решает эту проблему, «растворяя» трафик DNS в существующем соединении HTTP и тем самым просто убирая демаскирующие элементы. Теперь, чтобы заблокировать доступ к такому DNS-преобразователю, придется заблокировать и доступ к веб-сайту.
Например, если Google решит перевести на DOH свою общедоступную службу DNS (https://developers.google.com/speed/public-dns/) на www.google.com, а пользователь настроит свой браузер на работу с этой DNS-службой, то чтобы перекрыть доступ к ней, придется заблокировать весь Google (благодаря тому, как там организован хостинг сервисов).
Работы над DOH только начались, но уже вызвали существенный интерес… и ворчание касательно внедрения. Как на DOH отреагируют сети (и госструктуры), использующие DNS для выстраивания политик, покажет время.

Окостенение и смазка
Вернемся к вопросу «зачем менять Интернет». В своей работе разработчики протоколов снова и снова сталкиваются с одной и той же проблемой: сети делают некорректные предположения о трафике.
Например, у TLS 1.3 было немало проявившихся в последнюю минуту проблем с сетевыми приставками, которые принимали его за более раннюю версию протокола. А gQUIC заносит в черный список несколько сетей, которые задавливают трафик UDP, потому что считают его вредоносным или неприоритетным.
Когда протокол не может развиваться, потому что внедрение «заморозило» его точки развития, мы говорим, что он окостенел. Одним из ярких примеров окостенения является TCP: множество сетевых приставок «позволяют себе вольности» в обращении с TCP — от блокировки пакетов с нераспознанными опциями TCP до «оптимизации» контроля перегрузки.
Для предотвращения окостенения важно открыть протоколам возможность развиваться в соответствии с потребностями Интернета будущего; иначе случится т.н. трагедия общин, где действия некоторых сетей – пусть и лишенные злого умысла – могут подорвать «здоровье» всего Интернета.
Предотвращать окостенение можно различными способами; если соответствующие данные шифруются, они недоступны никому, кроме обладателей ключа, что перекрывает возможность вмешательства. Если точка расширения не зашифрована, но обычно используется таким образом, который видимо «ломает» приложения (например, заголовки HTTP), вероятность вмешательства здесь ниже.
Там, где разработчики протоколов не могут использовать шифрование, а точка расширения используется нечасто, ситуации можно помочь, искусственно нагружая точку расширения; мы называем это смазкой.
Например, QUIC поощряет использование на оконечных точках различных пустых значений при переговорах о версии (https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.section.3.7), чтобы различные реализации не предполагали, будто номер версии не будет меняться (ситуация, обнаружившаяся в реализациях TLS и повлекшая много неприятных проблем).
Сеть и пользователь
Помимо борьбы с окостенением, эти изменения также отражают развитие отношений между сетями и их пользователями. Долгое время люди считали сеть благонамеренной или как минимум нейтральной стороной, но сейчас сетям перестали столь безоглядно доверять – и не только из-за сплошного мониторинга (https://tools.ietf.org/html/rfc7258), но и из-за атак типа Firesheep (http://codebutler.com/firesheep).
В результате возникает конфликт интересов между основной массой пользователей Интернета и теми из сетей, которым требуется доступ к данным, проходящим через них. Особенно выделяются здесь сети, которые желают налагать на своих пользователей определенные политики – например, корпоративные сети.
В некоторых случаях сети могут достичь своих целей, устанавливая на машины своих пользователей специальное ПО (или сертификаты CA, или браузерные расширения). Однако это не так просто, если компьютер пользователя не принадлежит сети или недоступен для нее: например, использование личных компьютеров и телефонов на работе стало общим местом, а устройства Интернета вещей редко оснащены адекватными интерфейсами управления.
В результате множество дискуссий в IETF о развитии протоколов вращается вокруг (часто конфликтующих) потребностей корпоративных и других «оконечных» сетей с одной стороны и Интернета в целом – с другой.
Примите участие в работе
Чтобы Интернет хорошо работал в долгосрочной перспективе, он должен приносить ценность конечным пользователям, не поддаваться окостенению и не мешать сетям работать. Изменения, происходящие сейчас, должны соответствовать всем трем перечисленным целям, но нам очень не хватает обратной связи от сетевых операторов.
Если предлагаемые изменения негативно скажутся на вашей сети – и даже если они на ней не скажутся, – пожалуйста, оставьте внизу свой комментарий, а еще лучше – примите участие в работе IETF (https://www.ietf.org/): посетите совещание, подпишитесь на рассылку или дайте обратную связь по проектам стандартов.
Автор выражает благодарность Мартину Томсону и Брайану Треммеллу за конструктивные замечания. Эта статья была впервые опубликована в блоге APNIC.
Источник: Big Changes Ahead for Core Internet Protocols