Основные защищенные протоколы

Итак, в этой части мы кратко расскажем про основные протоколы, используемые на прикладном, транспортном и уровне представления в модели OSI.

  • Интерфейс – набор примитивных операций, которые нижний уровень предоставляет верхнему.
    Протокол – правила и соглашения, используемые для связи уровня N одного компьютера с уровнем N другого компьютера.

HTTP

HyperText Transfer Protocol — клиент-серверный протокол прикладного уровня для передачи гипертекста. В нем описаны правила передачи данных в интернете. HTTP использует TCP обычно через порт 80, для отправки и получения пакетов данных через Интернет. Грубо говоря, он помогает браузеру загружать веб-страницы, а серверу — получить информацию, которую пользователь ввёл на сайте.

Структура протокола HTTP определяет, что каждое сообщение состоит из трёх частей, которые передаются в следующем порядке:

  1. Стартовая строка — определяет тип сообщения;
  2. Заголовки — характеризуют тело сообщения, параметры передачи и прочие сведения;
  3. Тело сообщения — непосредственно данные сообщения.

Cтартовая строка является обязательным элементом, так как указывает на тип запроса/ответа, заголовки и тело сообщения могут отсутствовать.

Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:
Метод URI HTTP/Версия протокола

Стартовая строка ответа сервера имеет следующий формат:
HTTP/Версия КодСостояния [Пояснение]

GET / HTTP/1.1
Host: some_site.ru
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: close
Cookie: HACKYOUSPB=LOLHACK; autoupdate=1; _ga=GA1.2.495064126.158268; _gid=GA1.2.137093.1583021268; _gat_gtag_UA_163559_8=1
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

Клиент отправляет сообщение с запросом на HTTP-сервер, на котором размещен веб-сайт, затем сервер отвечает ответным сообщением. Ответное сообщение содержит информацию о состоянии завершения, например «HTTP/1.1 200 OK».

HTTP/1.1 200 OK
Server: nginx/1.12.1
Date: Sun, 01 Mar 2020 00:08:18 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 4088
Connection: close
X-Powered-By: PHP/5.5.9-1ubuntu4.20
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding

<!DOCTYPE html>
<html>
  <head>
    <meta charset='utf-8' />
    <meta http-equiv='Content-Type' content='text/html; charset=utf-8' />
    <title>some_site</title>
    <link rel='stylesheet' href='#' type='text/css' />
    <script type='text/javascript' src='#'></script>
  </head>
  <body>
    lol
  </body>
</html>

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

  • 1xx - информационные (сервер продолжает обработку запроса)
  • 2xx - успешная обработка запроса
  • 3xx - перенаправление запроса
  • 4xx - ошибка на стороне клиента
  • 5xx - ошибка на стороне сервера

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

HTTPS

Для решения проблемы http был введен Hypertext Transfer Protocol Secure, чтобы сначала установить безопасный сеанс между сервером и браузером. Фактически https не является сомостоятельным протоколом - это http + протокол шифрования (обычно используется ssl и/или tls).

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

Также в отличие от http https работает на транспортном уровне и использует по дефолту 443-й порт, а не 80-й. Вот и все отличия https от http:)

SSL

Secure Sockets Layer — криптографические протоколы, обеспечивающие защищенную передачу данных в сети по средством шифрования связи между клиентом-сервером/сервером-сервером.

SSL изначально был разработан в 1990-х годах компанией Netscape для добавления его в их браузер Netscape Navigator для безопасного взаимодействовия с серверами компании.

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

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

Таким образом, в 1995 году вышла версия 2.0 SSL, работающая поверх TCP на транспортном слое, а также предоставляющая TCP-подобный интерфейс для приложений более высокого уровня.

Протокол делится на два уровня подпротоколов:

  1. Протокол записи (record protocol)
  2. Уровень протокола подтверждения подключения (handshake protocol layer)

Уровень протокола подтверждения подключений в свою очередь состоит из трех протоколов:

  1. Протокол рукопажатия (handshake protocol)
  2. Протокол изменения параметров шифра (Change-cipher spec protocol)
  3. Протокол оповещения (Alert protocol)

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

  1. На первой фазе клиент и сервер обмениваются "hello"-пакетами для инициирования сеанса. Эти пакеты содержат наборы алгоритмов шифрования и версию протокола.
  2. Сервер отправляет свой сертификат с открытым ключом, а затем отправляет пакет "server-hello-done".
  3. На этой фазе клиент проверяет сертификат с сервера на подлиность. Сертификаты сервера соответствуют стандарту сертификата X.509, определенному стандартами шифрования с открытым ключом и выдаются центром сертификации (CA). Клиент сверяет данные полученные с центра сертификации с полученными в результате расшифровки отпечатка полученного с сервера сертификата. Если оно совпадает, то все ок. После чего клиент в свою очередь посылает пару сертификат и ключ, если это требует сервер.
  4. Происходит измение шифров. Рукопожатие завершается откправкой “finished”-пакетов.

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

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

Протокол записи принимает сообщения, которые нужно передать, фрагментирует данные в управляемые блоки, сжимает данные, применяя MAC (message authentication code), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента.

TLS

После версии SSL 3.0 различные компании начали разработку собственных протколов безопасности транспортировки. Во избежание кучи протоколов, с которыми всем бы пришлось работать, в 1999 году IETF (Internet Engineering Task Force) выпустили и стандартизировали TLS 1.0 (Transport Layer Security). Актуальная на данный момен версия протокола 1.3 выпущенная в 2018 году.

