Перевод статьи History of HTTPS Usage за авторством Jeff Kaufman.

Интернет начинался c создания HTTP протокола. Это позволяло делать огромное количество вещей, но покупки в Интернете не входили в их число. Проблема заключалась в том, что отправка номеров кредитных карт через HTTP делала их уязвимыми для кражи: любой, кто находился между вами и сервером, мог получить данные вашей карты. Компания Netscape увидела в этом возможность для бизнеса, если они смогут найти безопасный способ сделать передачи, используя свой браузер и сервер. Это было бы полезно и для компании и для успеха Интернета в целом.

Они решили создать SSL, протокол для создания безопасного канала между клиентом и сервером, по которому затем можно было бы запускать HTTP. Они назвали эту комбинацию HTTPS.

Первоначально протокол рассматривался как средство для кредитных карт. Например:

Использование Netscape обойдется 1495 долларов за сервер начального уровня; добавление возможности обработки безопасных переводов по кредитным картам увеличивает цену до 5000 долларов

The rise of Netscape, июль 1995 г

Позже в том же году, когда была обнаружена уязвимость в протоколе, сообщалось только о влиянии на кредитные карты:

Проблема в Netscape Navigator была обнаружена двумя аспирантами первого курса информатики Калифорнийского университета в Беркли. Они заявили, что злоумышленник может менее чем за минуту проникнуть в систему кодирования программного обеспечения и получить доступ к данным кредитной карты

Netscape: Internet security flaw can be fixed, сентябрь 1995

И:

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

The New Watchdogs of Digital Commerce, октябрь 1995

Трудно копать в историю конца 1990-х и начала 2000-х, поскольку очень много мертвых сайтов и сломанных URL, но есть одно место, где я смотрел, чтобы увидеть хоть что-то — это были руководства старого программного обеспечения. К сожалению, поставщики, кажется, были очень осторожны, давая конкретные советы о том, какого рода страницы нуждаются в HTTPS. Вместо этого мы получаем такие вещи, как списки рассылок об администрировании программного обеспечения, говорящие:

Если безопасность является проблемой, рассмотрите вопрос о безопасности доступа к серверам LISTSERV Maestro с шифрованием, тогда злоумышленники не смогут прослушивать соединение между браузером и сервером и не смогут получать информацию об обмене данными или шпионить за паролями.

Securing Access With SSL, май 2002

К 2004 году HTTPS описывался как используемый для безопасных web-сайтов для онлайн-банкинга, торговли акциями и розничной торговли, а пользователей, как правило, учили, что они должны были увидеть https:// в URL для своего банка или при покупке вещей в интернет-магазинах, но не в других местах. Например, вот некоторые советы из 2005 года о форумах, которые имели авторизацию, но не поддерживали HTTPS:

Большинство досок объявлений и других сайтов, на которых есть возможность стать пользователем, не обрабатывают вашу информацию на входе в систему на безопасносном уровне, что означает, что она не зашифрована, и любой, кому удастся перехватить пакеты данных, может прочитать ее. Значит ли это, что вы никогда не должны использовать такие сайты? Нет. Это означает, что вы должны иметь пароль для небезопасных сайтов, который отличается от паролей, используемых для банковских операций и операций по кредитным картам, или чего-то еще, что требует безопасности.

Should I provide passwords at unsecure sites? май 2005

Похоже, что примерно в это же время стало обычной практикой использовать HTTPS для входа в систему, даже если остальная часть сайта была только HTTP. Например, в 2006 году страница Википедии, посвященная HTTPS, была отредактирована и было добавлено, что помимо «платежных транзакций» HTTPS также широко используется для «корпоративного входа в систему».

Затем мы сделали шаг назад: сайты поняли, что могут размещать формы входа на своих домашних страницах, не обслуживая домашнюю страницу как HTTPS, установив форму POST для конечной точки HTTPS:

