Протокол SSL: что это, как работает и зачем нужен
Сказ о протоколе-шифровальщике, без которого не обходится ни одна покупка в интернете.
Иллюстрация: Оля Ежак для Skillbox Media
В одной из предыдущих статей мы рассказывали, что SSL-сертификаты позволяют удостовериться в подлинности сайта и установить с ним защищённое соединение. Без этого сертификата нельзя безопасно отправить важные данные по Сети — ведь в теории любой сможет их перехватить, прочитать или изменить. Например, взять ваш онлайн-заказ в пиццерии и заменить все топпинги на чёрный перец и лакрицу ��
Сегодня же перейдём на более продвинутый уровень и разберёмся, как устроен сам SSL-протокол:
Что такое SSL-протокол
SSL, или secure sockets layer, — это протокол, который шифрует и защищает данные во время их передачи по интернету. Для этого он использует специальные криптографические ключи, изменяющие данные до неузнаваемости.
В модели TCP/IP протокол находится на прикладном уровне, а в OSI — между транспортным и прикладным. Здесь SSL отвечает за шифрование/дешифрацию и создание сессий, в рамках которых происходит общение между клиентом и сервером.
Сразу скажем, что сегодня SSL используют редко: его заменил более современный и безопасный протокол TLS. Разработчики взяли за основу SSL 3.0 и добавили туда пару улучшений — в основном связанных с безопасностью и поддержкой в разных браузерах.
И TLS, и SSL выполняют одну и ту же работу — создают соединения и защищают передачу данных по ним. Разница лишь в том, что TLS более современный, надёжный и безопасный.
Работу SSL-протокола можно описать следующим образом.
Когда вы заходите на сайт, защищённый SSL-протоколом, браузер устанавливает безопасное соединение с сервером сайта. Такое соединение нужно, чтобы вы могли не беспокоясь передавать конфиденциальную информацию — например, пароли или данные от банковских карт.
Как только соединение будет настроено, браузер с помощью криптографического ключа зашифрует сообщение и отправит серверу. Сервер получит этот непонятный текст и расшифрует с помощью своего ключа. Такое общение будет продолжаться до тех пор, пока вы не закроете вкладку.
Пока всё звучит классно — протокол защищает наши данные и общается с сервером на своём языке. Но давайте узнаем, зачем он ещё нужен.
Зачем нужен SSL-протокол
Главная задача SSL— проверить подлинность сайта и установить с ним защищённое соединение. Каждый раз, когда вы заходите на какую-то страницу, браузер убеждается в том, что сайт настоящий, а не поддельный. А также узнаёт, можно ли безопасно передавать сайту личные данные.
Обычно, когда вы заходите на сайт, браузер использует протокол HTTP для передачи данных между клиентом и сервером. Это незащищённый протокол, а значит, данные перехватить может кто угодно. Поэтому поток данных, передаваемых по HTTP придумали шифровать протоколом SSL. Так появился стандарт HTTPS, где S означает secure. По сути, всё его отличие от предшественника как раз и состоит в использовании протокола SSL.
Подробнее о протоколе HTTP можно почитать в другой нашей статье — объясняем на пальцах, как он устроен и как работает.
Убедиться, что SSL-протокол работает, можно почти во всех браузерах. Например, в Google Chrome рядом с адресом сайта есть замок, который говорит о том, что передача данных защищена:
Ещё протокол обеспечивает целостность данных: он защищает их от изменений в процессе передачи. Любые правки, которые внезапно появятся, будут обнаружены, а пользователь получит предупреждение о возможном нарушении безопасности.
Без SSL интернет-транзакции были бы уязвимы к атакам типа man-in-the-middle («человек посередине»), а онлайн-покупки превратились бы в русскую рулетку. Возможно, сегодня пользователю повезёт и никто не перехватит три цифры на обороте его банковской карты, а возможно — нет, и кто-то купит пару биткоинов за его счёт.
Чем SSL-протокол отличается от SSL‑сертификата
SSL-протокол и SSL-сертификат работают в паре, но выполняют разные функции.
Протокол SSL определяет последовательность действий, которые нужно совершить, чтобы установить защищённое соединение между клиентом и сервером.
Сертификат SSL — это электронный документ. Он-то и содержит информацию о сайте, которая нужна для установки защищенного соединения. Туда входят:
- данные о владельце сертификата;
- публичный ключ для шифрования;
- подлинная подпись.
Получить такой сертификат можно в официальном центре сертификации. Он будет гарантировать, что соединение защищено, а пользователи смогут безопасно передавать свои личные данные. Один из самых популярных центров сертификации в России — reg.ru.
Сертификат можно сделать и самостоятельно, и он будет иметь все те же данные, но браузеры воспримут его с подозрением. Это как купить люкс-копию AirPods — вроде бы дизайн и кейс те же самые, но сколько они проработают и подключатся ли вообще к телефону, неизвестно.
Как мы отметили выше, SSL-протокол и SSL-сертификаты работают сообща. Протокол шифрует данные и передаёт их между клиентом и сервером, а сертификаты подтверждают подлинность и гарантируют, что клиент связывается с настоящим сайтом. На этом месте остановимся поподробнее.
Как работает SSL-протокол
Пора узнать, как клиент и сервер «жмут друг другу руки» и шифруют данные. Другими словами — как SSL работает на техническом уровне.
Когда вы пытаетесь подключиться к сайту, который защищён SSL, ваш браузер и сервер начинают «рукопожатие». Так называют процесс, когда браузер и сервер обмениваются информацией друг о друге. Для начала — сообщают, какие версии протокола установлены на обоих устройствах.
Затем сервер должен передать вашему браузеру договор «на подпись» — SSL‑сертификат. В нём будет храниться подробная информация о сайте. Но важнее всего — публичный ключ и подпись, которую выдаёт центр сертификации. Они нужны, чтобы проверить, что вы заходите на настоящий сайт, а не на его подделку.
SSL-протокол использует два типа ключей: публичные и приватные.
Публичные известны всем, и их можно получить при первом «рукопожатии» с сервером. Приватные — лежат строго на компьютере и не передаются никому.
Оба ключа нужны, чтобы шифровать данные по алгоритму RSA. Публичный ключ нужен, чтобы шифровать сообщения, а приватный — чтобы расшифровывать. На взлом такого шифра могут уйти миллионы лет. Поэтому не советуем этим заниматься.
Теперь браузер должен убедиться, что сайт настоящий, и проверить подлинность его SSL-сертификата. Для этого он обращается в центр сертификации и отдаёт ему уникальный номер сертификата. Если срок действия сертификата не закончился и он был выдан в надёжном месте, то браузер получит уведомление, что всё ок.
На этот момент соединение считается установленным: сертификат нормальный, публичный ключ у нас. Пора отправлять данные.
Вся информация, что передаётся между браузером и сервером, сначала шифруется на стороне браузера. Он применяет публичный ключ шифрования и генерирует примерно такой текст:
Попробуйте расшифровать наше послание, используя этот 1024-битный ключ. Вставьте текст выше в поле Enter Encrypted Text to Decrypt, а ключ ниже — в поле Enter Public/Private key.
Затем нажмите Decrypt
Как только текст зашифрован — пора передавать его на сервер. Тот его расшифрует с помощью своего приватного ключа и поймёт, что вы хотите от него получить.
Данные переданы, процесс завершается, и соединение разрывается. При следующем визите на сайт всё повторится.
Как SSL-протокол шифрует данные
Коротко расскажем об алгоритмах шифрования. Всего есть два больших класса алгоритмов — асимметричные и симметричные. Разница между ними только в количестве ключей.
Симметричные используют один общий ключ для шифрования и дешифрования. Ключ известен обеим сторонам — клиенту и серверу. Поэтому нужно не допустить, чтобы он потерялся, — иначе шифрование станет бессмысленным.
Асимметричные используют два ключа — публичный и приватный. Публичный ключ нужен для шифрования данных, поэтому его можно без проблем отправлять кому угодно. Приватный ключ нужен для дешифрования, поэтому его нужно держать в безопасном месте.
В SSL-протоколе два типа шифрования работают вместе. Асимметричное шифрование используют во время «рукопожатия» и аутентификации. Симметричное — для шифрование сообщений.
Вместе с шифрованием используют алгоритмы хеширования.
Хеширование — это способ превратить данные в строку фиксированной длины. Для этого данные пропускают через хеш-функцию, которая получает на их основе уникальную последовательность символов. В будущем по этой строке можно будет определить, редактировался файл или нет. Ведь даже если заменить один символ в текстовом документе, то его хеш изменится до неузнаваемости.
SSL/TLS
SSL (Secure Sockets Layer) и TLS (Transport Level Security) — криптографические протоколы, обеспечивающие защищенную передачу данных в компьютерной сети. Они широко используются в веб-браузерах, а также при работе с электронной почтой, обмене мгновенными сообщениями и в IP-телефонии.
Соединение, защищенное протоколом TLS, обладает одним или несколькими следующими свойствами:
- Безопасность: симметричное шифрование защищает передаваемую информацию от прочтения посторонними лицами.
- Аутентификация: «личность» участника соединения можно проверить с помощью асимметричного шифрования.
- Целостность: каждое сообщение содержит код (Message Authentication Code, MAC), с помощью которого можно проверить, что данные не были изменены или потеряны в процессе передачи.
Так как большинство протоколов связи могут быть использованы как с TLS/SSL, так и без него, при установке соединения необходимо явно указать серверу, хочет ли клиент устанавливать TLS. Один способ добиться этого — использовать порт, по которому соединение всегда устанавливается с использованием TLS (например, 443 для HTTPS). Другой способ — использовать специальную команду серверу от клиента переключить соединение на TLS (например, STARTTLS для протоколов электронной почты).
История SSL
SSL изначально разработан компанией Netscape для добавления протокола — HTTPS в свой веб-браузер Netscape Navigator, потому что компания считала, что безопасное соединение между клиентом и сервером в первую очередь послужит успехом развитию Интернета как инструмента бизнеса.
Из-за невозможности гарантировать безопасность сети, через которую передается информация наилучшим способом защитить ее было выбрано шифрование и дешифрование на концах устанавливаемого соединения соответственно. Netscape могли бы встроить этот подход напрямую в свой браузер, но это бы не предоставило единого решения, которое другие приложения могли бы использовать. Требовалось получить более общный, независимый от приложения подход.
В итоге, Netscape разработал протокол SSL работающий поверх TCP, а также предоставляющий TCP-подобный интерфейс для приложений более высокого уровня. В теории, одним из преимуществ SSL для разработчиков являлась возможность заменить все традиционные TCP вызовы на новые SSL вызовы. Специфические детали того, как SSL шифрует и дешифрует данные были относительно прозрачны.
Устройство протокола SSL
Протокол SSL размещается между двумя протоколами: протоколом, который использует программа-клиент (HTTP, FTP, LDAP, TELNET и т.д.) и транспортным протоколом TCP/IP. SSL защищает данные, выступая в роли фильтра для обеих сторон и передает их далее на транспортный уровень.
Работу протокола можно разделить на два уровня:
- Слой протокола подтверждения подключения (Handshake Protocol Layer)
- Слой протокола записи
Первый слой, в свою очередь, состоит из трех подпротоколов:
- Протокол подтверждения подключения (Handshake Protocol)
- Протокол изменения параметров шифра (Cipher Spec Protocol)
- Предупредительный протокол (Alert Protocol)
Протокол подтверждения подключения производит цепочку обмена данными, что в свою очередь начинает аутентификацию сторон и согласовывает шифрование, хэширование и сжатие. Следующий этап — аутентификация участников, которая осуществляется также протоколом подтверждения подключения.
Протокол изменения параметров шифра используется для изменения данных ключа (keying material) — информации, которая используется для создания ключей шифрования. Протокол состоит всего из одного сообщения, в котором сервер говорит, что отправитель хочет изменить набор ключей.
Предупредительный протокол содержит сообщение, которое показывает сторонам изменение статуса или сообщает о возможной ошибке. Обычно предупреждение отсылается тогда, когда подключение закрыто и получено неправильное сообщение, сообщение невозможно расшифровать или пользователь отменяет операцию.
Протокол записи
Протокол записи (Record Layer) — это уровневый протокол. На каждом уровне сообщения включают поля для длины, описания и проверки. Протокол записи принимает сообщения, которые нужно передать, фрагментирует данные в управляемые блоки, разумно сжимает данные, применяя MAC (message authentication code), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента.
Существует четыре протокола записи:
- Протокол рукопожатия (handshake protocol);
- Протокол тревоги (alert protocol);
- Протокол изменения шифра (the change cipher spec protocol);
- Протокол приложения (application data protocol);
Принцип работы SSL
Принцип работы SSL состоит из двух фаз: фаза рукопожатия и фаза передачи данных. Во время фазы рукопожатия клиент и сервер используют шифрование открытым ключом для того, чтобы определить параметры секретного ключа, используемого клиентом и сервером для шифрования во время фазы передачи данных.
Клиент инициирует рукопожатие посылая “hello”-сообщение серверу. Такое сообщение содержит список алгоритмов симметричного шифрования (cipher specs), поддерживаемых клиентом. Сервер отвечает похожим “hello”-сообщением, выбрав при этом наиболее подходящий алгоритм шифрования из полученного списка. Далее сервер отправляет сертификат, который содержит его публичный ключ.
Сертификат — это набор данных, который подтверждает подлинность. Подтвержденная третья сторона, известная как центр сертификации (CA), генерирует сертификат и проверяет его подлинность. Чтобы получить сертификат сервер должен использовать безопасные каналы для отправки своего публичного ключа в центр сертификации. Он генерирует сертификат, который содержит его собственный ID, ID сервера, публичный ключ сервера и другую информацию. А также центр сертификации создает отпечаток (digest) сертификата, который, по сути, является контрольной суммой. Далее центр сертификации создает подпись сертификата (certificate signature), которая формируется путем шифрования отпечатка сертификата приватным ключом центра сертификации.
Для проверки сертификата сервера клиент использует публичный ключ центра сертификации для расшифровки подписи. Затем клиент самостоятельно считает отпечаток сертификата сервера и сверяет с расшифрованным. Если они не совпадают, то сертификат был подделан. Естественно, для расшифровки подписи у клиента должен быть публичный ключ центра авторизации. Поэтому клиент хранит у себя список публичных ключей подтвержденных центров сертификации. По факту, многие браузерные приложения имеют подобный список, находящийся непосредственно в их коде. Когда клиент установил подлинность сервера (сервер также может запросить сертификат у клиента), сервер использует шифрование открытым ключом для определения секретного ключа для обмена информацией.
Фаза рукопожатия завершается отправкой “finished”-сообщений, как только обе стороны готовы начать использование секретного ключа. Начинается фаза передачи данных, в ходе которой каждая сторона разбивает исходящие сообщения на фрагменты и прикрепляет к ним коды авторизации сообщений MAC (message authentication code). Код авторизации сообщения это зашифрованный отпечаток, вычисленный на основе содержимого сообщений. Из соображений безопасности, он не совпадает с секретным ключом и вычисляется вместе с секретным ключом на стадии рукопожатия. Для получения полноценного SSL пакета каждая из сторон объединяет данные фрагмента, код авторизации сообщения, заголовки сообщения и шифруют с использованием секретного. При получении пакета, каждая из сторон расшифровывает его и сверяет полученный код авторизации сообщения со своим. Если они не совпадают, то пакет был подделан.
Цифровые сертификаты
Протокол SSL использует сертификаты для проверки соединения. Сертификаты расположены на безопасном сервере и используются для шифрования данных и идентификации Web-сайта.
Способы получения SSL-сертификата:
- Использовать сертификат, выданный центром сертификации (Certification authority)
- Использовать самоподписанный сертификат
- Использовать «пустой» сертификат
Самоподписанный сертификат — сертификат, созданный самим пользователем — в этом случае издатель сертификата совпадает с владельцем сертификата. «Пустой» сертификат — сертификат, содержащий фиктивную информацию, используемую в качестве временной для настройки SSL и проверки его функциональности в данной среде.
Хэширование
Хеш-значение является идентификатором сообщения, его размер меньше размера оригинального сообщения. Самыми известными хеш-алгоритмами являются MD5 (Message Digest 5), который создает 128-битное хеш-значение, SHA-1 (Standard Hash Algorithm), создающий 160-битное хеш-значение, SHA-2 и SHA-3. Результат работы алгоритма хеширования — значение, которое используется для проверки целостности передачи данных.
Шифрование
Существует два основных способа шифрования данных: симметричный ключ (общий секретный ключ) и асимметричный ключ (открытый ключ).
Открытый ключ
Суть асимметричного шифрования заключается в том, что используется пара ключей. Один из них используется в качестве открытого (как правило, он публикуется в самом сертификате владельца), второй ключ называется секретным — он держится в тайне и никогда никому не открывается. Оба ключа работают в паре: один используется для запуска противоположных функций другого ключа. Если открытый ключ используется для того, чтобы зашифровать данные, то расшифровать их можно только секретным ключом и наоборот. Такая взаимосвязь позволяет делать две важные вещи.
Любой пользователь может получить открытый ключ по назначению и использовать его для шифрования данных, расшифровать которые может только пользователь, владеющий секретным ключом. (RSA)
Если заголовок шифрует данные, используя свой секретный ключ, каждый может расшифровать данные, используя соответствующий открытый ключ. Именно это является основой для цифровых подписей. (DSA)
RSA — самый распространенный алгоритм шифрования с использованием асимметричных ключей.
Секретный ключ
При шифровании секретным ключом используется один и тот же ключ для шифрованных данных. Если стороны хотят обменяться зашифрованными сообщениями в безопасном режиме, то у обеих сторон должны быть одинаковые симметричные ключи. Такой тип шифрования используется для большого объёма данных. Обычно используются алгоритмы DES, 3-DES, RC2, RC4 и AES.
Комбинированный подход
Алгоритмы симметричного шифрования часто включают установленное число добавок и сдвигов. Такие алгоритмы часто используют ключ для помощи при битовых манипуляциях или для того, чтобы шифруемые данные стали более случайными. Другими словами, при увеличении размера секретного ключа может увеличиться случайность шифруемых данных, но не обязательно возрастет сложность вычислений при расшифровке. Однако, шифрование открытым ключом использует ключ как экспоненту, поэтому значительное увеличения ключа сильно увеличивает количество вычислений, требуемых для шифрования / дешифрования данных.
Таким образом хотя алгоритмы шифрования открытым ключом не сталкиваются с проблемой распределения, с которой сталкиваются алгоритмы шифрования секретным ключом, они требует значительно больше вычислительной мощности. Для использования сильных сторон обоих типов алгоритмов протоколы безопасности обычно используют шифрование открытым ключом для передачи секретных ключей. Как только секретный ключ доставлен начинается передача данных с использованием симметричного шифрования.
Существует еще один подход, использующий открытый ключ как соглашение, а не как способ доставки секретного ключа другим. Обе стороны обмениваются публичными ключами и независимо генерируют секретный ключ. Самой распространенной формой такого соглашения является протокол Диффи-Хеллмана. Хотя SSL поддерживает протокол Диффи-Хеллмана, большинство SSL транзакций не используют его. Вместо него используется алгоритм RSA, который решает проблему распределения секретных ключей.
Аутентификация и обмен ключами
SSL поддерживает 3 типа аутентификации:
- аутентификация обеих сторон (клиент — сервер),
- аутентификация сервера с неаутентифицированным клиентом,
- полная анонимность.
Обычно для аутентификации используются алгоритмы: RSA, DSA, ECDSA.
Если сервер аутентифицирован, то его сообщение о сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный сервер должен предоставить допустимый сертификат клиенту. Каждая сторона отвечает за проверку того, что сертификат другой стороны ещё не истек и не был отменен. Всякий раз, когда сервер аутентифицируется, канал устойчив (безопасен) к попытке перехвата данных между веб-сервером и браузером, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента.
Главная цель процесса обмена ключами — это создание секрета клиента (pre_master_secret), известного только клиенту и серверу. Секрет (pre_master_secret) используется для создания общего секрета (master_secret). Общий секрет необходим для того, чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (message authentication code) и сообщения «finished». Отсылая сообщение «finished», стороны указывают, что они знают верный секрет (pre_master_secret).
Анонимный обмен ключами
Полностью анонимная сессия может быть установлена при использовании алгоритма RSA или Диффи-Хеллмана для создания ключей обмена. В случае использования RSA клиент шифрует секрет (pre_master_secret) с помощью открытого ключа несертифицированного сервера. Открытый ключ клиент узнает из сообщения обмена ключами от сервера. Результат посылается в сообщении обмена ключами от клиента. Поскольку перехватчик не знает закрытого ключа сервера, то ему будет невозможно расшифровать секрет (pre_master_secret). При использовании алгоритма Диффи-Хеллмана открытые параметры сервера содержатся в сообщении обмена ключами от сервера, и клиенту посылают в сообщении обмена ключами. Перехватчик, который не знает приватных значений, не сможет найти секрет (pre_master_secret).
Аутентификация и обмен ключами при использовании RSA
В этом случае обмен ключами и аутентификация сервера может быть скомбинирована. Открытый ключ также может содержаться в сертификате сервера или может быть использован временный ключ RSA, который посылается в сообщении обмена ключами от сервера. Когда используется временный ключ RSA, сообщения обмена подписываются server’s RSA или сертификат DSS. Сигнатура содержит текущее значение сообщения Client_Hello.random, таким образом, старые сигнатуры и старые временные ключи не могут повторяться. Сервер может использовать временный ключ RSA только однажды для создания сессии. После проверки сертификата сервера клиент шифрует секрет (pre_master_secret) при помощи открытого ключа сервера. После успешного декодирования секрета (pre_master_secret) создается сообщение «finished», тем самым сервер демонстрирует, что он знает частный ключ, соответствующий сертификату сервера.
Когда RSA используется для обмена ключами, для аутентификации клиента используется сообщение проверки сертификата клиента. Клиент подписывается значением, вычисленным из master_secret и всех предшествующих сообщений протокола рукопожатия. Эти сообщения рукопожатия содержат сертификат сервера, который ставит в соответствие сигнатуре сервера сообщение Server_Hello.random, которому ставит в соответствие сигнатуру текущему сообщению рукопожатия.
Аутентификация и обмен ключами при использовании протокола Диффи-Хеллмана
В этом случае сервер может также поддерживать содержащий конкретные параметры алгоритм Диффи-Хеллмана или может использовать сообщения обмена ключами от сервера для посылки набора временных параметров, подписанных сертификатами DSS или RSA. Временные параметры хэшируются с сообщением hello.random перед подписанием для того, чтобы злоумышленник не смог совершить повтор старых параметров. В любом случае клиент может проверить сертификат или сигнатуру для уверенности, что параметры принадлежат серверу.
Если клиент имеет сертификат, содержащий параметры алгоритма Diffie-Hellman, то сертификат также содержит информацию, требующуюся для того, чтобы завершить обмен ключами. В этом случае клиент и сервер должны будут сгенерировать одинаковые Diffie-Hellman результаты (pre_master_secret) каждый раз, когда они устанавливают соединение. Для того, чтобы предотвратить хранение секрета (pre_master_secret) в памяти компьютера на время дольше, чем необходимо, секрет должен быть переведен в общий секрет (master_secret) настолько быстро, насколько это возможно. Параметры клиента должны быть совместимы с теми, которые поддерживает сервер для того, чтобы работал обмен ключами.
Восстановление сессии
Создатели SSL знали, что алгоритмы шифрования открытым ключом вычислительно сложные, и клиент, создающий несколько новых соединений к одному и тому же серверу в течение короткого промежутка времени может сильно нагрузить сервер, что приведет к заметным временным задержкам ответа. Однако, если клиент и сервер уже установили соединение, то ему будет соответствовать уникальный идентификатор сессии, позволяющий ссылаться на него и использовать такой же секретный ключ при последующих соединениях в рамках некоторого временного отрезка. Безусловно, такой подход привносит определенный риск в безопасность соединения. Поэтому, если необходимо, клиент может пересоздать новые идентификатор и секретный ключ для данной сессии. Microsoft’s Internet Explorer, например, проделывают эту операцию каждые 2 минуты.
Администрирование
Обслуживание сертификатов и ключей
Если клиент планирует обратиться к серверу, который требует клиентской аутентификации, он должен хранить свой сертификат и связанный с ним приватный ключ. Сервер должен всегда хранить свой сертификат и связанный с ним приватный ключ.
Хранилище идентификаторов сессий
Клиент и сервер обязаны хранить идентификаторы сессий и связанные с ними секретные ключи для использования во время восстановления соединения.
SSL 1.0, 2.0, 3.0 и TLS
Версия 1.0 никогда не была обнародована. Версии 2.0 была выпущена в феврале 1995 года, но содержала много недостатков по безопасности, которые привели к разработке SSL 3.0 версии.
Как только различные компании (Microsoft) начали предпринимать попытки разработки собственных безопасных протоколов транспортировки, IETF решило вмешаться и определить стандарт протокола шифрования. Впоследствии, при поддержке множества компаний, на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS 1.0. Его также часто называют SSL 3.1.
Хотя TLS и SSL имеют существенные различия в реализации, разработчики обычно замечают лишь немногие из них, а конечные пользователи вовсе их не различают. Тем не менее TLS 1.0 и SSL 3.0 несовместимы. Значительное различие состоит в том, что TLS требует определенные алгоритмы шифрования, которые SSL не поддерживает. Таким образом TLS сервер должен “откатиться” (downgrade) до SSL 3.0 для работы с клиентами, использующими SSL 3.0.
Принцип работы TLS
Протокол TLS делится на два слоя: TLS Record и TLS Handshake.
Подтверждение связи (handshake)
- Клиент посылает сообщение ClientHello, указывающее версию SSL или TLS и поддерживаемые клиентом методы шифрования (англ. CipherSuite). Это сообщение также содержит случайное число (набор байт), которое используется в последующих вычислениях. Протокол также позволяет указать поддерживаемые клиентом методы сжатия данных.
- Сервер отвечает сообщением ServerHello, которое содержит метод шифрования, выбранный сервером из списка, предложенного клиентом, а также идентификатор сессии и еще одно случайное число. Также сервер посылает свой цифровой сертификат. Если серверу нужен сертификат для аутентификации клиента, на этом шаге он может послать клиенту запрос такого сертификата.
- Клиент проверяет сертификат сервера.
- Клиент отправляет случайное число, которое клиент и сервер используют для шифрования последующих сообщений. Сама строка из байт шифруется публичным ключом сервера.
- Если сервер потребовал у клиента сертификат, клиент отсылает набор байт, зашифрованный его секретным ключом, и свой цифровой сертификат, или оповещение об отсутствии сертификата.
- Сервер проверяет сертификат клиента.
- Клиент и сервер отправляют друг другу сообщение ChangeCipherSpec, объявляя об изменении режима передачи данных с незащищенного на защищенный.
- Клиент отправляет сообщение Finished, зашифрованное секретным ключом, и таким образом завершает подтверждение связи со своей стороны.
- Аналогичные действия производит сервер.
- На протяжении данной сессии клиент и сервер могут обмениваться сообщениями, зашифрованными секретным ключом.
Возобновление сессии
- Клиент посылает сообщение ClientHello, используя ID сессии, которую нужно возобновить.
- Сервер проверяет, есть ли у него в кэше соответствующий идентификатор. Если есть и сервер способен возобновить сессию, он отсылает клиенту сообщение ServerHello с этим же ID сессии. Если нет, сервер генерирует новый ID сессии и выполняет процедуру handshake с клиентом.
- Клиент и сервер обмениваются сообщениями ChangeCipherSpec, а затем Finished.
- Передача данных по защищенному каналу возобновляется.
Протокол записи (TLS Record)
Этот слой защищает данные с помощью ключей, полученных при подтверждении связи, и проверяет целостность и источник входящих сообщений. Он выполняет следующие функции:
- Разбиение исходящих сообщений на блоки нужного размера и «склеивание» входящих сообщений.
- Сжатие исходящих сообщений и распаковку входящих (используется не всегда).
- Применение кода аутентификации к исходящим сообщениям и проверку входящих с помощью MAC.
- Шифрование исходящих сообщений и дешифровку входящих.
После обработки протоколом TLS Record зашифрованные данные передаются на слой TCP для передачи.
Полный обзор SSL/TLS и его криптографической системы.
Я думаю, многие из вас знают о HTTPS, и некоторые из вас, возможно, настроили SSL/TLS для своего веб-сервера. Но кто из вас хорошо понимает, как работает SSL/TLS?
- Что на самом деле происходит во время рукопожатия TLS?
- Какие криптографические алгоритмы используются TLS для защиты данных?
- Как клиент и сервер обмениваются секретными ключами?
- Как работает обмен эфемерными ключами Диффи-Хеллмана?
- Зачем нужен цифровой сертификат?
- Почему он должен быть подписан центром сертификации?
- Что такое цифровая подпись? Как он подписывается и проверяется?
- Что означает совершенная прямая секретность?
- Как работают AEAD, MAC, HKDF, 0-RTT?
- Что такое эллиптическая криптография?
- Что нового в TLS 1.3 по сравнению с TLS 1.2?
Вопросов много, и я не хочу просто царапать поверхность. Так что это будет очень подробная статья, чтобы рассказать вам все о SSL/TLS, чрезвычайно важном строительном блоке безопасности в Интернете.
Вот видеоверсия этой статьи, если вы хотите посмотреть:
1. Что такое SSL/TLS?
SSL расшифровывается как Secure Socket Layer. Это предшественник TLS.
TLS — краткая форма Transport Layer Security, которая представляет собой криптографический протокол, обеспечивающий безопасную связь по компьютерной сети.
2. История SSL/TLS
Вот немного истории SSL и TLS:
- Первоначально SSL был разработан Netscape и впервые опубликован в 1995 году с версией 2.0.
- Версия SSL 1.0 так и не была выпущена публично из-за некоторых серьезных недостатков безопасности.
- В 1996 году была опубликована версия 3.0 SSL, полностью переработанная для протокола.
- Затем, 3 года спустя, TLS 1.0 был впервые определен IETF в RFC 2246 как обновление SSL версии 3.0.
- Потребовалось 7 лет, чтобы обновить его до TLS 1.1 в 2006 году.
- Сразу после этого в 2008 году появился TLS 1.2.
- Наконец, после 10 лет разработки, в 2018 году мы получили TLS 1.3 с огромными улучшениями.
Итак, какая версия SSL/TLS еще существует на данный момент?
- SSL 2.0 устарел в 2011 году.
- SSL 3.0 устарел в 2015 году.
- А недавно, в марте 2020 года, исчезли и TLS 1.0 и TLS 1.1.
Это означает, что активны только TLS 1.2 и 1.3.
3. Где используется TLS?
Во-первых, он широко используется в Интернете. Все веб-сайты, которые вы посещаете с помощью HTTPS, защищены TLS, или мы часто говорим HTTP поверх TLS.
Точно так же электронная почта с протоколом SMTPS на самом деле является SMTP и TLS. Тогда FTPS для безопасного протокола передачи файлов также является FTP плюс TLS.
И есть много других приложений TLS, о которых у меня нет времени упоминать.
4. Зачем нам нужен TLS?
Потому что TLS дает нам 3 вещи:
Аутентификация
TLS проверяет личность взаимодействующих сторон, которыми обычно являются клиенты и серверы.
С помощью асимметричной криптографии TLS гарантирует, что мы перейдем на настоящий сайт, а не на поддельный.
Конфиденциальность
TLS защищает передаваемые данные от несанкционированного доступа, шифруя их с помощью алгоритмов симметричного шифрования.
Целостность
TLS распознает любое изменение данных во время передачи, проверяя код аутентификации сообщения, о котором мы узнаем чуть позже.
5. Как работает TLS?
По сути, TLS состоит из 2 фаз или 2 протоколов:
Протокол рукопожатия
На этом этапе клиент и сервер:
- Согласовать версию протокола
- Выберите криптографический алгоритм (или наборы шифров)
- Аутентифицировать друг друга с помощью асимметричной криптографии
- Установите общий секретный ключ, который будет использоваться для симметричного шифрования на следующем этапе.
Таким образом, основная цель рукопожатия — аутентификация и обмен ключами.
Протокол записи
- Все исходящие сообщения будут зашифрованы общим секретным ключом, установленным в рукопожатии.
- Затем зашифрованные сообщения передаются другой стороне.
- Они будут проверены, чтобы увидеть, есть ли какие-либо изменения во время передачи или нет.
- В противном случае сообщения будут расшифрованы тем же симметричным секретным ключом.
Таким образом, мы добьемся как конфиденциальности, так и целостности в этом протоколе записи. А поскольку объем зашифрованных данных на этом этапе велик, его часто называют массовым шифрованием.
6. Почему TLS использует как симметричную, так и асимметричную криптографию?
Почему бы просто не использовать один для всех целей?
Что ж, легко увидеть, что симметричная криптография не может обеспечить аутентификацию. Поскольку для клиента и сервера существует только один секретный ключ, они ничего не знают друг о друге, чтобы их можно было проверить. Не говоря уже о том, как они придумывают один и тот же ключ, не раскрывая его общественности, сложно.
Как насчет асимметричной криптографии? Звучит как хороший кандидат. К сожалению, это намного медленнее, чем симметричная криптография. И под «намного» я подразумеваю от 100 до 10000 раз медленнее. Так что для массового шифрования он явно не подходит.
7. Симметричная криптография
Хорошо, теперь давайте узнаем больше о симметричной криптографии. Я думаю, вы уже знаете основы.
Во-первых, у Алисы есть незашифрованное сообщение, которое она хочет отправить Бобу, но не хочет, чтобы кто-либо в общедоступной зоне его прочитал.
Поэтому она шифрует сообщение секретным ключом, которым они уже поделились друг с другом. Затем она отправляет зашифрованное сообщение Бобу через общедоступный Интернет.
Получив зашифрованное сообщение, Боб легко воспользуется тем же секретным ключом для его расшифровки.
Поскольку для шифрования и дешифрования используется один и тот же ключ, он является своего рода симметричным, поэтому у нас есть название симметричная криптография.
Теперь может быть хакер Гарри, который сможет перехватить их сообщения в общедоступной сети. Однако сообщение уже зашифровано, а у Гарри нет секретного ключа, поэтому он не сможет его расшифровать.
Но он все еще может изменить это! Существует одна техника, называемая атакой с переворачиванием битов, которая работает следующим образом:
Атака с переворотом битов
Допустим, на этот раз Алиса разговаривает не с Бобом, а со своим онлайн-банком. И она хочет отправить кому-то 100 долларов. Сообщение шифруется секретным ключом и отправляется в банк через Интернет.
Теперь Гарри ловит зашифрованное сообщение. Хотя он не может его расшифровать, он может поменять местами некоторые из его битов с 1 на 0 и с 0 на 1, а затем переслать это измененное сообщение в банк.
Поэтому, когда банк расшифрует его, он получит другой открытый текст. В данном случае она стала 900 долларов вместо 100.
Так что это очень опасно. Вот почему мы должны убедиться, что зашифрованное сообщение не было изменено во время передачи.
Но как? Один из способов сделать это — использовать аутентифицированное шифрование.
Аутентифицированное шифрование (AE)
Идея состоит в том, чтобы не только зашифровать, но и аутентифицировать зашифрованное сообщение.
Первый шаг — шифрование.
Незашифрованное сообщение Алисы проходит через алгоритм симметричного шифрования, такой как AES-256-GCM или CHACHA20.
Этот алгоритм шифрования также принимает в качестве входных данных общий секретный ключ и случайный одноразовый номер или вектор инициализации (IV). И он вернет зашифрованное сообщение.
Второй шаг – аутентификация.
Зашифрованное сообщение, секретный ключ и одноразовый номер становятся входными данными для алгоритма MAC, такого как GMAC, если вы используете AES-256-GCM, или POLY1305, если вы используете алгоритм шифрования CHACHA20.
Этот алгоритм MAC действует как криптографическая хэш-функция, и его выходом является MAC или код аутентификации сообщения.
Теперь этот MAC будет помечен вместе с зашифрованным сообщением, и окончательный результат будет отправлен Бобу. Из-за этого мы иногда называем этот MAC тегом аутентификации.
Добавить связанные данные (AD)
В TLS 1.3, помимо зашифрованного сообщения, мы также хотим аутентифицировать некоторые связанные данные, такие как: адреса, порты, версия протокола или порядковый номер. Эта информация не зашифрована и известна обеим сторонам связи.
Таким образом, связанные данные также являются входными данными алгоритма MAC. И поэтому весь процесс называется аутентифицированным шифрованием со связанными данными, или, короче, AEAD.
Расшифровка и проверка MAC
Теперь давайте посмотрим, как Боб может проверить, что зашифрованное сообщение не было изменено во время передачи.
Это просто обратный процесс. Начиная с зашифрованного сообщения с MAC-адресом, мы удаляем MAC-адрес из зашифрованного сообщения.
Затем зашифрованное сообщение будет передано алгоритму MAC вместе с общим секретным ключом и одноразовым номером. Обратите внимание, что это тот же одноразовый номер, который используется в процессе шифрования. Обычно одноразовый номер добавляется к зашифрованному сообщению перед отправкой получателю.
Связанные данные также войдут в алгоритм MAC. А на выходе будет другой MAC.
Теперь Боб может просто сравнить два значения MAC. Если они разные, то он знает, что зашифрованное сообщение было изменено. В противном случае он может безопасно расшифровать сообщение и использовать его, будучи уверенным, что это то же самое открытое текстовое сообщение, которое отправила Алиса.
Обмен секретными ключами
Однако есть 1 вопрос: как Боб и Алиса делятся друг с другом секретным ключом, не раскрывая его общественности?
Что ж, ответ таков: для этой цели им нужно использовать асимметричную криптографию или криптографию с открытым ключом. В частности, они могут использовать либо Эфемерную модель Диффи-Хеллмана, либо Эфемерную модель Диффи-Хеллмана с эллиптической кривой.
Обмен ключами Диффи-Хеллмана
Давайте посмотрим, как работает обмен ключами Диффи Хеллмана!
Во-первых, Алиса и Боб согласны с двумя числами: основанием g и модулем p. Эти цифры всем известны.
Затем каждый из них тайком выбирает приватный номер. Закрытый ключ Алисы имеет номер a, а закрытый ключ Боба — номер b.
Затем Алиса вычисляет свой открытый ключ и отправляет его Бобу: A = (g^a) mod p
Точно так же Боб вычисляет свой открытый ключ и отправляет его Алисе: B = (g^b) mod p
Затем Алиса получит открытый ключ Боба B, а Боб получит открытый ключ Алисы A.
Теперь происходит волшебство!
Алиса вычисляет: S = (B^a) mod p
Боб вычисляет: S = (A^b) mod p
И эти 2 значения магическим образом равны одному и тому же числу S. Почему? Давайте посчитаем:
(B^a) mod p = (g^b)^a mod p = (g^(b*a)) mod p
(A^b) mod p = (g^a)^b mod p = (g^(a*b)) mod p
Итак, Алиса и Боб придумали один и тот же секретный номер S, не раскрывая его общественности.
Однако имейте в виду, что для каждого алгоритма шифрования может потребоваться секретный ключ разной длины. Таким образом, чтобы создать секретный ключ, Алиса и Боб должны поместить S в одну и ту же функцию получения ключа (KDF). , а на выходе будет общий секретный ключ необходимой длины.
Ключевая функция деривации — KDF
В TLS 1.3 мы используем функцию получения ключа на основе HMAC, поэтому название HKDF.
Как правило, KDF принимает следующие входные данные:
- Входной ключевой материал (или IKM). В нашем случае IKM — это число S.
- Как долго мы хотим, чтобы выходной ключ был, например, 128-битным.
- Криптографическая хеш-функция, например HMAC-SHA256.
- Опционально некоторая контекстная или специфичная для приложения информация
- Необязательная соль.
Со всеми этими входными данными KDF создаст секретный ключ необходимой длины.
Функция люка
Теперь вернемся к обмену ключами Диффи-Хеллмана.
Мы знаем, что p, g, A , B известны широкой публике, а это означает, что хакер Гарри также имеет доступ к этим номерам.
Мы можем задаться вопросом: безопасен ли этот механизм обмена ключами? Или учитывая p, g, A, B, может ли Гарри разгадать секретные числа: a, b, S?
К счастью, эти функции станут лазейками, если мы выберем правильные значения для p, g, а, б.
- Выберите p в качестве 2048-битного простого числа.
- Выберите g в качестве примитивного корня по модулю p
- И выберите a, b для 256-битных случайные целые числа
функция-лазейка означает, что ее легко вычислить одним способом, но сложно другим. В таком случае:
- Учитывая p, g, a, легко вычислить A.
- Но учитывая p, g, A, очень сложно вычислить a.
Легко видеть, что A можно вычислить довольно быстро с временной сложностью O(log(a)). Это известная Модульная задача возведения в степень.
С другой стороны, вычисление a намного сложнее. Это задача дискретного логарифма, на решение которой нашему нынешнему поколению компьютеров требуется очень много времени.
Так что, по крайней мере, сейчас мы в безопасности или пока в дело не вступит следующее поколение мощных квантовых компьютеров.
Впрочем, пока «долго решать» не значит неразрешимо, правда?
Статический или эфемерный ключ?
Если Алиса и Боб используют одни и те же закрытые ключи a и b для каждого сеанса связи, то что случается так, что Гарри может записать все эти сеансы и начать решать a с сеанса 1.
Хотя на ее решение у него уйдет много времени, скажем, после сеанса N он получит право a. Теперь он может использовать его для вычисления секретного числа S и, таким образом, сможет расшифровать все записанные разговоры.
Звучит страшно? Как мы можем предотвратить это?
Ответ эфемерный ключ. Как следует из названия, мы используем разные закрытые ключи для каждой сессии. Таким образом, даже если Гарри сможет разгадать секретный ключ для одного сеанса, он не сможет использовать его для других.
Это называется идеальной прямой секретностью в TLS.
Итак, теперь вы понимаете, что означает Эфемерность Диффи-Хеллмана. Это просто Диффи-Хеллман с эфемерными или недолговечными ключами.
Как насчет эллиптической кривой Диффи-Хеллмана, эфемерной?
8. Криптография на основе эллиптических кривых
Криптография с эллиптическими кривыми (или ECC) — это подход к асимметричной криптографии, в котором алгоритм аналогичен, но используется другая функция лазейки.
Эта функция-лазейка основана на алгебраической структуре эллиптических кривых. И поэтому такое название.
Одно из удивительных преимуществ криптографии на основе эллиптических кривых заключается в том, что для обеспечения эквивалентного уровня безопасности требуются ключи меньшего размера. Вы можете увидеть это в этом сравнении с RSA.
Агентство национальной безопасности США (АНБ) использовало для защиты своей совершенно секретной информации 384-битный ключ ECC, который обеспечивает тот же уровень безопасности, что и ключ RSA-7680.
Звучит потрясающе, правда?
Однако криптография на основе эллиптических кривых является более легкой мишенью для атаки квантовых вычислений. Алгоритм Шора может взломать ECC на гипотетическом квантовом компьютере с меньшим количеством квантовых ресурсов, чем взломать RSA.
Могут пройти десятилетия, прежде чем этот мощный квантовый компьютер будет построен и использован. Но подготовили ли мы что-нибудь для этого? Существует ли квантово-устойчивый алгоритм?
Да, существует алгоритм обмена ключами Supersingular Isogeny Diffie-Hellman, который также основан на криптографии на эллиптических кривых. Но это уже другая история.
9. Асимметричная криптография
Теперь вернемся к асимметричной криптографии! Это потрясающая технология, которая имеет широкий спектр применения.
Мы уже изучили одно из его приложений, предназначенное для симметричного обмена секретными ключами, с эфемерным алгоритмом Диффи-Хеллмана и эфемерным алгоритмом Диффи-Хеллмана с эллиптической кривой.
Фактически, алгоритм RSA также использовался для обмена ключами в прошлом, но он был удален в TLS 1.3 из-за различных атак и отсутствия возможности прямой секретности.
Асимметричная криптография также используется в системе шифрования. Вот алгоритмы асимметричного шифрования:
- RSA с оптимальным дополнением асимметричного шифрования (RSA-OAEP).
- RSA со стандартом шифрования с открытым ключом 1 (RSA-PKCS1) с последней версией 2.2
- Алгоритм шифрования Эльгамаля.
И, наконец, еще одна важная особенность асимметричной криптографии — цифровая подпись, которую TLS широко использует для аутентификации. Некоторые популярные алгоритмы цифровой подписи, используемые в TLS:
- RSA с вероятностной схемой подписи.
- Эллиптический алгоритм цифровой подписи.
- Алгоритм цифровой подписи кривой Эдвардса.
Вскоре мы узнаем о цифровой подписи. Но перед этим давайте узнаем, как работает система асимметричного шифрования.
Асимметричное шифрование
Подобно симметричному шифрованию, у Алисы есть незашифрованное сообщение, которое она хочет отправить Бобу.
Но на этот раз общего секретного ключа нет. Вместо этого Алиса шифрует сообщение открытым ключом Боба и отправляет зашифрованное сообщение Бобу.
Когда Боб получает сообщение, он использует свой закрытый ключ для его расшифровки.
Хотя открытый ключ и закрытый ключ различны, они по-прежнему связаны некой функцией-лазейкой, точно так же, как мы видели в алгоритме Диффи-Хеллмана.
Идея такова: ключи идут парами, и только закрытый ключ из той же пары может расшифровать сообщение, зашифрованное открытым ключом.
Из-за этого, даже когда хакер Гарри имеет доступ как к зашифрованному сообщению Алисы, так и к открытому ключу Боба, он не может использовать этот открытый ключ для расшифровки сообщения.
Совместное использование открытого ключа
Совместное использование открытого ключа очень просто. Боб просто отправляет ключ Алисе напрямую через общедоступный Интернет, не опасаясь, что ключ может быть использован для расшифровки любых сообщений.
Ключ является общедоступным, поэтому любой может использовать его для шифрования сообщений, которые может прочитать только Боб, даже если они никогда раньше не разговаривали друг с другом. Это действительно сногсшибательно, не так ли?
Однако жизнь не так проста!
«Человек посередине» меняет ключ
Хотя мы знаем, что Гарри не может расшифровать сообщение с помощью открытого ключа Боба, он все же может вмешаться в обмен открытым ключом и заменить открытый ключ Боба своим собственным открытым ключом.
Теперь, когда Алиса получает ключ, она все еще думает, что это открытый ключ Боба, но на самом деле это ключ Гарри. Таким образом, если Алиса зашифрует свое сообщение этим ключом, Гарри сможет расшифровать его своим закрытым ключом.
Причина, по которой это может произойти, заключается в том, что ключ — это просто число, и нет идентификационной информации, которая могла бы сказать нам, кто его владелец.
Так что мы можем сделать? Очевидно, мы должны соединить ключ с некоторой идентификационной информацией. И это не что иное, как цифровой сертификат.
Цифровой сертификат
Итак, Боб помещает свой ключ в свой сертификат, на котором указано его имя и другая идентификационная информация. Сертификат действует как паспорт в реальном мире.
Но откуда мы знаем, что этот сертификат действительно принадлежит Бобу? Что мешает Гарри сделать поддельный сертификат на имя Боба, но с открытым ключом Гарри?
Ну, как и в реальном мире, паспорт должен быть выдан паспортным органом после процесса проверки личности. В цифровом мире сертификат должен быть проверен и подписан центром сертификации.
Этот центр сертификации и центр сертификации являются доверенной третьей стороной, которая помогает нам предотвратить создание поддельных паспортов и цифровых сертификатов.
Подписание сертификата
Процесс подписания сертификата происходит следующим образом:
У Боба есть пара открытого и закрытого ключа. На первом этапе он создает запрос на подпись сертификата или CSR. Этот CSR содержит его открытый ключ и некоторые идентификационные данные, такие как его имя, организация и адрес электронной почты.
Затем, второй шаг, он подписывает CSR своим закрытым ключом и отправляет его в центр сертификации.
Центр сертификации проверит личность Боба в сертификате. Они могут связаться с ним, чтобы запросить дополнительные доказательства, если это необходимо.
Затем они используют открытый ключ Боба в сертификате для проверки его подписи. Это делается для того, чтобы убедиться, что Боб действительно владеет закрытым ключом, связанным с открытым ключом в сертификате.
Если все верно, ЦС подпишет сертификат своим закрытым ключом и отправит его обратно Бобу.
Общий доступ к сертификату
Теперь Боб поделится с Алисой этим сертификатом, содержащим его открытый ключ, вместо того, чтобы посылать только открытый ключ, как раньше.
Получив сертификат, Алиса может легко проверить его подлинность с помощью открытого ключа центра сертификации.
Из-за этого Гарри больше не может заменить открытый ключ Боба своим ключом, так как у него нет закрытого ключа ЦС для подписи поддельного сертификата.
Обратите внимание, что это работает только потому, что мы все доверяем центру сертификации. Если каким-то образом CA не заслуживает доверия, например, если они дадут Гарри свой закрытый ключ, то у нас серьезные проблемы!
Центр сертификации — цепочка доверия
На самом деле существует цепочка центров сертификации.
На верхнем уровне находится корневой центр сертификации, который подписывает свой собственный сертификат, а также подписывает сертификат своего подчиненного, который является промежуточным сертификатом. полномочия.
Этот центр может подписывать сертификаты других промежуточных центров или они могут подписывать сертификат конечного объекта (или конечный сертификат).
Каждый сертификат будет ссылаться на сертификат своего более высокого уровня, вплоть до корня.
Ваши операционные системы и браузеры хранят список сертификатов доверенных корневых центров сертификации. Таким образом, они могут легко проверить подлинность всех сертификатов.
Цифровой подписи
Мы много говорили о цифровой подписи, так что давайте посмотрим, как это работает на самом деле!
Чтобы подписать документ, подписывающему сначала необходимо его хэшировать. Затем хеш-значение шифруется с помощью закрытого ключа подписавшего. Результатом будет цифровая подпись. Затем эта подпись будет прикреплена к исходному документу. И это все, что касается процесса подписания.
Теперь, как мы можем проверить, что подпись действительна? Ну, мы просто делаем обратный процесс.
Сначала мы отделяем подпись от документа, расшифровываем ее с помощью открытого ключа подписавшего, чтобы получить хеш-значение. Затем мы хэшируем документ с помощью того же алгоритма хеширования, который использовался в процессе подписания. Результатом является другое значение хеш-функции. Затем мы просто сравниваем 2 хеш-значения. Если они совпадают, то подпись действительна.
10. Протокол рукопожатия TLS 1.3
Итак, теперь, со всеми полученными знаниями, давайте подробнее рассмотрим, как они используются в протоколе рукопожатия TLS.
Полное рукопожатие
Полное рукопожатие TLS 1.3 начинается с приветственного сообщения, которое клиент отправляет на сервер. На самом деле в этом сообщении много всего, но здесь я лишь перечисляю важную информацию.
Во-первых, список версий протокола, которые поддерживает клиент.
Затем список поддерживаемых наборов симметричных шифров AEAD. В данном случае есть 2 варианта: AES-256-GCM или CHACHA20-POLY1305
После этого идет список поддерживаемых групп обмена ключами. Например, этот клиент поддерживает как эфемерную модель Диффи-Хеллмана с конечным полем, так и эфемерную модель Диффи-Хеллмана с эллиптической кривой.
Вот почему клиент также делится своими 2 открытыми ключами: 1 для Диффи-Хеллмана и другой для Эллиптической кривой Диффи-Хеллмана. Таким образом, сервер сможет вычислить общий секретный ключ независимо от того, какой алгоритм он выберет.
Последнее поле, отправляемое клиентом в этом сообщении, представляет собой список алгоритмов подписи, которые он поддерживает. Это для сервера, чтобы выбрать, какой алгоритм он должен использовать для подписи всего рукопожатия. Мы увидим, как это работает через некоторое время.
После получения клиентского приветственного сообщения сервер также отправляет приветственное сообщение, которое содержит: выбранную версию протокола TLS 1.3, выбранные наборы шифров: AES-256-GCM, выбранный метод обмена ключами: Diffie-Hellman Ephemeral и открытый ключ для выбранного метода.
Следующее поле — это запрос сертификата клиента, который является необязательным и будет отправлен только в том случае, если сервер хочет аутентифицировать клиента по своему сертификату. Обычно на веб-сайте HTTPS только сторона сервера должна отправить свой сертификат клиенту. И это отправляется в следующем поле этого сообщения.
Следующее поле — проверка сертификата, которое, по сути, является подписью всего рукопожатия до этого момента. Вот как он генерируется: все данные от начала рукопожатия до запроса сертификата называются контекстом рукопожатия. Мы объединяем этот контекст с сертификатом сервера, хешируем его и подписываем хеш-значение закрытым ключом сервера, используя один из алгоритмов подписи, которые поддерживает клиент.
Аналогичным образом завершение сервера генерируется путем объединения контекста рукопожатия, сертификата и проверки сертификата, хеширования и помещения хэш-значения в алгоритм MAC выбранного набора шифров. Результатом является MAC всего рукопожатия.
Здесь сертификат сервера, проверка сертификата и завершение работы сервера называются сообщениями аутентификации, поскольку они используются для аутентификации сервера. Благодаря подписи и MAC-адресу всего рукопожатия TLS 1.3 защищен от нескольких типов атак типа «человек посередине» с понижением уровня.
Теперь, после того как клиент получит приветственное сообщение от сервера, он проверит сертификат сервера с помощью корневого центра и проверит подпись и MAC всего рукопожатия, чтобы убедиться, что он не был подделан.
Если все в порядке, клиент отправляет сообщение о завершении с MAC-адресом всего рукопожатия до этого момента и, необязательно, с сертификатом клиента и подтверждением сертификата, если сервер запросил.
И это весь поток полного рукопожатия TLS.
Сокращенное рукопожатие с возобновлением PSK
Для повышения производительности клиент и сервер не всегда проходят это полное рукопожатие. Иногда они выполняют сокращенное рукопожатие, используя возобновление предварительного общего ключа.
Идея такова: после предыдущего рукопожатия клиент и сервер уже знают друг друга, поэтому им не нужно повторно аутентифицироваться.
Таким образом, сервер может отправить клиенту один или несколько билетов сеанса, которые можно использовать в качестве идентификатора предварительного общего ключа (PSK) при следующем рукопожатии. Это касается срока жизни билета, а также некоторой другой информации.
Теперь при следующем рукопожатии клиент отправит простое приветственное сообщение, содержащее:
- Список идентификаторов PSK (или билетов), полученных в результате предыдущего рукопожатия.
- Режим обмена ключами PSK, который может быть либо только PSK, либо PSK с Diffie-Hellman.
- Если используется PSK с режимом Диффи-Хеллмана, то клиент также должен поделиться своим открытым ключом Диффи-Хеллмана. Это обеспечит идеальную секретность пересылки, а также позволит серверу вернуться к полному рукопожатию, если это необходимо.
Когда сервер получает это приветственное сообщение клиента, он отправляет его обратно с помощью:
- Идентификация выбранного предварительного общего ключа
- Необязательный открытый ключ Диффи-Хеллмана сервера
- И сервер Finish так же, как и при полном рукопожатии.
Наконец, клиент отправляет обратно свой Finish, и это конец возобновления PSK. Как видите, в этом сокращенном рукопожатии нет проверки подлинности сертификата между клиентом и сервером.
Это также открывает возможность для данных с нулевым временем приема-передачи (0-RTT), что означает, что клиенту не нужно ждать завершения рукопожатия, чтобы отправить свои первые данные приложения на сервер.
0-RTT рукопожатие
В 0-RTT клиент отправляет данные приложения вместе с приветственным сообщением клиента. Эти данные шифруются с использованием ключа, полученного из первого PSK в списке билетов.
И это также добавляет еще 1 поле: указание ранних данных, чтобы сообщить серверу, что вместе отправляются ранние данные приложения.
Если сервер примет этот запрос 0-RTT, он отправит серверу приветствие, как при обычном возобновлении PSK, а также, возможно, некоторые данные приложения.
Клиент закончит с сообщением, содержащим MAC и индикатор конца ранних данных. Вот как работает 0 времени приема-передачи в TLS 1.3.
Его плюсы уменьшают задержку на 1 время прохождения туда и обратно. Но минусы открывают потенциальную угрозу повторной атаки, что означает, что хакер может просто скопировать и отправить один и тот же зашифрованный запрос 0-RTT на сервер несколько раз. Чтобы избежать этого, серверное приложение должно быть реализовано таким образом, чтобы оно было устойчивым к дублированию запросов.
11. Сравните TLS 1.3 и TLS 1.2
Теперь, прежде чем мы закончим, давайте быстро сравним TLS 1.3 и TLS 1.2, чтобы увидеть, что нового!
TLS 1.3 имеет более безопасные механизмы обмена ключами, в которых удалены уязвимые RSA и другие статические методы обмена ключами, оставлены только эфемерные алгоритмы Диффи-Хеллмана или Диффи-Хеллмана на эллиптических кривых, что обеспечивает идеальную прямую секретность.
Рукопожатие TLS 1.3 как минимум на 1 круговой обмен быстрее, чем TLS 1.2.
Симметричное шифрование в TLS 1.3 более безопасно, поскольку набор шифров AEAD является обязательным, а также удаляет из списка некоторые слабые алгоритмы, такие как режим блочного шифрования (CBC), RC4 или Triple DES.
Набор шифров в TLS 1.3 также проще, поскольку он содержит только алгоритм AEAD и алгоритм хеширования. Алгоритмы обмена ключами и подписи вынесены в отдельные поля. В то время как в TLS 1.2 они объединены в набор шифров. Из-за этого количество рекомендуемых наборов шифров становится слишком большим: 37 вариантов в TLS 1.2, тогда как в TLS 1.3 их всего 5.
Далее, TLS 1.3 также дает нам более сильную подпись, так как он подписывает все рукопожатие, а не только какую-то его часть, как в TLS 1.2.
И последнее, но не менее важное: криптография на основе эллиптических кривых получает значительное внимание в TLS 1.3 с добавлением некоторых улучшенных алгоритмов кривых, таких как алгоритм цифровой подписи на основе кривой Эдварда, который работает быстрее без ущерба для безопасности.
И это все, чем я хочу поделиться с вами в этой статье.
Вы можете проверить мой канал Youtube для более полезных руководств и курсов. И не забудьте подписаться на меня в твиттере для будущих публикаций!
Что такое SSL-протокол
В статье рассказываем, как работает SSL-протокол, и делимся инструкцией по получению сертификата и его установке на сервер.
Secure Sockets Layer, SSL, — протокол, обеспечивающий шифрование, защиту и аутентификацию интернет-соединений. Несмотря на то, что начале XX века его заменил обновленный протокол TLS (Transport Layer Security), SSL по-прежнему широко используется.
Протоколы SSL/TLS также подходят для защиты и других подключений — например, IP-телефонии или электронной почты.
Работа Secure Sockets Layer (SSL): рукопожатие
Работа SSL-протокола базируется на нескольких этапах:
- Установка соединения. Клиент отправляет запрос на установку безопасного соединения с сервером.
- Запрос на сертификат. Сервер отвечает клиенту, отправляя свой цифровой сертификат, который содержит открытый ключ и информацию о сервере.
- Проверка сертификата. Клиент проверяет подлинность сертификата с помощью центра сертификации.
- Key exchange. Клиент генерирует симметричные ключи шифрования и осуществляет их передачу с помощью открытого ключа сервера.
- Шифрование данных. Сервер расшифровывает симметричные ключи с помощью закрытого ключа и использует для шифрования данных, которые затем отправляет клиенту.
- Расшифровка данных. Клиент использует симметричные ключи для расшифровки данных, полученных от сервера.
В результате трафик, который передается между сервером и клиентом, защищен от перехвата и изменения злоумышленниками. SSL-протокол сохраняет целостность, конфиденциальность и аутентификацию данных.
Что такое SSL-сертификат
SSL-сертификат — это файл, который устанавливается на сервере с сайтом. Он содержит цифровую подпись издателя, открытый ключ и имя владельца сертификата, название центра сертификации.
Зачем нужен SSL-сертификат
SSL-сертификаты нужны для обеспечения безопасности пользовательских данных, подтверждения права собственности на веб-сайт, предотвращения создания поддельных версий сайта.
Если веб-сайт просит пользователей войти в систему или ввести личные данные, SSL поможет сохранить конфиденциальность сессии. Он также гарантирует, что веб-сайт является подлинным.
Самое главное — сертификат нужен, чтобы веб-сайт мог работать через шифрование HTTPS. Если сертификат отсутствует, то обмен данными осуществляется через HTTP.
Менеджер секретов
Разместите данные для доступа к приложениям и сертификатам в защищенном пространстве.
Типы SSL-сертификатов
В зависимости от задачи доступно несколько типов сертификатов. Уровень аутентификации, обеспечиваемый центром сертификации (CA), является существенным различием между ними.
- Domain Validation, DV — SSL-сертификат с проверкой домена обеспечивают самый быстрый, простой и экономичный способ шифрования HTTPS. DV требует подтверждения права собственности на защищенный домен и обычно выдается в течение нескольких минут. Однако поскольку легитимность организации не проверяется, DV не подходит для бизнес-сайтов. Этот сертификат лучше использовать для внутренних веб-сервисов, тестовых серверов и доменов.
- Organization Validation, OV — SSL-сертификат с проверкой организации. Чтобы его получить, организация должна доказать право собственности на домен и подтвердить, что является юридически зарегистрированным бизнесом.
- Extended Validation, EV — SSL-сертификат с расширенной проверкой обеспечивают наиболее высокий уровень доверия. Этот вариант подходит для веб-сайтов с электронной коммерцией — например, для интернет-магазинов. Чтобы его получить, владелец сайта должен соответствовать требованиям аутентификации для OV, а также пройти дополнительную проверку. При этом сертификаты EV обеспечивают то же самое шифрование, что DV и OV.
- Wildcard — отдельный сертификат с подстановочным знаком (*) в поле имени домена. Это позволяет сертификату защищать несколько поддоменов, относящихся к одному базовому домену.
- Multi-Domain SSL Certificate, MDC — может защитить до 100 различных доменных имен и поддоменов с помощью одного сертификата, что помогает сэкономить время и деньги.
- Unified Communications Certificate, UCC — предназначен для защиты нескольких полных доменных имен (FQDN). В UCC первый домен считается основным (базовым), а другие — доменами SAN (альтернативные имена субъекта).
В зависимости от центра сертификации пользователь может защитить от 25 до 250 доменов, что экономит время на управление сертификатами, а также снижает стоимость.
Платные и бесплатные сертификаты
Существуют как платные, так и бесплатные сертификаты SSL.
Платные сертификаты SSL предоставляются коммерческими центрами сертификации. Они обеспечивают более высокий уровень доверия для пользователей, так как включают проверку владельца сайта.
Бесплатные сертификаты SSL также доступны и могут быть получены от различных организаций, таких как Let’s Encrypt. Они предоставляют базовую безопасность и шифрование данных, но могут иметь ограниченный период действия или ограничения по функциональности.
Выбор между платными и бесплатными сертификатами SSL зависит от требований и бюджета веб-проекта. Бесплатные сертификаты привлекательны и подходят в определенных ситуациях. Но платные сертификаты более гибкие и заслуживают большего доверия.
Как проверить наличие сертификата
Самый простой способ узнать — это проверить URL сайта. Он должен начинаться с HTTPS. Для получения более подробной информации вы можете кликнуть на значок у адресной строки:
Также можно использовать сервисы вроде SSL Checker. С помощью него можно узнать, например, срок действия сертификата.
SSL Checker.
Как получить SSL-сертификат
Алгоритм для владельца сайта
Для получения SSL-сертификата необходимо выполнить несколько действий:
1. Выберите поставщика SSL-сертификатов. На рынке существует множество компаний, которые предлагают сертификаты. Среди них — Comodo, Symantec, GlobalSign, Let’s Encrypt и другие. Выберите поставщика, учитывая ваши потребности и бюджет.
2. Приобретите SSL-сертификат. После выбора поставщика и плана сертификации вам нужно купить сертификат. Поставщик предоставит вам данные, которые необходимо внести в качестве дополнительных записей на сервере или DNS.
3. Сгенерируйте CSR, запрос на сертификат. Вам необходимо будет создать запрос, который содержит информацию о вашей организации (название, адрес, домен и другие данные). Этот запрос будет связан с вашим закрытым ключом и использоваться для создания сертификата.
4. Предоставьте CSR поставщику сертификатов. Когда вы сгенерируете CSR, передайте его поставщику сертификатов. Он будет использовать эту информацию для создания вашего SSL-сертификата.
5. Подтвердите свое право на домен. В зависимости от типа сертификата и поставщика может понадобиться подтверждение того, что вы собственник домена. Обычно это можно сделать с помощью специальных DNS-записей или размещения файлов на сервере.
6. Получите и установите SSL-сертификат. После утверждения запроса поставщик предоставит вам SSL-сертификат. Его нужно будет установить на сервере — для этого понадобится закрытый ключ, созданный вместе с CSR.
После установки SSL-сертификата сайт будет защищен шифрованием. Посетители будут значок в адресной строке браузера, которые указывают на то, что соединение с сервером безопасно.
Проверка и выпуск сертификатов: подробнее о центрах сертификации
Как правило, заявитель на сертификат генерирует закрытый и открытый ключи (приватный и публичный), а также запрос на подпись сертификата, CSR. CSR — это закодированный текстовый файл, содержащий открытый ключ и другую информацию, которая будет включена в сертификат — например, доменное имя, название организации, адрес электронной почты и другое.
Ключи и CSR обычно генерируются на машине, на которой нужно установить сертификат. Информации в CSR зависит от уровня проверки и типа сертификата.
После создания CSR заявитель отправляет его в CA, который самостоятельно проверяет его содержание. Если информация корректна, центр подписывает сертификат в цифровой форме.
Когда подписанный сертификат предоставляется третьей стороне (например, когда это лицо получает доступ к веб-сайту с сертификатом), получатель может криптографически подтвердить цифровую подпись CA с помощью открытого ключа.
Установка сертификата
С получением SSL-сертификата разобрались. Теперь подробнее рассмотрим его установку на сервер.