SSL (англ. secure sockets layer — уровень защищённых сокетов) — криптографический протокол, который подразумевает более безопасную связь. Он использует асимметричную криптографию для аутентификации ключей обмена, симметричное шифрование для сохранения конфиденциальности, коды аутентификации сообщений для целостности сообщений. Протокол широко использовался для обмена мгновенными сообщениями и передачи голоса через IP (англ. Voice over IP — VoIP) в таких приложениях, как электронная почта, Интернет-факс и др. В настоящее время известно, что протокол не является безопасным. SSL должен быть исключен из работы в пользу TLS (см. CVE-2014-3566).
SSL изначально разработан компанией Netscape Communications для добавления протокола HTTPS в свой веб-браузер Netscape Navigator. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS.
Протокол SSL обеспечивает защищенный обмен данных за счет двух следующих элементов: Аутентификация Шифрование
SSL использует асимметричную криптографию для аутентификации ключей обмена, симметричный шифр для сохранения конфиденциальности, коды аутентификации сообщений для целостности сообщений.
Протокол SSL предоставляет "безопасный канал", который имеет три основных свойства: Канал является частным. Шифрование используется для всех сообщений после простого диалога, который служит для определения секретного ключа. Канал аутентифицирован. Серверная сторона диалога всегда аутентифицируется, а клиентская делает это опционно. Канал надежен. Транспортировка сообщений включает в себя проверку целостности.
Преимуществом SSL является то, что он независим от прикладного протокола. Протоколы приложений (HTTP, FTP, TELNET и т.д.) могут работать поверх протокола SSL совершенно прозрачно, т.е. SSL может согласовывать алгоритм шифрования и ключ сессии, а также аутентифицировать сервер до того, как приложение примет или передаст первый байт сообщения.
SSL использует среду с несколькими слоями, что обеспечивает безопасность обмена информацией. Конфиденциальность общения присутствует за счет того, что безопасное соединение открыто только целевым пользователям.
Протокол SSL размещается между двумя протоколами: протоколом, который использует программа-клиент (HTTP, FTP, LDAP, TELNET etc) и транспортным протоколом TCP/IP. SSL защищает данные, выступая в роли фильтра для обеих сторон и передает их далее на транспортный уровень. Работу протокола можно разделить на два уровня: Слой протокола подтверждения подключения (Handshake Protocol Layer) Слой протокола записи
Первый слой, в свою очередь, состоит из трех подпротоколов: Протокол подтверждения подключения (Handshake Protocol) Протокол изменения параметров шифра (Cipher Spec Protocol) Предупредительный протокол (Alert Protocol) Протокол подтверждения подключения используется для согласования данных сессии между клиентом и сервером. К данным сессии относятся: Идентификационный номер сессии Сертификаты обеих сторон Параметры алгоритма шифрования Алгоритм сжатия информации "Общий секрет" применен для создания ключей; открытый ключ
Протокол изменения параметров шифра используется для изменения данных ключа (keyingmaterial) - информации, которая используется для создания ключей шифрования. Протокол состоит всего из одного сообщения, в котором сервер говорит, что отправитель хочет изменить набор ключей.
Предупредительный протокол содержит сообщение, которое показывает сторонам изменение статуса или сообщает о возможной ошибке. Обычно предупреждение отсылается тогда, когда подключение закрыто и получено неправильное сообщение, сообщение невозможно расшифровать или пользователь отменяет операцию.
Протокол подтверждения подключения производит цепочку обмена данными, что в свою очередь начинает аутентификацию сторон и согласовывает шифрование, хэширование и сжатие. Следующий этап - аутентификация участников, которая осуществляется также протоколом подтверждения подключения.
Протокол SSL использует сертификаты для проверки соединения. Cертификаты расположены на безопасном сервере и используются для шифрования данных и идентификации Web-сайта. Способы получения SSL-сертификата: Использовать сертификат, выданный CA Использовать самоподписанный сертификат Использовать «пустой» сертификат
Самоподписанный сертификат - сертификат, созданный самим пользователем — в этом случае издатель сертификата совпадает с владельцем сертификата. «Пустой» сертификат — сертификат, содержащий фиктивную информацию, используемую в качестве временной для настройки SSL и проверки его функциональности в данной среде.
При "утере" приватного ключа RSA криптоаналитик, получивший его, получает возможность расшифровать все записанные прошлые сообщения и будущие сообщения. Реализация обмена ключей в RSA является односторонней: вся необходимая информация для образования симметричного ключа, который создается на этапе рукопожатия, пересылается на сервер и шифруется публичным ключом сервера. Раскрытие приватного ключа дает возможность узнать симметричный ключ данной сессии.
Механизм Fixed Diffie-Hellman использует постоянный публичный ключ, который прописан в сертификате сервера. Это также означает, что при каждом новом соединении клиент предоставляет свою часть ключа. После обмена ключами образуется новый симметричный ключ для обмена информацией для текущей сессии. При раскрытии приватного ключа сервера криптоаналитик может расшифровать ранее записанные сообщения, а также все будущие сообщения. Это становится возможным из-за самого механизма. Так как криптоаналитик знает частный ключ сервера, он сможет узнать симметричный ключ каждой сессии, и даже тот факт, что механизм образования ключа является двусторонним, не поможет. Механизм Anonymous Diffie-Hellman не предоставляет гарантий секретности, ибо данные передаются незашифрованными. Единственный вариант, при котором гарантируется безопасность прошлых и будущих сообщений —Ephemeral Diffie-Hellman. Разница по сравнению с ранее рассмотренными методами заключается в том, что при каждом новом соединении сервером и клиентом создается одноразовый ключ. Таким образом, даже если криптоаналитику достанется текущий частный ключ, он сможет расшифровать только текущую сессию, но не предыдущие или будущие сессии.
Существует два основных способа шифрования данных: симметричный ключ (общий секретный ключ) и асимметричный ключ (открытый ключ).
SSL использует как асимметричную, так и симметричную криптографию.
Суть асимметричного шифрования заключается в том, что используется пара ключей. Один из них используется в качестве открытого (как правило, он публикуется в самом сертификате владельца), второй ключ называется секретным - он держится в тайне и никогда никому не открывается. Оба ключа работают в паре: один используется для запуска противоположных функций другого ключа. Если открытый ключ используется для того, чтобы зашифровать данные, то расшифровать их можно только секретным ключом и наоборот. Такая взаимосвязь позволяет делать две важные вещи. Любой пользователь может получить открытый ключ по назначению и использовать его для шифрования данных, расшифровать которые может только пользователь, владеющий секретным ключом. Если заголовок шифрует данные, используя свой секретный ключ, каждый может расшифровать данные, используя соответствующий открытый ключ. Именно это является основой для цифровых подписей.
RSA - самый распространенный алгоритм шифрования с использованием асимметричных ключей.
При шифровании симметричным ключом используется один и тот же ключ для шифрованных данных. Если стороны хотят обменяться зашифрованными сообщениями в безопасном режиме, то у обеих сторон должны быть одинаковые симметричные ключи. Такой тип шифрования используется для большого объема данных. Обычно используются алгоритмы DES, 3-DES, RC2, RC4 и AES.
Протокол SSL использует шифрование с открытым ключом для аутентификации клиент-сервер и наоборот, а также для определения ключа сессии, который, в свою очередь, используется более быстрыми алгоритмами симметричной криптографии для шифрования большого объема данных.
Хеш-значение является идентификатором сообщения, его размер меньше размера оригинального сообщения. Самыми известными хеш-алгоритмами являются MD5 (Message Digest 5), который создает 128-битное хеш-значение, SHA-1 (Standard Hash Algorithm), создающий 160-битное хеш-значение, SHA-2 и SHA-3. Результат работы алгоритма хеширования - значение, которое используется для проверки целостности передачи данных.
Протокол на уровне слоя записи получает зашифрованные данные от программы-клиента и передает их на транспортный слой. Протокол записи берет данные, разбивает их на блоки и выполняет шифрование (расшифровывание) данных. При этом активно используется информация, которая была согласована во время подтверждения данных.
Протокол SSL позволяет использовать шифрование симметричным ключом, используя либо блочные, либо потоковые шифры. Обычно на практике применяются блочные шифры. Принцип работы блочного шифра заключается в отображении блока открытого текста в такой же блок шифрованного текста. Этот шифр можно представить в виде таблицы, содержащей 2128 строк, каждая строка содержит блок открытого текста M и соответствующий ему блок шифрованного текста C. Подобная таблица существует для каждого ключа.
Шифрование можно обозначить в виде функции
C = E(Key, M), где M - исходные данные, Key - ключ шифрования, С - зашифрованные данные.
Как правило, блоки имеют небольшой размер (обычно 16 байт), поэтому возникает вопрос: как зашифровать длинное сообщение? Первый режим для подобного шифрования называется ECB (Electronic Codebook) или режим простой замены. Его суть состоит в том, что мы разбиваем исходное сообщение на блоки (по те же 16 байт) и шифруем каждый блок отдельно. Однако, данный режим применяет редко из-за проблемы сохранения статистических особенностей исходного текста: 2 одинаковых блока открытого текста после шифрования превратятся в два одинаковых блока зашифрованного текста. Для решения этой проблемы был разработан второй режим - CBC (Cipher-block chaining). В этом случае каждый новый блок шифротекста XOR’ится с предыдущим результатом шифрования. Первый блок XOR’ится c некоторым вектором инициализации (Initialization Vector, IV). Однако вся вышеизложенная теория разработана для одного большого объекта, в то время как SSL, являясь криптографическим протоколом, должен шифровать серию пакетов. В такой ситуации существует два способа применения CBC: Обрабатывать каждое сообщение как отдельный объект, генерируя для него каждый раз новый вектор инициализации Обрабатывать все сообщения как один большой объект, сохраняя режим CBC между ними. В таком случае в качестве вектора инициализации для сообщения n будет использоваться последний блок шифрования предыдущего сообщения (n-1)
При проектировании приложений SSL реализуется поверх любого другого протокола транспортного уровня, таких как HTTP, FTP, SMTP, NNTP и XMPP. Исторически SSL был использован в первую очередь с надёжными транспортными протоколами, такими как Transmission Control Protocol (TCP). Тем не менее, он также был реализован с датаграммными транспортными протоколами, такими как User Datagram Protocol (UDP) и Datagram Control Protocol (DCCP), использование которого было стандартизировано, что привело к появлению термина Datagram Transport Layer Security (DTLS).
Частое использование протокола SSL привело к формированию протокола HTTPS (Hypertext Transfer Protocol Secure), поддерживающего шифрование. Данные, которые передаются по протоколу HTTPS, «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивая защиту этих данных. Такой способ защиты широко используется в мире Веб для приложений, в которых важна безопасность соединения, например в платёжных системах. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443.
Уточнения: В OS X используется TLS, предоставляемый Network Security Services (NSS). По состоянию на март 2013 года NSS 3.14.3 поддерживает TLS 1.0 и 1.1, но не версию 1.2. Firefox 31.2 поддерживает TLS 1.0, 1.1 и 1.2, поддержка SSL 3.0 по умолчанию отключена. IE использует реализацию TLS от операционной системы Microsoft Windows, предоставляемый SChannel. TLS 1.1 и 1.2 по умолчанию отключены. Opera 10 имеет поддержку TLS 1.2. Предыдущие версии поддерживали TLS 1.0 и 1.1[13]. TLS 1.1 и 1.2 по умолчанию отключены (за исключением версии 9). Safari использует реализацию операционной системы Mac OS X, Windows (XP, Vista, 7). Safari 5 является последней версией, доcтупной для Windows. Mobile Safari и программное обеспечение сторонних производителей с использованием библиотечных систем UIWebView поддерживают TLS 1.2, как и iOS 5.0
Изначально виртуальные частные сети (VPN) на основе SSL разрабатывались как дополнительная и альтернативная технология удалённого доступа на основе IPsec VPN. Однако, такие факторы, как достаточная надёжность и дешевизна, сделали эту технологию привлекательной для организации VPN. Также SSL получил широкое применение в электронной почте. Наиболее распространённая реализация SSL — криптографический пакет с открытым исходным кодом OpenSSL, основанный на SSLeay, написанной Эриком Янгом. Последняя версия OpenSSL поддерживает SSLv3. Пакет предназначен для создания и управления различного рода сертификатами. Также в его состав входит библиотека для поддержки SSL различными программами. Библиотека используется, например, модулем SSL в распространенном HTTP-сервере Apache.
Все данные в SSL пересылаются в виде записей или рекордов - объектов, которые состоят из заголовка и некоторого количества данных. Каждый заголовок рекорда содержит 2 или 3 байта кода длины. Если старший бит в первом байте кода длины рекорда равен 1, тогда рекорд не имеет заполнителя и полная длина заголовка равна 2 байтам, в противном случае рекорд содержит заполнитель, и полная длина заголовка равна 3 байтам. В случае длинного (3 байта) заголовка второй по старшинству бит первого байта имеет специальное значение. Если он равен 0 - рекорд является информационным, если он равен 1 - рекорд является security escape. Код длины рекорда не включает в себя число байт заголовка. Для 2-байтового заголовка его длина вычисляется так:
RECORD-LENGTH = ((byte[0] & 0x7F) << 8) | byte;
Здесь byte[0] - первый полученный байт, а byte - второй полученный байт. Для 3-байтового заголовка длина рекорда вычисляется следующим образом:
Значение PADDING специфицирует число байтов добавленных отправителем к исходному рекорду. Данные заполнителя используются для того, чтобы сделать длину рекорда кратной размеру блока шифра. Отправитель добавляет PADDING после имеющихся данных, а затем шифрует все это, т. к. длина этого массива кратна размеру блока используемого шифра. Поскольку известен объем передаваемых данных, заголовок сообщения может быть сформирован с учетом объема PADDING. Получатель сообщения дешифрует все поле данных и получает исходную информацию, затем вычисляет истинное значение RECORD-LENGTH, при этом PADDING из поля "данные” удаляется.
Часть данных рекорда SSL состоит из 3х компонентов: MAC-DATA[MAC-SIZE] ACTUAL-DATA[N] PADDING-DATA[PADDING]
MAC-DATA - код аутентификации сообщения MAC-SIZE - функция используемого алгоритма вычисления хеш-суммы ACTUAL-DATA - реально переданные данные или поле данных сообщения PADDING-DATA - данные PADDING (при блочном шифровании)
Здесь SECRET передается хеш-функции первым, затем следует ACTUAL-DATA и PADDING-DATA, за которыми передается SEQUENCE-NUMBER - порядковый номер. Значение SECRET зависит от того, кто именно посылает сообщение. Если это делает клиент, то SECRET равен CLIENT-WRITE-KEY. Если же клиент получает сообщение, SECRET равен CLIENT-READ-KEY. Порядковый номер представляет собой 32-битовый код, который передается хеш-функции в виде 4 байт, используя сетевой порядок передачи "от старшего к младшему”. Порядковый номер - счетчик для сервера или клиента. Для каждого направления передачи используется пара счетчиков - для отправителя и для получателя; каждый раз, когда отправляется сообщение, счетчик увеличивает свое значение на 1. Получатель сообщения использует ожидаемое значение порядкового номера для передачи MAC (тип хеш-функции определяется параметром CIPHER-CHOICE). Вычисленное значение MAC-DATA должно совпадать с переданным значением. Если сравнение не прошло, сообщение считается поврежденным, что приводит к возникновению ошибки, которая вызывает закрытие соединения. Окончательная проверка соответствия выполняется, когда используется блочный шифр. Объем данных в сообщении (RECORD-LENGTH) должен быть кратен размеру блока шифра. Если данное условие не выполнено, сообщение считается поврежденным, что приводит к разрыву соединения.
Для 2х-байтового заголовка максимальная длина сообщения равно 32767 байтов, для 3х-байтового 16383 байтов. Сообщения протокола диалога SSL должны соответствовать одиночным рекордам протокола SSL, а сообщения прикладного протокола могут занимать несколько рекордов SSL.
SSL поддерживает 3 типа аутентификации: аутентификация обеих сторон (клиент — сервер), аутентификация сервера с неаутентифицированным клиентом, полная анонимность.
Если сервер аутентифицирован, то его сообщение о сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный сервер должен предоставить допустимый сертификат клиенту. Каждая сторона отвечает за проверку того, что сертификат другой стороны еще не истек и не был отменен. Всякий раз, когда сервер аутентифицируется, канал устойчив (безопасен) к попытке перехвата данных между веб-сервером и браузером, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента. Главная цель процесса обмена ключами — это создание секрета клиента (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, сообщения обмена подписываются 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) настолько быстро, насколько это возможно. Параметры клиента должны быть совместимы с теми, которые поддерживает сервер для того, чтобы работал обмен ключами.
Протокол записи (Record Layer) — это уровневый протокол. На каждом уровне сообщения включают поля для длины, описания и проверки. Протокол записи принимает сообщения, которые нужно передать, фрагментирует данные в управляемые блоки, разумно сжимает данные, применяя MAC (message authentication code), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента.
Существует четыре протокола записи: Протокол рукопожатия (handshake protocol); Протокол тревоги (alert protocol); Протокол изменения шифра (the change cipher spec protocol); Протокол приложения (application data protocol);
Если SSL реализация получает тип записи, который ей неизвестен, то эта запись просто игнорируется. Любой протокол, созданный для использования совместно с SSL, должен быть хорошо продуман, так как будет иметь дело с атаками на него. Заметим, что из-за типа и длины записи, протокол не защищен шифрованием. Внимание следует уделить тому, чтобы минимизировать трафик.
SSL клиент и сервер договариваются об установлении связи с помощью процедуры рукопожатия. Во время рукопожатия клиент и сервер договариваются о различных параметрах, которые будут использованы, чтобы обеспечить безопасность соединения: Клиент посылает серверу номер версии SSL клиента, поддерживаемые алгоритмы шифрования и сжатия, специфичные данные для сеанса и другую информацию, которая нужна серверу, чтобы общаться с клиентом, используя SSL. Сервер посылает клиенту номер версии SSL сервера, алгоритм сжатия и шифрования (выбранные из посланных ранее клиентом), специфичные данные для сеанса и другую информацию, которая нужна серверу, чтобы общаться с клиентом по протоколу SSL. Сервер также посылает свой сертификат, который требует проверки подлинности клиента. После идентификации сервер запрашивает сертификат клиента. Клиент использует информацию, переданную сервером для проверки подлинности. Если сервер не может быть проверен, пользователь получает предупреждение о проблеме и о том, что шифрование и аутентификация соединения не может быть установлена. Если сервер успешно прошел проверку, то клиент переходит к следующему шагу. Используя все данные, полученные до сих пор от процедуры рукопожатие, клиент (в сотрудничестве с сервером) создает предварительный секрет сессии, в зависимости от используемого шифра от сервера, шифрует его с помощью открытого ключа сервера (полученного из сертификата сервера, отправленного на 2-м шаге), а затем отправляет его на сервер. Если сервер запросил аутентификацию клиента (необязательный шаг рукопожатия), клиент также подписывает еще один кусок данных, который является уникальным для этого рукопожатия и известным как для клиента, так и сервера. В этом случае, клиент отправляет все подписанные данные и собственный сертификат клиента на сервер вместе с предварительно зашифрованным секретом. Сервер пытается аутентифицировать клиента. Если клиент не может пройти проверку подлинности, сеанс заканчивается. Если клиент может быть успешно аутентифицирован, сервер использует свой закрытый ключ для расшифровки предварительного секрета, а затем выполняет ряд шагов (которые клиент также выполняет), чтобы создать главный секрет. И клиент, и сервер используют секрет для генерации ключей сеансов, которые являются симметричными ключами, использующиеся для шифрования и расшифрования информации, которой обмениваются во время SSL сессии. Происходит проверка целостности (то есть, для обнаружения любых изменений в данных между временем когда он был послан, и временем его получения на SSL-соединении). Клиент посылает сообщение серверу, информируя его, что будущие сообщения от клиента будут зашифрованы с помощью ключа сеанса. Затем он отправляет отдельное, зашифрованное сообщение о том, что часть рукопожатие закончена. И в заключение, сервер посылает сообщение клиенту, информируя его, что будущие сообщения от сервера будут зашифрованы с помощью ключа сеанса. Затем он отправляет отдельное, зашифрованное сообщение о том, что часть рукопожатие закончена.
На этом рукопожатие завершается, и начинается защищенное соединение, которое зашифровывается и расшифровывается с помощью ключевых данных. Если любое из перечисленных выше действий не удается, то рукопожатие SSL не удалось, и соединение не создается.