Общий принцип работы у TLS такой же, как и у SSL и в нем нет принципиальной разницы.

Протокол TLS делится на два слоя: TLS Record и TLS Handshake.

Подтверждение связи (handshake)

  1. Клиент посылает сообщение ClientHello, указывающее версию SSL или TLS и поддерживаемые клиентом методы шифрования (CipherSuite). Это сообщение также содержит случайное число (набор байт), которое используется в последующих вычислениях. Протокол также позволяет указать поддерживаемые клиентом методы сжатия данных.
  2. Сервер отвечает сообщением ServerHello, которое содержит метод шифрования, выбранный сервером из списка, предложенного клиентом, а также идентификатор сессии и еще одно случайное число. Также сервер посылает свой цифровой сертификат. Если серверу нужен сертификат для аутентификации клиента, на этом шаге он может послать клиенту запрос такого сертификата.
  3. Клиент проверяет сертификат сервера.
  4. Клиент отправляет случайное число, которое клиент и сервер используют для шифрования последующих сообщений. Сама строка из байт шифруется публичным ключом сервера.
  5. Если сервер потребовал у клиента сертификат, клиент отсылает набор байт, зашифрованный его секретным ключом, и свой цифровой сертификат, или оповещение об отсутствии сертификата.
  6. Сервер проверяет сертификат клиента.
  7. Клиент и сервер отправляют друг другу сообщение ChangeCipherSpec, объявляя об изменении режима передачи данных с незащищенного на защищенный.
  8. Клиент отправляет сообщение Finished, зашифрованное секретным ключом, и таким образом завершает подтверждение связи со своей стороны.
  9. Аналогичные действия производит сервер.
  10. На протяжении данной сессии клиент и сервер могут обмениваться сообщениями, зашифрованными секретным ключом.

Протокол записи (record)

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

  • Разбиение исходящих сообщений на блоки нужного размера и "склеивание" входящих сообщений.
  • Сжатие исходящих сообщений и распаковку входящих (используется не всегда).
  • Применение кода аутентификации к исходящим сообщениям и проверку входящих с помощью MAC.
  • Шифрование исходящих сообщений и дешифровку входящих.

После обработки протоколом TLS Record зашифрованные данные передаются на слой TCP для передачи.

Состав пакета записи:

    Так для чего собственно был нужен TLS, и в чем его отличие?!

    В последней версии SSL было и остается достаточно много дыр в безопасности, которые находят в нем до сих пор. Позже расскажу мб про уязвимость poodle нашумевшую в свое время. (она правда затрагивает и tls первых версий, но не столь важно)

    Основные отличия:

    • В TLS используется HMAC, работающий с любой хэш-функцией, а не только с MD5 или SHA, как в SSL.
    • В SSL проверка сертификата требует передачи сложной последовательности сообщений; в TLS информация о проверке полностью передается в сообщениях во время handshake.
    • SSL поддерживает только алгоритмы RSA, Diffie-Hellman и Fortezza/DMS. В TLS отказались от поддержки Fortezza/DMS.

    SSH

    Шифрование данных

    Существует два основных способа шифрования данных: симметричное(с общим секретным ключом) и асимметричное(с использованием пубоичного ключа).

    Симметричное

    При шифровании секретным ключом используется один и тот же ключ для шифрованных данных. Если стороны хотят обменяться зашифрованными сообщениями в безопасном режиме, то у обеих сторон должны быть одинаковые симметричные ключи. Такой тип шифрования используется для большого объёма данных. Обычно используется алгоритм AES со 128-битным ключом (АНБ США используют 256-битную версию алгоритма)

    Асимметричное

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

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

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

    Аутентификация

    Аутентифицированный сервер должен предоставить допустимый сертификат клиенту. Каждая сторона отвечает за проверку того, что сертификат другой стороны ещё не истек и не был отменен.

    Главная цель процесса обмена ключами — это создание секрета клиента (pre_master_secret), известного только клиенту и серверу. Секрет (pre_master_secret) используется для создания общего секрета (master_secret). Общий секрет необходим для того, чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (message authentication code) и сообщения «finished». Отсылая сообщение «finished», стороны указывают, что они знают верный секрет (pre_master_secret).

    Открытый ключ может содержаться в сертификате сервера или может быть использован временный ключ RSA, который посылается в сообщении обмена ключами от сервера. Сигнатура содержит текущее значение сообщения Client_Hello.random, таким образом, старые сигнатуры и старые временные ключи не могут повторяться. Сервер может использовать временный ключ RSA только однажды для создания сессии. После проверки сертификата сервера клиент шифрует секрет (pre_master_secret) при помощи открытого ключа сервера. После успешного декодирования секрета (pre_master_secret) создается сообщение «finished», тем самым сервер демонстрирует, что он знает частный ключ, соответствующий сертификату сервера.

    Когда RSA используется для обмена ключами, для аутентификации клиента используется сообщение проверки сертификата клиента. Клиент подписывается значением, вычисленным из master_secret и всех предшествующих сообщений протокола рукопожатия. Эти сообщения рукопожатия содержат сертификат сервера, который ставит в соответствие сигнатуре сервера сообщение Server_Hello.random, которому ставит в соответствие сигнатуру текущему сообщению рукопожатия.

    Уязвимости и векторы атак

    *тут пара слов про mitm и о том, что существует достаточно много типов атак, но почти все они так или инчае сводятся к типам mitm*

    *пара слов об одной уязвимости какой-то, например poodle*