После многих лет обучения клиентов доверять только сайтам с поддержкой SSL, банки перемещают свои формы входа в онлайн банк на незашифрованные домашние страницы своих веб-сайтов. Хотя данные шифруются, как только пользователь нажимает на кнопку “Войти”, практика идет вразрез с многолетними ожиданиями клиентов, а также целями создателей браузера. Три из пяти крупнейших банков США в настоящее время отображают регистрационные формы на домашних страницах, не использующих SLL, включая Bank of America, Wachovia и Chase, а также финансовые услуги гиганта American Express. Кроме того, на веб-сайтах Bank of America размещаются анкеты.
…
Учитывая это, многие банки, использующие авторизацию на главной странице, включают ссылку на информацию о безопасности. “Находясь на нашей главной странице, вы можете заметить, что в вашем браузере не отображаются некоторые знакомые индикаторы, подтверждающие безопасность всей страницы.”, Bank of America отмечает в своей заметке о безопасности, доступ к которой осуществляется, нажав значок на форме входа. “Эти индикаторы включают в себя значок ‘замочка’ в правом нижнем углу кадра браузера и ‘s’ в строке URL браузера (например, ‘https’). Чтобы обеспечить самый быстрый доступ к нашей домашней странице для всех наших миллионов клиентов и других посетителей, мы сделали вход в онлайн-банкинг безопасным, не делая всю страницу безопасной. Пожалуйста, будьте уверены, что ваши ID и пароль безопасны и что только Банк Америки имеет доступ к ним.”

Banks Shifting Logins to Non-SSL Pages

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

В 2009 году это было распространено:

Некоторые крупные веб-сайты - такие, как Facebook, Vox и другие (но не Metafilter!) - заставляло вводить пользователям имя и пароль на http странице, а не на https странице. Это так же безопасно, как вход в систему через https:// и если так, то почему?

Are login boxes on HTTP pages secure? декабрь 2009

Примерно в это время Gmail ввела возможность всегда использовать HTTPS для вашей учетной записи:

Мы используем https для защиты вашего пароля каждый раз, когда вы входите в Gmail, но мы не используем https, если вы не попросите об этом (посетив https://mail.google.com вместо http://mail.google.com). Почему нет? Потому что недостатком является то, что https может сделать вашу почту медленнее. Ваш компьютер должен проделать дополнительную работу, чтобы расшифровать все эти данные, и зашифрованные данные не распространяются через Интернет так же эффективно, как незашифрованные данные. Поэтому мы оставляем выбор за вами.
…
Мы добавили опцию в Настройки, чтобы всегда использовать https. Если вы не будете регулярно регистрироваться через незашифрованные беспроводные соединения в кофейнях, аэропортах или общежитиях колледжей, то вам может не понадобиться этот дополнительный уровень безопасности. Но если вы хотите всегда использовать HTTPS, то эта настройка это делает супер легко.

Making Security Easier, июль 2008

[Разглашение: Я работаю на Google, хотя этот пост не связан с рабочим проектом]

И они сделали HTTPS по умолчанию полтора года спустя:

Если вы доверяете безопасности вашей сети и не хотите, чтобы по умолчанию https был включен из соображений производительности, вы можете отключить его в любое время, выбрав “Не всегда использовать https” в меню Настройки. Gmail всегда шифрует страницу входа, чтобы защитить ваш пароль. Пользователи Google Apps, администраторы которых еще не сделали по умолчанию все свои домены на https, будут иметь такую же возможность.

Default https access for Gmail январь 2010

В 2010 году они также добавили поддержку HTTPS для поиска

Несколько лет назад Google добавила шифрование SSL к продуктам от Gmail до Google Docs и других, и мы продолжаем включать шифрование на большее количество услуг. Подобно банковским сайтам и сайтам электронной коммерции, шифрование Google распространяется не только на пароли для входа в систему, но и на весь сервис. Шифрование всей сессии является значительным преимуществом конфиденциальности по сравнению с системами, которые шифруют только страницы входа в систему и информацию о кредитной карте.
…
при поиске с помощью SSL, вы не увидите ссылок на такие страницы как Поиск изображений или Карты, которые, по большей части, не поддерживают SSL в данный момент. Кроме того, поскольку SSL-соединения требуют дополнительного времени для настройки шифрования между вашим браузером и удаленным веб-сервером, ваш пользовательский опыт поиска по SSL может быть немного медленнее, чем ваш обычный поиск.

Search more securely with encrypted Google web search май 2010

Размещения (deployments), при которых сайт поддерживал HTTPS, но не обслуживал его, если вы явно не решили его использовать, существовали, по крайней мере, с момента запуска Gmail в 2004 году, но это было масштабное событие, побудившее к созданию браузерного расширения HTTPS Everywhere:

Сегодня EFF и Tor Project запускают публичную бета-версию нового расширения Firefox под названием HTTPS Everywhere. Это расширение Firefox было вдохновлено запуском опции шифрованного поиска Google. Нам нужен был способ гарантировать, что каждый запрос на поиск, отправляемый нашими браузерами, будет зашифрован. В то же время мы смогли зашифровать большинство или местами даже все сообщения браузера и для некоторых других сайтов: [список сайтов]

Encrypt the Web with the HTTPS Everywhere Firefox Extension, июнь 2010

Это расширение содержало список сайтов, которые предоставляли версии HTTPS, а также regexps для перехода от HTTP-адреса к HTTPS-адресу. Это не всегда было так просто, как добавить к протоколу ‘s, так как многие сайты привыкли делать такие вещи, как http://en.wikipedia.org для HTTP, но https://secure.wikimedia.org/wikipedia/en для HTTPS. Их FAQ описывает их мышление:

В. Что, если сайт не поддерживает HTTPS или поддерживает его только для некоторых видов действий, например, для ввода информации о кредитной карте?

О. Вы можете попытаться связаться с сайтом и отметить, что использование HTTPS для всех функций сайта в настоящее время становится все более распространенной практикой и защищает пользователей (и сайты) от различных интернет-атак. Например, он защищает от того как другие люди в сети Wi-Fi шпионят за использованием вами конкретного сайта или даже мешает возможности завладеть вашей учетной записью. Вы также можете указать, что номера кредитных карт — не единственная информация, которую вы считаете частной или конфиденциальной.

Такие сайты, как Google, Twitter и Facebook, теперь поддерживают HTTPS для нефинансовой информации — по общим соображениям конфиденциальности и безопасности.

HTTPS Everywhere FAQ, июнь 2010

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

В течение десятилетия люди переключались с проводного подключения к Интернету на беспроводное. Люди стали чаще подключаться к Wi-Fi в общественных местах, таких как кафе, и это изменило уровень безопасности HTTP. Вместо того, чтобы нападать на интернет-провайдер или промежуточную сеть, злоумышленнику понадобилось просто слушать то, что отправляется в открытом доступе через WiFi. Использование HTTPS только для входа в систему с последующей отправкой файлов cookie аутентификации в открытом виде при каждом запросе никогда не было безопасным, но теперь его можно было легко использовать. Тем не менее пользователи и компании в большинстве не беспокоились об этом.

Затем в октябре 2010 вышел Firesheep. Это был активный эксплойт, упакованный как простое в использовании расширение Firefox. Любой желающий мог спуститься в местную кофейню, открыть Firesheep, перехватить HTTP Cookies пользователей и выдать себя за них на Facebook, Twitter и т.д. Автор Firesheep писал:

Единственным эффективным исправлением [для перехвата сессии] является полное сквозное шифрование, известное в Интернете как HTTPS или SSL. Facebook постоянно выкладывает новые функции “приватности” в бесконечной попытке подавить крики несчастных пользователей, но какой смысл, когда кто-то может просто полностью взять контроль над учетной записью? Twitter заставил всех сторонних разработчиков использовать OAuth, а затем немедленно выпустил новую версию своего небезопасного сайта. Когда дело доходит до конфиденциальности пользователей, SSL как слон в посудной лавке.

Firesheep, октябрь 2010 года

Компании поспешили предложить хотя бы опцию HTTPS, и Facebook объявил о неавтоматической настройке в январе 2011 года, а также поставил цель в какой-то момент использовать HTTPS по умолчанию:

Начиная с сегодняшнего дня мы предоставим вам возможность испытать Facebook полностью по HTTPS. Вам следует рассмотреть возможность включения этого варианта, если вы часто используете Facebook из точек доступа к Интернету в общественных кафе, аэропортах, библиотеках или школах.
…
Есть несколько вещей, которые вы должны иметь в виду, прежде чем решить включить HTTPS. Зашифрованные страницы загружаются дольше, поэтому вы можете заметить, что Facebook работает медленнее, когда использует HTTPS. Кроме того, некоторые функции Facebook, включая многие сторонние приложения, в настоящее время не поддерживаются в HTTPS. Мы будем упорно работать, чтобы решить оставшиеся проблемы. Мы медленно внедряем эту функцию в течение следующих нескольких недель, но вы скоро сможете включить эту функцию в настройках Пользователя. Мы надеемся предложить HTTPS по умолчанию, когда вы будете использовать Facebook в будущем.

A Continued Commitment to Security, январь 2011 года

Три месяца спустя Twitter добавил поддержку:

Мы добавляем настройки пользователя, которые позволяют вам всегда использовать HTTPS при доступе к Twitter.com.
…
Это повысит безопасность вашей учетной записи и улучшит защиту ваших данных, если вы используете Twitter через незащищенное подключение к Интернету, такое как общедоступная сеть Wi-Fi, где кто-то может подслушивать вашу активность на сайте. В будущем мы надеемся сделать использование HTTPS по умолчанию.

Making Twitter more secure: HTTPS, март 2011

Google уже использовал HTTPS по умолчанию для Gmail и предлагал возможность поиска по HTTPS, но поиск по умолчанию не был зашифрован. В октябре они выпустили HTTPS по умолчанию для зарегистрированных пользователей:

Поскольку поиск становится все более индивидуальным, мы признаем растущую важность защиты персонализированных результатов поиска, которые мы предоставляем. В результате мы расширяем возможности поиска по умолчанию для зарегистрированных пользователей. В течение следующих нескольких недель многие из вас будут перенаправлены на https://www.google.com (обратите внимание на дополнительные “s”), когда вы войдете в свою учетную запись Google. Это изменение шифрует ваши поисковые запросы и страницу результатов Google. Это особенно важно, когда вы используете незащищенное подключение к Интернету, такое как точка доступа Wi-Fi в интернет-кафе.

Making search more secure октябрь 2011 года

Другие поставщики услуг двигались медленнее. Например, Yahoo Mail даже не предлагала возможность всегда использовать HTTPS до конца 2012 года, когда они, очевидно, представили его без объявления. Мелкие компании, как правило, еще медленнее добавляли поддержку, если только они явно не были ориентированы на конфиденциальность или безопасность.

В июне 2013 года Эдвард Сноуден рассказал, как много шпионила США, и как много всего HTTP трафика отслеживалось. Мне кажется, что раскрытие информации действительно изменило то, как технические специалисты думали о HTTPS. До этого идея заключалась в том, что вы должны использовать HTTPS только для важных вещей (покупки, финансы, данные находящиеся в сессиях), но большинство вещей могли оставаться в поле зрения (новостные сайты, блоги, ссылки). В то время как после раскрытия информации идея о том, что в конечном итоге все должно быть по HTTPS, получила гораздо большую поддержку.

В краткосрочной перспективе компании, которые не использовали HTTPS последовательно для конфиденциальных задач, попытались внедрить его:

Теперь мы используем https по умолчанию для всех пользователей Facebook. Эта функция, которую мы впервые ввели в качестве опциональной два года назад, означает, что ваш браузер будет общаться с Facebook с помощью безопасного соединения, в котором указано “https”, а не “http”

Secure Browsing By Default, июнь 2013

Википедия написала:

Наша текущая архитектура не может работать с HTTPS по умолчанию, но мы постепенно вносим изменения, чтобы сделать это возможным. Так как мы, похоже, стали мишенью XKeyscore, мы ускорим эти усилия.

The future of HTTPS on Wikimedia projects, август 2013

А затем позже, но в том же месяце Википедия сделала это по умолчанию для пользователей, вошедших в систему.

Yahoo снова оказалась более медленной, но наконец, реализовала HTTPS в начале 2014 года:

Как мы и обещали в октябре, теперь мы автоматически шифруем все соединения между нашими пользователями и Yahoo Mail. Каждый раз, когда вы используете Yahoo Mail - будь то в Интернете, мобильной сети, мобильных приложениях или через IMAP, POP или SMTP - он на 100% зашифрован по умолчанию и защищен 2048-битными сертификатами. HTTPS Now Default in Yahoo Mail, Январь 2014

К этому моменту большинство препятствий на пути внедрения HTTPS было устранено. Вам больше не нужен IP-адрес для каждого узла [1], и дополнительные вычисления были слишком малы, чтобы иметь значение, но сертификаты все еще раздражали. Например, это была основная причина, по которой я не предложил HTTPS на любом из моих сайтов. Let’s Encrypt был основан, чтобы исправить это:

Тогда почему мы не используем TLS (преемник SSL) везде? Каждый браузер в каждом устройстве поддерживает его. Каждый сервер в каждом дата-центре поддерживает его. Почему бы нам просто не щелкнуть выключателем?

Проблема в сертификатах сервера. Якорь для любого соединения, защищенного TLS — это сертификат с открытым ключом, который показывает, что сервер, с которым вы на самом деле коммуницируете, является сервером, с которым вы намеревались общаться. Для многих операторов серверов получение даже базового сертификата сервера является слишком большой проблемой. Процесс подачи заявки может быть запутанным. Это обычно стоит денег. Это сложно установить правильно. Это боль для обновления.

Let’s Encrypt - это новый бесплатный центр сертификации, построенный на основе сотрудничества и открытости, который позволит каждому начать работу с базовыми сертификатами сервера для своих доменов в один клик мыши.

Let’s Encrypt: Delivering SSL/TLS Everywhere, ноябрь 2014

Проект был анонсирован в ноябре 2014 года, год спустя началось публичное бета-тестирование и проект полностью открылся в апреле 2016 года. Он охватывает около 25 миллионов доменов, включая этот.

На этом этапе браузеры могут начать сильно давить на HTTPS. Поскольку они ввели новые функции, особенно те, которые влияют на безопасность, они сделали их доступными только для страниц HTTPS. (Service workers, getUserMedia, Prefer Secure Origins For Powerful New Features). В сентябре 2016 года компания Chrome объявила о планах по маркировке всех сайтов HTTP как небезопасных:

Исторически сложилось так, что Chrome не обозначал HTTP соединения как небезопасные. Начиная с января 2017 года (Chrome 56) мы будем помечать HTTP-страницы, которые собирают пароли или кредитные карты как не защищенные, как часть долгосрочного плана по маркировке всех сайтов HTTP как не защищенные.

Moving towards a more secure web, сентябрь 2016

И все идет по плану:

За последние несколько лет мы продвинулись к более безопасной сети, решительно выступая за то, чтобы сайты использовали шифрование HTTPS. В течение прошлого года мы также помогли пользователям понять, что НТТР-сайты не являются безопасными, постепенно помечая большее число НТТР-страниц как “небезопасные”. Начиная с июля 2018 года с выходом Chrome 68, Chrome будет отмечать все сайты HTTP как “небезопасные”.

A secure web is here to stay, февраль 2018

Вы можете увидеть общий рост HTTPS из отчета Google HTTPS Transparency Report:

Вы также можете увидеть рост исходя из данных Firefox, Let’s Encrypt stats:

Мы еще не там, где есть только https://, но, кажется, мы будем там в течение нескольких лет.

[1] В 2003 RFC 3456: Transport Layer Security (TLS) Extensions вышел в свет, который определил Server Name Indication (SNI):

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

RFC 3456, июнь 2003

Например, я размещаю jefftk.сом, trycontra.com, lilywise.com и несколько других сайтов на одном сервере с одним IP-адресом. Когда поступает запрос, он указывает, какой из них ему нужен в заголовке Host:

GET /index HTTP/1.1 Host: wwww.jefftk.com ...

До SNI, если бы я пытался разместить все это на HTTPS в одном IP, разговор бы начался с запроса сертификата. Но откуда мне знать, какой сертификат предоставить? Если они пытаются посетить jefftk.com, они хотят Cert A, в то время как для trycontra.com они хотят Cert B и т.д. В то время вы можете обойти это, используя различные IP-адреса для разных сайтов, и тогда вы знаете, что запрос на IP A должен получить Cert A, пока IP B должен получить Cert B. Это было дорого и неудобно, однако, и ограничивало развертывание HTTPS.

(Был другой способ сделать это, subjectAltName позволял сделать один сертификат, который был хорош для нескольких доменов. Это было бы прекрасно для моих сайтов, и на самом деле я до сих пор так обрабатываю сертификаты, но это не очень хорошо подходит для хостинг-провайдеров или кого-либо еще, у кого много доменов, которые часто меняются.)

При использовании SNI браузер включает доменное имя сайта, который он пытается посетить, когда впервые начинает настройку SSL-соединения. Это позволяет серверу выбрать правильный сертификат для обслуживания, не полагаясь на хак нескольких IP-адресов.

С другой стороны, пока браузеры, которые вы хотите поддерживать, не поддерживают SNI, вы не сможете на него переключиться. Это был очень долгий переход. Поскольку SNI обрабатывался библиотекой SSL, поддержка SNI обычно зависела от версии операционной системы. Windows XP и Android Gingerbread были двумя последними широко используемыми операционными системами, не поддерживавшими SNI, и они сохранялись долгое время. Например, в июле 2013 года и ранее Gingerbread был все еще на уровне 41%, в июле 2015 года они были на уровне 6%, и они не упали ниже 1% до июня 2017 года.