HTTPS - безопасный HTTP

Протокол HTTPS

В прошлых статьях (”Основы HTTP” и “Практика HTTP”) мы уже говорили про протокол http, и даже пробовали выполнять http-запросы. В этой статье мы затронем тему безопасности и шифрования протокола.

Проблемы HTTP

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

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

SSL/TLS

Давайте немного погрузимся в протоколы шифрования.

SSL (англ. Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, который подразумевает безопасное соединение по сети. Он использует асимметричную шифрование для аутентификации ключей обмена, симметричное шифрование для сохранения конфиденциальности, коды аутентификации сообщений и т.д. После обнаружения уязвимости в 2014 году SSL должен быть исключён из работы в пользу протокола TLS

TLS (англ. transport layer security — Протокол защиты транспортного уровня), - это криптографический протокол, основанный на SSL и обеспечивающий защищённую передачу данных между узлами в сети Интернет. TLS, как и SSL, использует асимметричное шифрование для аутентификации, симметричное шифрование для конфиденциальности и коды аутентификации сообщений для сохранения целостности сообщений.

Как можно понять из названия, протокол TLS работает между транспортным и прикладным уровнем сетевой модели OSI. Шифрование данных происходит после формирования HTTP-запроса, в момент его отправки.

Установка соединения с TLS

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

Разберём подробнее каждый шаг данной процедуры:

Так как TLS работает над TCP, для начала между клиентом и сервером устанавливается TCP-соединение.
После установки TCP, клиент посылает на сервер спецификацию в виде обычного текста (а именно версию протокола, которую он хочет использовать, поддерживаемые методы шифрования, etc).
Сервер утверждает версию используемого протокола, выбирает способ шифрования из предоставленного списка, прикрепляет свой сертификат и отправляет ответ клиенту (при желании сервер может так же запросить клиентский сертификат).
Версия протокола и способ шифрования на данном моменте считаются утверждёнными, клиент проверяет присланный сертификат и инициирует либо RSA, либо обмен ключами по Диффи-Хеллману, в зависимости от установленных параметров.
Сервер обрабатывает присланное клиентом сообщение, сверяет MAC, и отправляет клиенту заключительное (‘Finished’) сообщение в зашифрованном виде.
Клиент расшифровывает полученное сообщение, сверяет MAC, и если всё хорошо, то соединение считается установленным и начинается обмен данными приложений.

Ассиметричное шифрование

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

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

Клиент и сервер используют свои собственные закрытые ключи (каждый – свой) и опубликованный открытый ключ для создания общего секретного ключа на сессию.

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

Одним из наиболее распространенных подходов является алгоритм обмена ключами Диффи — Хеллмана (DH). Этот алгоритм позволяет клиенту и серверу договориться по поводу общего секретного ключа, без необходимости передачи секретного ключа по соединению.

Алгоритм Диффи-Хеллмана (осторожно, математика)

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

Пусть им обоим известны два числа g и p, которые не являются секретными.
Для того, чтобы создать неизвестный никому ключ, оба участника переписки также генерируют большие случайные числа a и b.
Затем Андрей вычисляет остаток от деления

и пересылает его Дмитрию, а Дмитрий вычисляет остаток от деления

и передаёт его Андрею.

Далее Андрей на основе своего числа a и полученного B вычисляет

а Дмитрий на основе своего числа b и полученного по сети A вычисляет

Таким образом, у обоих партнёров получается одно и то же число, а злоумышленник встречается с почти неразрешимой (за разумное время) проблемой вычисления

если числа p, a и b выбраны достаточно большими.

В практических реализациях для a и b используются числа порядка 10^100 и p порядка 10^300

Симметричное шифрование

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

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

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

Алгоритм Диффи-Хеллмана позволяет двум сторонам получить закрытый секретный ключ. Но откуда обе стороны могут быть уверены в том, что разговаривают действительно друг с другом? Что если при осуществлении обмена DH-ключами окажется, что запрос был перехвачен, и общение происходит со злоумышленником? Нам нужно быть уверенными, что мы общаемся именно с тем, с кем необходимо. Эту проблема решает инфраструктура открытых ключей (Public key infrastructure, PKI). В основе PKI лежит использование криптографической системы с открытым ключом и несколько основных принципов:

Закрытый ключ (private key) известен только его владельцу;
Удостоверяющий центр (УЦ или CA - Certificate Authority) создает электронный документ — сертификат открытого ключа, таким образом удостоверяя факт того, что закрытый ключ известен эксклюзивно владельцу этого сертификата, открытый ключ свободно передается;
Никто не доверяет друг другу, но все доверяют удостоверяющему центру;
Удостоверяющий центр подтверждает или опровергает принадлежность открытого ключа заданному лицу, которое владеет соответствующим закрытым ключом.

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

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

Чтобы сертификату доверял любой веб-браузер, он должен быть подписан аккредитованным удостоверяющим центром (центром сертификации, Certificate Authority, CA). CA – это компании, выполняющие ручную проверку, того что лицо, пытающееся получить сертификат, удовлетворяет следующим двум условиям:

Является реально существующим;
Имеет доступ к домену, сертификат для которого оно пытается получить.

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

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

Вывод

HTTPS - это протокол HTTP, использующий шифрование с помощью протокола TLS. Мы узнали, по каким принципам шифруется трафик, как устанавливается соединение и как всё это подтверждает центр сертификации.

Используемые источники:

Спасибо за внимание. С вами был Flex Code.