Добрый день! Возник у меня как-то вопрос, как простыми словами объяснить работу HTTPS-протокола, почему он безопасен и можно ли ему полностью доверять. Давайте попробуем разобраться вместе.
Я сетевой инженер в большой компании, пишу статьи про сетевое оборудование, сетевые технологии и околоАЙТИшные темы. Рассматриваю возможности разного оборудования, вместе с вами продолжаю изучать разный функционал и привожу конкретные примеры того, что сделано и как сделано. Это не призыв к действию и не точный мануал - в моих статьях бывают ошибки, которые я всегда готов обсудить в комментариях. Прошу следовать правилам платформы, не нарушать законодательство РФ, не оскорблять других людей и все будет норм!
Моя тележка - добро пожаловать!
HTTP (HyperText Transfer Protocol) — протокол передачи гипертекста. Это протокол прикладного уровня (L7 OSI, TCP 80) передачи данных, изначально — в виде гипертекстовых документов в формате HTML, в настоящее время используется для передачи произвольных данных. Учитывая его изначальную идею создания, основными реализациями клиентов протокола являются браузеры и главнейшая его задача - получение информации с веб-сайтов. И все было бы хорошо, если бы не было так плохо... HTTP подразумевался, как протокол отображения веб-страниц, а страницы задумывались, прежде всего, как онлайн реклама организаций, описание рода задач, история компании и онлайн прайс услуг, в которой скрывать было нечего. Это уже позже начали появляться идеи о создании онлайн чатов, форумов, текстовых блогов (типа livejournal, 1999) и т.п., где вопросы безопасности начали играть более существенную роль.
Первый интернет-банкинг был создан в 1995 году банком Security First Network Bank. Но из-за сильного недоверия со стороны потенциальных клиентов, которые, в те времена, не очень-то доверяли такому новшеству - он прекратил свою деятельность несколько лет спустя. Далее только в 2001 первым банком, достигшим успеха в онлайн-банкинге, стал Bank of America, база пользователей этой услугой превысила 2 млн клиентов. Чтобы понять насколько это было давно, давайте рассмотрим еще несколько параллельных событий из мира World Wide Web. Самая первая зарегистрированная страничка в интернет и браузер, способный ее открыть, были придуманы в 1990 году Тимоти Джоном Бернесом-Ли, сотрудником Европейского Центра по ядерным исследованиям (CERN). А уже в 1997 была запущена поисковая система Яндекс, и годом позже Google (ага, Яндекс старше Гугла и всех их старше Рамблер - 1996). В 2001 году Microsoft выпускает Windows XP со встроенным браузером Internet Explorer 6, который фактически познакомил мир с интернетом и подтолкнул к развитию данной сферы. В 2005 появляется YouTube, в 2006 Facebook (внутри сети Гарварда работал с 2004, является запрещенной в РФ частью организации Meta) и VKontakte... Не сказать, что инженеры не осознавали проблем с безопасностью технологии HTTP, так как еще в 1994 компанией Netscape Communications был разработан протокол HTTPS для браузера Netscape Navigator (привет олдфагам!).
HTTPS (HyperText Transfer Protocol Secure) — это расширение для протокола HTTP с поддержкой шифрования в целях повышения безопасности. Данные в протоколе HTTPS передаются поверх криптографических протоколов TLS или устаревшего в 2015 году SSL. В отличии от HTTP с TCP-портом 80, для HTTPS по умолчанию используется TCP-порт 443. HTTPS не является отдельным протоколом - это обычный HTTP, работающий через шифрованные транспортные механизмы SSL и TLS. Он обеспечивает защиту от атак, основанных на прослушивании сетевого соединения - от снифферских атак и атак типа MITM (man-in-the-middle), при условии, что будут использоваться шифрующие средства и сертификат сервера проверен.
Теперь, давайте на пальцах разберемся, как это работает. Начнем с HTTP. Мы заказываем доставку еды домой: отправляем заказ и ждем, когда курьер принесет еду. А потом проверяем все ли он принес из того, что мы заказывали. HTTPS делает все тоже самое, только с одноразовыми наклейками на пакете, которые гарантируют, что курьер не вскрывал пакет, который собрали для нас. Роль данной наклейки выполняет SSL-сертификат, который наш браузер проверяет в момент входа на какой-либо сайт. Сайт ему сообщает свой сертификат, а наш браузер запрашивает у глобального центра сертификации проверку его валидности. Если сертификат валидный, то браузер продолжает работу и открывает страницу дальше, если нет, то пишет что сайт не является надежным и просит его не использовать. Но как проходит сам механизм обмена закрытыми ключами?! Я где-то натыкался на более логичное объяснение с аналогией посылок: сначала мы отправляем посылку-ящик, которая закрыта нашим ключом, серверу получателю. Далее сервер на эту посылку вешает свой замок и отправляет обратно, не трогая наш. Когда мы получим посылку с двумя замками, то снимаем свой и отправляем серверу обратно только с его замком, который он сможет снять сам и получить нашу посылку. А внутри будет наш уникальный ключ (который рандомно генерируется при каждом входе и содержит не менее 100 букв, цифр и символов), по которому наш браузер и будет ожидать от сервера шифрованных данных. Данная схема работы называется two-way authentication. Расшифровать данные можно только этим уникальным ключом и даже если кто-то перехватит наш трафик, то расшифровать его будет довольно проблематично и накладно, а когда это удастся, то и данные уже потеряют свою актуальность. А еще, вы замечали, что когда вы совершаете онлайн оплату где-либо и всплывает окно подтверждения вашего банка, то оно как-будто притормаживает, открывается медленно и неспешно, хотя там одна малюсенькая картиночка? Это просто данная страничка работает на максимальном уровне безопасности для вашего браузера и шифруется очень длинными ключами шифрования.
В настоящее время трудно встретить сайт без замочка HTTPS в адресной строке. HTTPS стал стандартом, и большинство сайтов априори используют именно защищенное соединение. Этому есть несколько причин, из которых защита пользовательских данных стоит далеко не на первом месте. Это и повышение доверия посетителей, и отсутствие надписи "Не защищено" в браузерах, и маркетинг. Но есть и недостаток - соединение по HTTPS медленнее, чем по HTTP. Это замедляет загрузку сайта, что может даже оказать обратный эффект для организации (например, интернет-провайдера), ведь скорость сайта является более значимым фактором ранжирования, чем наличие HTTPS. Как мы уже выяснили, так называемое SSL/TLS-рукопожатие, вызывает согласование сессии и обмен ключами шифрования. Т.е. до 8 раз в (TLS 1.2 и ниже) должны данные пролететь всё расстояние между вами и сервером перед тем, как вы только начнёте загружать нужную страницу, да ещё с перерывами на обработку шифрования. В TLS 1.3 таких хопов (hop) уже всего 6, но все еще больше, чем в оригинальном HTTP - там их 4.
В качестве вывода хочу обозначить несколько моментов. 15 лет назад был представлен первый айфон с браузером Safari. 12 лет назад был предложен адаптивный дизайн сайтов, который отображал сайт на экране компьютера и мобильного устройства одинаково, опираясь только на диагональ экрана. 2 года назад Adobe закрыла направление Flash, признав его не перспективным и подтолкнув мир в формат HTML5. Все, существующие сегодня механизмы, проходят жесткую конкуренцию и рынок оставляет лучшее (хотя не всегда это так), чтобы дальше у нас было, как у Олимпийцев: быстрее, выше, сильнее...
Спасибо за прочтение, надеюсь, было интересно и познавательно. Как обычно: прошу Вас поддержать статью лайком, автора канала подпиской, а друг друга можно поддержать в комментариях, где можно поностальгировать и выложить старые картинки всем знакомых сайтов или забавную историю. Спасибо, еще раз и удачи!