1.6. Как работает HTTPS и шифрование в SSL/TLS

 

Для чего нужен HTTPS

Безопасное соединение по HTTP осуществляется благодаря протоколам SSL/TLS, поэтому такой HTTP протокол и называют HTTPS (HTTP Secure или HTTP over SSL). Протоколы SSL/TLS содержат определенный набор шифров и алгоритмов для создания защищенного туннеля связи:

Для чего вообще нужно создавать защищенное соединение?

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

Вот, что предоставляет HTTPS:

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

От чего HTTPS вас НЕ защитит:

  • Различные сетевые атаки. Существует большое количество уязвимостей и методов атак, направленные против веб-серверов и приложений, например инъекция SQL, инъекция команд и многое другое. Для защиты от них применяют комплексные меры на стороне сервера и клиента.
  • Анонимность – HTTPS не делает ваше соединение анонимным. Ваш браузер и сторонние сервисы и устройства видят и отслеживают, когда и какие сайты вы посещали. Однако они не видят какие данные вы и сервер передавали друг другу.
  • Посещение зловредных сайтов – сайты мошенников и хакеров могут содержать скрипты и программы, которые могут вам навредить. Кроме того, некоторые популярные сайты могут быть сфальсифицированы, чтобы обманом принудить вас совершить какое-либо действие. Например представим, что существует ваш любимый интернет-магазин echop.com, в котором вы часто совершаете покупки. Хакер может сделать копию сайта и опубликовать его в интернете под именем esh0p.com. Обратите внимание, что буква «о» заменена на цифру «0». Не все на это могут обратить внимание, поэтому хакер просто разошлет тысячи электронных писем с предложением о распродажи, подделав стилистику сайта. Доверчивые пользователи перейдут по ссылке и совершат покупки. Таким образом хакер может получить деньги и самое главное данные ваших карт. HTTPS не способен оградить вас от этого.

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

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

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

 

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

Симметричное шифрование использует один ключ для шифрования и дешифрования сообщений:

Схема симметричного шифрования

 

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

Схема асимметричного шифрования

Самым известным алгоритмом асимметричного шифрования является шифр RSA. Он используется в протоколах SSL/TLS и VPN.

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

Обмен ключами с помощью алгоритма RSA

  1. Клиент генерирует симметричный ключ шифрования.
  2. Затем, используя открытый ключ сервера, шифрует сгенерированный ключ и передает серверу. На этом этапе канал связи уязвим для перехвата злоумышленником, однако, даже перехватив зашифрованные данные, их сложно взломать, не имея закрытого ключа. Поэтому для повышения сложности раскрытия или, иначе говоря, криптостойкости, используют длинные ключи и сложные алгоритмы шифрования.
  3. Сервер, приняв сообщение, расшифровывает его своим закрытым ключом. С этого момента оба участника обладают одинаковым сеансовым ключом.
  4. Обладая общим ключом клиент и сервер устанавливают защищенный канал связи.

Возникает вопрос, а почему бы не использовать ассиметричный алгоритм для двусторонней связи?

Дело в том, что данный алгоритм требует значительных вычислительных ресурсов и к тому же гораздо медленнее, чем симметричный.

 

Протокол Диффи-Хелмана

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

Схема работы алгоритма Диффи-Хелмана

  1. В начале генерируются специальные числовые параметры a и b. Они известны обоим участникам и могут открыто передаваться по сети.
  2. Затем клиент генерирует случайную числовую последовательность x, так называемый закрытый ключ. Данный ключ по сети не передается. Используя закрытый ключ клиент вычисляет открытый ключ M, который передает серверу.
  3. Сервер также генерирует закрытый ключ y и вычисляет открытый ключ N, используя полученные ранее параметры a и b. Затем ключ N передает клиенту.
  4. Теперь участники вычисляют общий сеансовый ключ. Клиент использует параметр b, открытый ключ сервера N и свой закрытый ключ x. Сервер же использует параметр b, открытый ключ клиента M и свой закрытый ключ y. Причем в результате вычислений обе стороны получат одинаковый ключ K.

Если злоумышленник перехватит a, b и M, N, то, не имея закрытых ключей x и y, он не сможет вычислить общий ключ.

 

Хэш-функция и Хэширование

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

Хэширование — это процесс применения хэш-функции к данным с целью получения уникального "отпечатка" или "хэш-суммы" для этих данных.

У хэширования есть 2 отличительные особенности:

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

Схема работы процесса хэширования

Для чего же нужен хэш?

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

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

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

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

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

В качестве алгоритмов хэширования используются MD5, SHA-1, SHA-256 и другие.

 

Цифровая подпись

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

В механизме цифровой подписи задействованы 2 алгоритма: хэширование и ассиметричное шифрование.

Рисунок ниже иллюстрирует принцип работы цифровой подписи:

Схема создания цифровой подписи

  1. На первом этапе отправитель прежде, чем отправить сообщение, генерирует его хэш.
  2. Затем, используя закрытый ключ, который известен только ему, шифрует хэш и добавляет его в конец передаваемого сообщения. Это и есть цифровая подпись.
  3. Далее сформированное сообщение с подписью передается получателю. Так как канал связи не защищен, то вполне вероятно, что хакер может подделать сообщение. Однако он не сможет сгенерировать подпись, потому что у него нет закрытого ключа отправителя.
  4. На приеме получатель проводит с помощью открытого ключа, который известен всем, он расшифровывает подпись и получает оригинальный хэш.
  5. Затем он генерирует хэш из уже полученного сообщения.
  6. Оба хэша сравниваются и, если они одинаковы, то полученное сообщение подлинное, в противном случае удаляется.

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

 

