HTTP - безопасность, TLS и сертификаты

Внимание

Данный материал является частью цикла статей «Протокол HTTP». Не забудьте посмотреть другие статьи по этой теме :-)

  1. HTTP - обзор основных концепций протокола
  2. Архитектурные аспекты HTTP
  3. HTTP - идентификация клиента
  4. HTTP - механизмы аутентификации
  5. HTTP - безопасность, TLS и сертификаты
  6. HTTP справочник

Вам действительно нужен HTTPS?

Вы можете подумать: «Конечно, не все веб-сайты нуждаются в защите и безопасности». Если веб-сайт не обслуживает конфиденциальные данные или не отправляет какие-либо формы, было бы излишним покупать сертификаты и замедлять работу веб-сайта, просто чтобы получить маленькую зеленую отметку в строке URL с надписью «Защищено».

Если у вас есть веб-сайт, вы знаете, что крайне важно, чтобы он загружался как можно быстрее, поэтому старайтесь не перегружать его ненужными вещами.

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

Посмотрим, стоит ли того.

HTTPS шифрует ваши сообщения и решает проблему MITM

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

Первоначальные участники общения могут не знать, что их сообщения прослушиваются.

HTTPS решает проблему атак MITM за счет шифрования связи. Это не означает, что ваш трафик больше нельзя прослушивать. Это означает, что любой, кто прослушивает и перехватывает ваши сообщения, не сможет увидеть их содержание. Для расшифровки сообщения вам понадобится ключ. Мы узнаем, как это работает, чуть позже.

Поехали.

HTTPS как критерий ранжирования

Не так давно Google сделал HTTPS критерием ранжирования.

Что это значит?

Это означает, что если вы веб-мастер и заботитесь о позициях вашего сайта в Google, то вам обязательно следует внедрить HTTPS на своем веб-сайте. Хотя это не так эффективно, как некоторые другие критерии, такие как качественный контент и обратные ссылки, он определенно имеет значение.

Тем самым Google побуждает веб-мастеров как можно скорее перейти на HTTPS и повысить общую безопасность Интернета.

Это можно сделать совершенно бесплатно

Чтобы включить HTTPS (SSL/TLS) для веб-сайта, вам понадобится сертификат, выданный центром сертификации. До недавнего времени сертификаты были дорогостоящими, и их приходилось обновлять каждый год.

Спасибо ребятам из Let's encrypt, теперь вы можете получить очень доступные сертификаты. Серьезно, они совершенно бесплатны.

Сертификаты Let's Encrypt, которые легко устанавливаются, пользуются поддержкой крупных компаний и большим сообществом людей. Взгляните на основных спонсоров и убедитесь сами в списке компаний, которые их поддерживают. Вы можете узнать несколько

Давайте шифровать выдает только сертификаты DV (проверка домена) и не планируем выпускать сертификаты организации (OV) или сертификаты расширенной проверки (EV). Срок действия сертификата составляет 90 дней, и его легко продлить.

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

Все дело в скорости

Многие люди связывают HTTPS с дополнительными расходами на скорость. Взгляните на httpvshttps.com.

Вот мои результаты для HTTP и HTTPS:

Так что же там произошло? Почему HTTPS намного быстрее? Как такое возможно?

HTTPS - это требование для использования протокола HTTP 2.0.

Если мы посмотрим на вкладку сети, мы увидим, что в случае HTTPS изображения были загружены по протоколу HTTP2.0.

HTTP 2.0 является преемником распространенного в настоящее время HTTP / 1.1.

У него много преимуществ перед HTTP / 1.1:

  • Он двоичный, а не текстовый
  • Он полностью мультиплексирован, что означает, что он может отправлять несколько запросов параллельно через одно TCP-соединение.
  • Снижает накладные расходы за счет сжатия HPACK.
  • Он использует новое расширение ALPN, которое позволяет ускорять зашифрованные соединения
  • Это сокращает дополнительное время приема-передачи (RTT), что ускоряет загрузку вашего веб-сайта.
  • Многие другие

Браузеры не одобряют сайты без HTTPS

Если вы еще не уверены, то, вероятно, знаете, что некоторые браузеры начали вести войну с незашифрованным контентом.

Вот как это выглядело до и после версии Chrome 56.

А вот как это будет выглядеть в итоге.

Вы еще не уверены?

Переход на HTTPS сложен

Это тоже пережиток прошлых времен. Хотя переход на HTTPS может быть сложнее для веб-сайтов, которые существуют в течение длительного времени из-за огромного количества ресурсов, загружаемых через HTTP, провайдеры хостинга обычно пытаются упростить этот процесс.

Многие хостинг-провайдеры предлагают автоматический переход на HTTPS. Это может быть так же просто, как нажать одну кнопку на панели параметров.

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

Итак, это причины для перехода на HTTPS. Есть причина не делать этого?

Надеюсь, теперь я убедил вас в ценности HTTPS, и вы страстно хотите перевести свой сайт на HTTPS и понять, как это работает.

Основные концепции HTTPS

HTTPS означает безопасный протокол передачи гипертекста. Фактически это означает, что клиент и сервер обмениваются данными через HTTP, но через безопасное соединение SSL/TLS.

