Кратко

  • RFC 2817 описал переход действующего соединения HTTP/1.1 на TLS через Upgrade: открытый и защищённый HTTP могли делить порт 80, а поле Host приходило до выбора сертификата.
  • Документ сохранил самостоятельное пространство адресов https и отметил слабый интерес к замене порта 443 при обычном просмотре сайтов. RFC 2818 зафиксировал схему, в которой TLS на этом порту начинается прежде HTTP.

У раннего Веба были две подписанные двери. Обычный HTTP шёл на порт 80. Адрес https по умолчанию вёл на порт 443: сперва TLS предъявлял рукопожатие, затем HTTP передавал запрос внутри защищённого канала. В декабре 1997 года руководство прикладного направления IETF снова высказалось против привычки назначать каждому новому протоколу пару портов, обычный и безопасный. Весной 2000 года появился проект, который предлагал обойтись одной дверью и поставить на неё замок. На чертеже это выглядело как избавление от лишнего ключа; в адресной строке ключ давно лежал под номером 443.

RFC 2817 предложил механизм Upgrade для перехода с HTTP/1.1 на TLS/1.0 в уже установленном TCP-соединении. Появлялась и польза для виртуального хостинга. Несколько имён сайтов могли жить на одном IP-адресе, потому что HTTP-запрос передавал имя в поле Host. Когда TLS начинался раньше HTTP, серверу приходилось выбирать сертификат ещё до получения этого поля. Открытое начало разговора давало ему имя, а затем включалась защита. Сначала спросить посетителя, к кому он пришёл; потом запереть вход.

У RFC 2616 слово Upgrade означало изменение протокола между соседними участниками соединения. Клиент мог послать Upgrade: TLS/1.0 и Connection: Upgrade вместе с обычным запросом, если открытый ответ его устраивал. Когда открытый ответ был недопустим, RFC 2817 требовал сперва отправить OPTIONS *. Этот предварительный обмен выяснял готовность сервера, не выдавая содержимое чувствительной операции до установления TLS.

Согласившийся сервер отвечал 101 Switching Protocols, указывал порядок TLS/1.0, HTTP/1.1 и переходил к рукопожатию TLS сразу после заголовков ответа. После рукопожатия продолжался HTTP, уже защищённый. Код 426 Upgrade Required давал серверу возможность потребовать такой переход для ресурса. Само число 426 не выполняло переход: клиенту ещё предстоял обмен Upgrade. Надпись «запереть дверь» не поворачивает ключ.

Посредники усложняли маршрут. Upgrade действовал на одном участке пути. Ответ 101 от прокси менял связь клиента с прокси, но ничего автоматически не делал с соединением прокси и исходного сервера. Для защиты до самого сервера RFC 2817 описал туннель CONNECT, в том числе к порту 80. После успешного ответа класса 2xx клиент мог провести переговоры об Upgrade с сервером через туннель. Одна общая дверь всё равно требовала знать план коридоров.

Оставалась строка адреса. RFC 2817 сохранил раздельные пространства URI http:// и https://. Опубликованный в том же месяце RFC 2818 описал путь https: порт 443 по умолчанию, первым идёт TLS ClientHello, затем HTTP внутри TLS. Новый порядок установки соединения менял работу двери. Адрес продолжал сообщать, в какое именно место направляется браузер.

Авторы RFC 2817 прямо описали реакцию своего времени. Общий замысел встретили широко благожелательно, но альтернативу порту 443 для обычного просмотра Веба почти не стремились внедрять. Более перспективными выглядели новые протоколы поверх HTTP, включая интернет-печать. Это признание стоит в самом введении стандарта. Общий порт обещал сократить число параллельных назначений, позволить заранее прочитать имя хоста и явно требовать TLS. На пути стояли предварительный обмен, прокси и адреса https, уже разошедшиеся по Сети. TLS постучал в порт 80. В приглашении было написано 443.