Сертификат веб-сайта

Каждый веб-сайт для работы по HTTPS должен иметь сертификат. Сертификат является своего рода паспортом сайта и подтверждает его подлинность. Выдаются сертификаты специальными организациями – центрами сертификации (Certification Authority – CA), которым доверяют все участники связи (браузеры, серверы).

Аналогом сертификата сайта является паспорт гражданина, в котором указывается некоторая информация о нем и выдается он определенным государственным органом. То есть проверив паспорт гражданина, мы тем самым устанавливаем его подлинность, доверяя при этом организации, выдавшей данный паспорт.

Так что же из себя представляет сертификат?

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

Структура и поля сертификата

Обычно файл имеет расширение .cer,. p12, .pfx. Формат файла определяется стандартом X.509.

Когда клиент обращается к сайту, то запрашивает его сертификат и проверяет следующие данные:

  • Кем был выдан сертификат. Современные браузеры поставляются с некоторыми предустановленными сертификатами и содержат список доверенных организаций и центров сертификации.
  • Срок действия сертификата.
  • Доменное имя сайта.
  • Цифровая подпись.
  • Был ли отозван сертификат. Иногда по тем или иным причинам центр сертификации может отозвать сертификат и сделать его недействительным.

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

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

Можно ли самому создать свой сертификат и подписать его?

Да, можно. Такие сертификаты являются самоподписанными (self-signed).

Что будет делать браузер, если получит такой сертификат?

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

Посещая любой сайт, вы можете сами проверить сертификат, особенно если браузер на него «ругается». Для этого в адресной строке браузера кликнете на иконку со знаком замка (демонстрируется для браузера Mozilla Firefox):

Иконка с замком при безопасном соединении через HTTPS

Если вы кликнете на “Connection secure”, то увидите кем был выдан сертификат:

Отображение эмитента сертификата

Чтобы увидеть весь сертификат, то кликнете на “More information”, а затем переключитесь на вкладку “Security”:

Краткое отображение содержимого сертификата сайта

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

Если кликнете на “View certificate”, то в новой вкладке браузера отобразится полная информация из сертификата:

Отображение полной иформации из сертификата сайта

 

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

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

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

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

Цепочка доверенных организаций из сертификата

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

Самопдписанный корневой сертификат

Обратите внимание на имя субъекта (Subject Name) и имя эмитента (Issuer Name). Они одинаковые, а значит перед нами самоподписанный сертификат.

 

Протоколы SSL/TLS – принцип работы

Теперь, зная основы криптографии, вы сможете понять, как работают протоколы SSL/TLS. Однако в начале вкратце опишем протоколы SSL и TLS.

SSL (Secure Sockets Layer) использует ассиметричное шифрование для обмена ключами и симметричное шифрование для создания защищенного канала, по которому уже передаются пользовательские данные. Протокол включает в себя довольно большой набор алгоритмов шифрования и хэширования, однако многие из них уже признаны устаревшими. Всего существуют 3 версии протокола: SSL 1.0, SSL 2.0 и SSL 3.0. Все версии протокола признаны уязвимыми, поэтому была разработана улучшенная версия SSL, которая получила название TLS (Transport Layer Security).

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

На сегодняшний день рекомендуется использовать TLS 1.2 и TLS 1.3, причем версия 1.3 является самой безопасной и надежной.

Итак, как же работает SSL/TLS?

Если взглянуть на стек TCP/IP, то протокол SSL/TLS находится между прикладным и транспортным уровнями:

Разница между HTTP и HTTPS в стеке TCP/IP

Любое HTTPS соединение начинается с установления TCP соединения, подробнее о TCP можно почитать здесь. Затем устанавливается SSL/TLS соединение и после этого HTTP начинает передавать данные по зашифрованному каналу. Упрощенная схема работы HTTPS представлена ниже:

Установление SSL/TLS соединения

Установление SSL/TLS соединения

Установление SSL/TLS соединения

 

  1. Устанавливается TCP соединение.
  2. Затем клиент передает серверу весь набор поддерживаемых шифров и версию протокола SSL/TLS.
  3. Сервер всегда будет выбирать последнюю версию и только надежные алгоритмы шифрования из предложенного списка.
  4. Затем сервер отправляет свой сертификат.
  5. Браузер проверяет сертификат и подпись, то есть аутентифицирует сервер. Если сертификат недостоверный, то на этом этапе браузер отобразит предупреждение пользователю.
  6. Сервер также может запросить браузер предоставить свой сертификат, чтобы удостовериться, что клиент может общаться с сервером и пользоваться его ресурсами. Такое происходит, когда веб-приложение оперирует с конфиденциальными данными и необходимо ограничить доступ к приложению только определенным пользователям. Для этих целей в браузеры предварительно устанавливают соответствующие сертификаты.
  7. Получив сертификат от клиента сервер также проверяет его. Если все в порядке, то сервер продолжает соединение. В противном случае разрывает.
  8. Затем браузер генерирует сеансовый симметричный ключ, который шифрует с помощью открытого ключа сервера, указанного в его сертификате, и отправляет его серверу.
  9. Сервер, используя свой закрытый ключ, получает сеансовый ключ. На этом установление SSL/TLS соединения завершается.
  10. Теперь обе стороны, имея идентичный сеансовый ключ шифрования, могут шифровать и передавать данные друг другу.