SSL против TLS

Термины SSL (Secure Socket Layer) и TLS (Transport Layer Security) взаимозаменяемы, но на самом деле сегодня когда кто-то упоминает SSL, они, вероятно, имеют в виду TLS.

Протокол SSL был первоначально разработан Netscape, но версия 1.0 так и не увидела свет. Версия 2.0 была представлена ​​в 1995 году, а версия 3.0 - в 1996 году, и они использовались долгое время после этого (по крайней мере, то, что считается долгим в ИТ), хотя их преемник TLS уже начал набирать обороты. Вплоть до 2014 года. Переход с TLS на SSL поддерживался серверами, и это было основной причиной Атака POODLE была настолько успешной.

После этого возврат к SSL был полностью отключен.

Если вы проверяете свой или любой другой веб-сайт с помощью инструмента Qualys SSL Labs, вы, вероятно, увидите что-то вроде этого:

Как видите, SSL 2 и 3 вообще не поддерживаются, а TLS 1.3 еще не получил широкого распространения.

Но поскольку SSL был так широко распространен, он стал знаком большинству людей, и теперь он используется практически для чего угодно. Поэтому, когда вы слышите, что кто-то использует SSL вместо TLS, это только по историческим причинам, а не потому, что они действительно имеют в виду SSL.

Теперь, когда мы разобрались с этим, я буду использовать TLS, так как он более уместен.

Итак, как клиент и сервер устанавливают безопасное соединение?

Подтверждение TLS

Прежде чем начнется реальная зашифрованная связь между клиентом и сервером, они выполняют так называемое «рукопожатие TLS».

Вот как работает рукопожатие TLS (очень упрощенно, дополнительные ссылки ниже).

Зашифрованный обмен данными начинается после установления соединения.

Фактический механизм намного сложнее, чем этот, но для реализации HTTPS вам не нужно знать все фактические детали реализации установления связи TLS.

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

Если вы хотите точно узнать, как работает TLS Handshake, вы можете найти его в RFC 2246.

На изображении подтверждения TLS сертификаты отправляются, поэтому давайте посмотрим, что представляет собой сертификат и как он выдается.

Центры сертификации

Сертификаты являются важной частью безопасного обмена данными по HTTPS. Они выдаются одним из доверенных центров сертификации.

Цифровой сертификат позволяет пользователям веб-сайта безопасно общаться при использовании веб-сайта.

Если вы, например, используете Chrome, вы можете самостоятельно проверить сертификаты, перейдя на вкладку «Безопасность» в Инструментах разработчика (F12).

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

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

С другой стороны, сертификаты расширенной проверки подтверждают, что веб-сайт контролируется юридическим лицом. Продолжаются дискуссии о том, полезны ли сертификаты EV для типичного пользователя Интернета. Вы можете распознать их по произвольному тексту слева от адресной строки. Например, при просмотре сайта twitter.com вы можете увидеть:

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

Цепочки сертификатов

Так почему же ваш браузер доверяет сертификату, который сервер отправляет обратно? Любой сервер может отправить часть цифровой документации и заявить, что это именно то, что вы хотите.

Вот тут и пригодятся корневые сертификаты. Обычно сертификаты связаны цепочкой, и корневой сертификат - это тот сертификат, которому ваша машина неявно доверяет.

Самый низкий из них - это сертификат моего домена, который подписан сертификатом, расположенным над ним, и так далее… Пока не будет достигнут корневой сертификат.

Но кто подписывает корневой сертификат, вы можете спросить?

Выдан: AddTrust External CA Root, Выдан: AddTrust External CA Root.

И ваша машина, и ваши браузеры имеют список доверенных корневых сертификатов, на которые они полагаются, чтобы гарантировать, что домен, который вы просматриваете, является доверенным. Если цепочка сертификатов по какой-либо причине нарушена (это случилось со мной, потому что я включил CDN для своего блога), ваш сайт будет отображаться как небезопасный на некоторых машинах.

Вы можете проверить список доверенных корневых сертификатов в Windows, запустив диспетчер сертификатов, нажав кнопку Windows + R и набрав certmgr.msc. Затем вы можете найти доверенные сертификаты компьютера в разделе «Доверенные корневые центры сертификации». Этот список используется Windows, IE и Chrome. Firefox же, с другой стороны, управляет собственным списком.

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

Слабые стороны HTTPS

HTTPS может создавать ложное ощущение безопасности, если серверная часть сайта не реализована должным образом. Существует множество различных способов извлечения информации о клиентах, и многие сайты пропускают данные, даже если они используют HTTPS. Помимо MITM существует множество других механизмов для получения конфиденциальной информации с веб-сайта.

Другая потенциальная проблема заключается в том, что веб-сайты могут иметь HTTP-ссылки, даже если они работают по HTTPS. Это может быть шансом для атаки MITM. При переносе веб-сайтов на HTTPS это может остаться незамеченным.

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

Заключение

На этом завершается серия статей по HTTP. Мы надеемся, что вы извлекли из этого что-то полезное и поняли некоторые концепции, которых раньше не понимали или не могли понять.