SSL

Материал из Википедии — свободной энциклопедии
Это старая версия этой страницы, сохранённая 95.156.66.54 (обсуждение) в 06:42, 15 апреля 2014 (→Браузеры). Она может серьёзно отличаться от текущей версии.
Перейти к навигации Перейти к поиску

SSL (англ. Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, который обеспечивает безопасность связи [1]. Он использует асимметричную криптографию для аутентификации ключей обмена, симметричное шифрование для сохранения конфиденциальности, коды аутентификации сообщений для целостности сообщений. Протокол широко используется для обмена мгновенными сообщениями и передачи голоса через IP (англ. Voice over IP - VoIP), в таких приложениях, как электронная почта, Интернет-факс и др.

SSL изначально разработан компанией Netscape Communications для добавления протокола HTTPS в свой веб-браузер Netscape Navigator. Впоследствии, на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS.

Описание

Протокол SSL позволяет общаться клиенту с сервером в сети, предотвращая перехват или фальсификацию. Так как протоколы могут работать либо без SSL либо поверх SSL, то для клиента необходимо указать серверу, хочет ли он установить соединение SSL или нет. Есть две возможности сделать это. Одним из вариантов является использование различных номеров портов для соединения SSL (например, порт 443 для HTTPS). Другой заключается в использовании регулярного номера порта, сервер установит соединение с клиентом, используя протокол конкретного механизма (например, STARTTLS для почты и новостных протоколов). После того как клиент и сервер решили использовать SSL, они ведут переговоры, отслеживая состояние соединения с помощью процедуры рукопожатия [2]. Во время этого рукопожатия клиент и сервер соглашаются на различные параметры, используемые для установки безопасного соединения. После завершения процедуры рукопожатия начинается защищенное соединение. Клиент и сервер используют сеансовые ключи для шифрования и расшифрования данных, которые они посылают друг другу. Это нормальный алгоритм работы по защищенному каналу. В любое время, в связи с внутренним или внешним раздражителем (автоматическое вмешательство или вмешательство пользователя), любая из сторон может пересмотреть сеанс связи. В этом случае, весь процесс повторяется. SSL работает модульным способом.

В протоколе SSL все данные передаются в виде записей-объектов, состоящих из заголовка и передаваемых данных. Передача начинается с заголовка. Заголовок содержит либо два, либо три байта кода длины. Причём, если старший бит в первом байте кода равен единице, то полная длина заголовка равна двум байтам, иначе - длина заголовка равна трём байтам.Код длины записи не включает в себя число байт заголовка. Длина записи 2-байтового заголовка: 

RecLength = ((byte[ 0 ] & 0x7F) << 8) | byte[ 1 ];

Здесь byte[0] и byte[1] — первый и второй полученные байты. Длина записи 3-байтового заголовка: 

RecLength = ((byte[ 0 ] & 0x3F) << 8) | byte[ 1 ];
Escape = (byte[ 0 ] & 0x40) != 0;
Padding = byte[ 2 ];

Здесь Padding определяет число байтов, добавленных отправителем к исходному тексту, для того, чтобы сделать длину записи кратной размеру блока шифра, при использовании блочного шифра. Теперь отправитель «заполненной» записи добавляет заполнитель после имеющихся данных и шифрует всё это. Причем не важно содержание заполнителя. Из-за того, что известен объём передаваемых данных, заголовок может быть сформирован с учетом Padding. В свою очередь получатель записи расшифровывает все поля данных и получает полную исходную информацию. Затем производится вычисление значения RecLength по известному Padding, и заполнитель из поля данных удаляется. Данные записи SSL состоят из 3 компонент:

  • MAC_Data[Mac_Size] — (Message Authentication Code) — код аутентификации сообщения
  • Padding_Data[Padding] — данные заполнителя
  • Actual_Data[N] — реальные данные

Когда записи посылаются открытым текстом, очевидно, что никакие шифры не используются. Тогда длина Padding_Data и MAC_Data равны нулю. При использовании шифрования Padding_Data зависит от размера блока шифра, а MAC_Data зависит от выбора шифра. Пример вычисления MAC_Data: 

MacData = Hash(Secret, Actual_Data, Padding_Data, Sequence_Number);

Значение Secret зависит от того, кто (клиент или сервер) посылает сообщение. Sequence_Number — счётчик, который инкрементируется как сервером, так и клиентом. Здесь Sequence_Number представляет собой 32-битовый код, передаваемый хэш-функции. Для MD2, MD5 MAC_Size равен 16 байтам (128 битам). Для 2-байтового заголовка максимальная длина записи равна 32767 байтов, а для 3-байтного заголовка — 16383 байтов.

История и развитие

SSL 1.0, 2.0 и 3.0

Протокол SSL был изначально разработан компанией Netscape Communications. Версия 1.0 никогда не была обнародована. Версия 2.0 была выпущена в феврале 1995 года, но содержала много недостатков по безопасности, которые привели к разработке SSL версии 3.0. [3] SSL версии 3.0, выпущенная в 1996 году, послужила основой для создания протокола TLS 1.0, стандарт протокола Internet Engineering Task Force (IETF), который впервые был определен в RFC 2246 в январе 1999 года. Visa, Master Card, American Express и многие другие организации имеют лицензию на использование протокола SSL для коммерческих целей в сети Интернет. Тем самым SSL расширяемо в соответствии с проектом о поддержке прямой и обратной совместимости и переговорам между соединениями в одноранговой сети.

TLS 1.0

TLS 1.0 впервые был определен в RFC 2246 в январе 1999 года в качестве обновления версии SSL 3.0. Как указано в RFC "различия между этим протоколом и SSL 3.0 не критичны, но они значительны для появления несовместимости при взаимодействии TLS 1.0 и SSL 3.0". TLS 1.0 действительно включает средства, с помощью которых реализация подключения TLS к SSL 3.0, ослабит безопасность.

TLS 1.1

TLS 1.1 презентовали в RFC 4346 в апреле 2006 года.[4] Это было обновление TLS версии 1.0 Значительные изменения в этой версии включают в себя:

  • Добавлена ​​защита от атак, использующих режим сцепления блоков шифротекста (Cipher Block Chaining).
    • Неявный Вектор инициализации (IV) был заменен на явный IV.
    • Было проведено изменение в обработке ошибок.
  • Введена поддержка IANA регистрации параметров.

TLS 1.2

TLS 1.2 был анонсирован в RFC 5246 в августе 2008 года. Он основан на ранее предложенной версии TLS 1.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.

Сайт поддержки протокола
Версия протокола Безопасность Поддержка сайтами
SSL 2.0 Нет 28.4%
SSL 3.0 Может быть 99.8%
TLS 1.0 99.4%
TLS 1.1 Да 10.4%
TLS 1.2 12.7%

Браузеры

По состоянию на 2013 г. все основные веб-браузеры, поддерживающие SSL/TLS:

Браузеры, поддерживающие SSL/TLS
Браузер Платформы TLS 1.0 TLS 1.1 TLS 1.2
Chrome 28 Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8)[a][b] Да Да Да
Chrome 22–текущая Android, iOS, Linux, Mac OS X, Windows (XP, Vista, 7, 8)[a][b] Да[5] Да[5] Нет[5]
Firefox 27–текущая Linux, Mac OS X, Windows (XP, Vista, 7, 8)[c][b] Да[6] Да[7] Да[8]
IE 6 Windows (XP)[d] Да Да Нет
IE 7–8 Windows (XP, Vista)[d] Да Нет Нет
IE 8–9 Windows 7[d] Да Да Да
IE 9 Windows Vista[d] Да Нет Нет
IE 10 Windows (7, 8)[d] Да Да Да
Opera 5–7 Linux, Mac OS X, Windows Да[9] Нет Нет
Opera 8–9 Linux, Mac OS X, Windows Да Да[10] Нет
Opera 10–текущая Linux, Mac OS X, Windows[e] Да Да Да
Safari 4 Mac OS X, Windows (XP, Vista, 7), iOS 4.0[f] Да Нет Нет
Safari 5 Mac OS X, Windows (XP, Vista, 7)[f] Да Нет Нет
Safari 5–текущая iOS 5.0–[g] Да Да Да

Уточнения:

  • Google Chrome поддерживает TLS 1.0 и TLS 1.1, начиная с версии 22 (она была добавлена, но потом был откат до 21 версии). TLS 1.2 не поддерживается.[11][12]
  • В OS X используется TLS предоставляемые от Network Security Services (NSS). По состоянию на март 2013 года, NSS 3.14.3 поддерживает TLS 1.0 и 1.1, но не версию 1.2.
  • Firefox поддерживает TLS 1.1 и TLS 1.2 начиная с версии 27.
  • IE использует реализацию TLS от операционной системы Microsoft Windows предоставляемых SChannel. TLS 1.1 и 1.2 по умолчанию отключены.[13][14]
  • Opera 10 имеет поддержку TLS 1.2. Предыдущие версии поддерживали TLS 1.0 и 1.1.[15] TLS 1.1 и 1.2 по умолчанию отключены (за исключением версии 9[16] ).
  • Safari использует реализацию операционной системы Mac OS X, Windows (XP, Vista, 7)[17][18] Safari 5 является последней версией доступной для Windows.
  • Mobile Safari и программное обеспечение сторонних производителей с использованием библиотечных систем UIWebView поддерживают TLS 1.2 как и iOS 5.0.[19][20][21]

Использование и реализация

Изначально виртуальные частные сети (VPN) на основе SSL разрабатывались как дополнительная и альтернативная технология удалённого доступа на основе IPsec VPN. Однако, такие факторы, как достаточная надёжность и дешевизна сделали эту технологию привлекательной для организации VPN. Также SSL получил широкое применение в электронной почте. Наиболее распространенная реализация SSL — криптографический пакет с открытым исходным кодом OpenSSL, основанный на SSLeay, написанной Эриком Янгом. Последняя версия OpenSSL поддерживает SSLv3. Пакет предназначен для создания и управления различного рода сертификатами. Так же в его состав входит и библиотека для поддержки SSL различными программами. Библиотека используется, например, модулем SSL в распространенном HTTP-сервере Apache.

Аутентификация и обмен ключами

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, который посылается в сообщении обмена ключами от сервера. Когда используется временный ключ RSA, сообщения обмена подписываются server’s RSA или сертификат DSS. Сигнатура включает текущее значение сообщения Client_Hello.random, таким образом старые сигнатуры и старые временные ключи не могут повторяться. Сервер может использовать временный ключ RSA только однажды для создания сессии. После проверки сертификата сервера клиент шифрует секрет (pre_master_secret) при помощи открытого ключа сервера. После успешного декодирования секрета (pre_master_secret) создается сообщение «finished», тем самым сервер демонстрирует, что он знает частный ключ, соответствующий сертификату сервера.

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

Аутентификация и обмен ключами при использовании Diffie-Hellman

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

Если клиент имеет сертификат, содержащий параметры алгоритма Diffie-Hellman, то сертификат также содержит информацию, требуемую для того, чтобы завершить обмен ключами. Заметим, что в этом случае клиент и сервер должны будут сгенерировать те же Diffie-Hellman результаты (pre_master_secret), каждый раз, когда они устанавливают соединение. Для того чтобы предотвратить остановку секрета (pre_master_secret) в памяти компьютера на время дольше, чем необходимо, секрет должен быть переведен в общий секрет (master_secret) настолько быстро, на сколько это возможно. Параметры клиента должны быть совместимы с теми, которые поддерживает сервер для того, чтобы работал обмен ключами.

Протокол записи

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

Существует четыре протокола записи:

  1. Протокол рукопожатия (handshake protocol);
  2. Протокол тревоги (alert protocol);
  3. Протокол изменения шифра (the change cipher spec protocol);
  4. Протокол приложения (application data protocol);

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

Протокол рукопожатия

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

  1. Клиент посылает серверу номер версии SSL клиента, зашифрованные параметры, специфичные данные для сеанса и другую информацию, которая нужна серверу, чтобы общаться с клиентом, используя SSL.
  2. Сервер посылает клиенту номер версии SSL сервера, зашифрованные параметры, специфичные данные для сеанса и другую информацию,которая нужна серверу, чтобы общаться с клиентом по протоколу SSL. Сервер также посылает свой ​​сертификат, который требует проверки подлинности клиента. После идентификации сервер запрашивает сертификат клиента.
  3. Клиент использует информацию, переданную сервером для проверки подлинности. Если сервер не может быть проверен, пользователь получает предупреждение о проблеме и о том, что шифрование и аутентификация соединения не может быть установлена. Если сервер успешно прошел проверку, то клиент переходит к следующему шагу.
  4. Используя все данные, полученные до сих пор от процедуры рукопожатия, клиент (в сотрудничестве с сервером) создает предварительный секрет сессии, в зависимости от используемого шифра от сервера, шифрует его с помощью открытого ключа сервера (полученного из сертификата сервера , отправленного на 2-м шаге), а затем отправляет его на сервер.
  5. Если сервер запросил аутентификацию клиента (необязательный шаг рукопожатия), клиент также подписывает еще один кусок данных, который является уникальным для этого рукопожатия и известным как для клиента, так и сервера. В этом случае, клиент отправляет все подписанные данные и собственный сертификат клиента на сервер вместе с предварительно зашифрованным секретом.
  6. Сервер пытается аутентифицировать клиента. Если клиент не может пройти проверку подлинности, сеанс заканчивается. Если клиент может быть успешно аутентифицирован, сервер использует свой ​​закрытый ключ для расшифровки предварительного секрета, а затем выполняет ряд шагов (которые клиент также выполняет), чтобы создать главный секрет.
  7. И клиент, и сервер используют секрет для генерации ключей сеансов, которые являются симметричными ключами, использующимися для шифрования и расшифрования информации, которой обмениваются во время SSL сессии. Происходит проверка целостности (то есть для обнаружения любых изменений в данных между временем, когда он был послан, и временем его получения на SSL-соединении).
  8. Клиент посылает сообщение серверу, информируя его, что будущие сообщения от клиента будут зашифрованы с помощью ключа сеанса. Затем он отправляет отдельное, зашифрованное сообщение о том, что часть рукопожатие закончена.
  9. И в заключение, сервер посылает сообщение клиенту, информируя его, что будущие сообщения от сервера будут зашифрованы с помощью ключа сеанса. Затем он отправляет отдельное, зашифрованное сообщение о том, что часть рукопожатие закончена.

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

Протокол изменения параметров шифрования

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

struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;

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

Протокол тревоги

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

Протокол приложения

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

Безопасность

Существует ряд атак, которые могут быть предприняты против протокола SSL. Однако SSL устойчив к этим атакам, при условии, что пользователь использует только доверенные сервера для обработки информации. SSL 2.0 уязвима в некоторых ситуациях:[22]

  1. Идентичные криптографические ключи используются для аутентификации и шифрования сообщений,
  2. SSL 2.0 имеет слабую MAC конструкцию, которая использует MD5 хэш-функцию с секретом префикса, что делает его уязвимым для атак,
  3. SSL 2.0 не имеет никакой защиты для протокола рукопожатия, то есть атака типа злоумышленник посередине (man-in-the-middle) могут остаться незамеченными,
  4. SSL 2.0 использует закрытие TCP соединения, чтобы указать конец данных. Это означает что возможна следующая атака: злоумышленник просто подделывает TCP FIN, оставив получателя без сообщения о конце передачи данных (в SSL 3.0 эту ошибку исправили)
  5. SSL 2.0 предполагает наличие единой службы поддержки и фиксированного домена, что идет вразрез со стандартной функцией виртуального хостинга на веб-серверах.

SSL 2.0 по умолчанию отключена в браузерах, начиная с Internet Explorer 7,[23] Mozilla Firefox 2,[24] Opera 9.5,[25] и Safari. TLS имеет целый ряд мер безопасности. С точки зрения безопасности, SSL 3.0 следует считать менее надежным, чем TLS 1.0. В SSL 3.0 есть слабые моменты. К примеру, половина мастер-ключа (master key), которая устанавливается, полностью зависит от хэш-функции MD5, которая не является устойчивой к коллизиям и, следовательно, не считается безопасной.[26]

Атака отклика

Злоумышленник записывает коммуникационную сессию между сервером и клиентом. Позднее, он пытается установить соединение с сервером, воспроизводя записанные сообщения клиента. Но SSL отбивает эту атаку при помощи особого уникального идентификатора соединения (ИС). Конечно, теоретически третья сторона не в силах предсказать ИС, потому что он основан на наборе случайных событий. Однако, злоумышленник с большими ресурсами может записать большое количество сессий и попытаться подобрать «верную» сессию, основываясь на коде nonce, который послал сервер в сообщение Server_Hello. Но коды nonce SSL имеют, по меньшей мере, длину 128 бит, а значит, злоумышленнику необходимо записать кодов nonce, чтобы получить вероятность угадывания 50 %. Но достаточно большое число, что делает эти атаки бессмысленными.

Атака протокола рукопожатия

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

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

Взлом SSL-соединений агентами ФБР с помощью систем Carnivore и NarusInsight

Наиболее известный инцидент по массовому взлому информации, защищенной протоколами SSL, был произведен агентами ФБР с помощью систем Carnivore и NarusInsight, что привело к судебному процессу от лица правозащитной организации Electronic Frontier Foundation против AT&T, который установил данные комплексы для взлома криптографически защищенной информации.

Несмотря на высокий общественный резонанс в США данного дела и расследование на уровне конституционного комитета Палаты представителей, технологически взлом протокола SSL агентами ФБР не производился. Carnivore и NarusInsight были установлены в самом ЦОД, где находились сервера, ведущие SSL-соединенения с удаленными клиентами. NarusInsight полностью восстановил зашифрованную информацию путем прослушивания не SSL-соединения, а внутреннего траффика между серверами приложений внутри самого ЦОД, уже после того как данные, поступившие по SSL, были расшифрованы самим сервером, их принявшим от внешних пользователей.

Тем не менее, указанный инцидент показал, что SSL не может являться надежным средством криптозащиты данных серверов в Интернете, так как спецслужбы могут установить системы прослушивания, такие как NarusInsight или СОРМ-2, в ЦОД. Любой вид криптографии, подразумевающий, что ключи от шифров находятся у сервера-получателя в ЦОД, взламываются снифферами спецслужб в автоматическом режиме за счет внедрения их в самого получателя. Далее данные полностью реконструируются по процедурам, которые на данный момент регулируются и законодательными актами, такими как «Патриотический акт». Причем указанные законодательные акты запрещают вплоть до судебного преследования владельцев ЦОД удаление снифферов спецслужб из внутренней части серверов-получателей. С учетом наличия данных систем, протокол SSL может защищать только соединение двух пользователей в Интернете, но не SSL-соединение с внешним Web-сайтом.

BEAST атака

23 сентября 2011 года тайские исследователи Дуонг и Джулиано Риццо продемонстрировали "доказательство концепции" под названием Beast, ("Browser Exploit Against SSL/TLS") используя Java апплет, продемонстрировали уязвимость в TLS 1.0.[27][28] Практически, ранее эту уязвимость, которая первоначально была обнаружена Phillip Rogaway[29] в 2002 году, никто не мог продемонстрировать. Уязвимость TLS 1.1 была зафиксирована в 2006 году.

RC4 атака

Несмотря на существующие атаки на RC4, шифр на основе RC4 в SSL и TLS считали безопасным. В 2011 RC4 был рекомендован как средство защиты от Beast атаки.[30] Однако в 2013 году было совершено нападение по сценарию, предложенному Алфардом, Бернштейном, Патерсоном, Поттерингом и Шхултдом, которые использовали новые статистические погрешности в RC4 ключе.[31][32][33]

Раскрытие шифров

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

Из-за того, что большинство SSL-сайтов не используют алгоритмы со свойством perfect forward secrecy (PFS)[34], злоумышленник записавший зашифрованные сессии, сможет их прочитать после того как получит приватный ключ RSA.

Злоумышленник посередине

Также известна как MitM (Man-in-the-Middle) атака. Предполагает участие трех сторон: сервера, клиента и злоумышленника, находящегося между ними. В данной ситуации злоумышленник может перехватывать все сообщения, которые следуют в обоих направлениях, и подменять их. Злоумышленник представляется сервером для клиента и клиентом для сервера. В случае обмена ключами по алгоритму Диффи-Хелмана данная атака является эффективной, так как целостность принимаемой информации и ее источник проверить невозможно. Однако такая атака практически невозможна при использовании протокола SSL[35], так как для проверки подлинности источника (обычно сервера) используются сертификаты, заверенные центром сертификации[36] .

Атака будет успешной, если:

  • Сервер не имеет подписанного сертификата.
  • Клиент не проверяет сертификат сервера.
  • Пользователь игнорирует сообщение об отсутствии подписи сертификата центром сертификации или сообщение о несовпадении сертификата с кэшированным[37]

Данный вид атаки можно встретить в крупных организациях, использующих межсетевые экраны с возможностью работы в режиме SSL Interception proxy[38], например Forefront TMG компании Microsoft. В данном случае "злоумышленник" находится на границе сети организации и производит подмену оригинального сертификата своим. Данная атака становится возможной благодаря добавлению на клиентские компьютеры в список доверенных корневых центров сертификата, используемого в данном экране.[39] Подобная процедура добавления может производиться прозрачно для пользователя за счет работы корпоративных пользователей в среде Active Directory. Данное средство может использоваться как для контроля за передаваемой информацией, так и в целях похищения личных данных, передаваемых с помощью защищенного соединения HTTPS.

Наиболее спорным становится вопрос информированности пользователя о возможности перехвата данных, т.к. в случае подмены корневого сертификата никаких сообщений безопасности выводиться не будет и пользователь будет ожидать конфиденциальности передаваемых данных. Кроме того, при использовании Forefront TMG в качестве SSL-прокси возникает возможность проведения второй MitM-атаки на стороне интернета, т.к. оригинальный сертификат не будет передан пользователю, а Forefront TMG может быть настроен на прием и последующую подмену самоподписанных или отозванных сертификатов. Для защиты от подобной атаки необходимо полностью запретить работу с веб-серверами, чьи сертификаты содержат какие-либо ошибки, что безусловно приведет к невозможности работы по протоколу HTTPS со множеством сайтов.

Обработка ошибок в протоколе SSL

В протоколе SSL обработка ошибок очень проста. Когда ошибка обнаружена, тот, кто её обнаружил, посылает об этом сообщение своему партнёру. Неустранимые ошибки требуют от сервера и клиента разрыва соединения.[40] Протокол SSL определяет следующие ошибки:

  1. Unsupported_Certificate_Type_Error: такая ошибка возникает, когда клиент/сервер получает тип сертификата, который не поддерживается. Ошибка устранима (только для аутентификации клиента).
  2. No_Cipher_Error: ошибка возникает, когда сервер не может найти размер ключа или шифр, который поддерживается также и клиентом. Ошибка неустранима.
  3. Bad_Certificate_Error: такая ошибка возникает, когда сертификат считается принимающей стороной плохим. Это означает, что или некорректна подпись сертификата, или его значение некорректно. Ошибка устранима (только для аутентификации клиента).
  4. No_Certificate_Error: если послано сообщение Request_Certificate, то эта ошибка может быть прислана по причине того, что клиент не имеет сертификата. Ошибка устранима.

Алгоритмы, использующиеся в SSL

См. также

Примечания

  1. ↑ P. Karlton, P. Kocher. The Secure Sockets Layer (SSL) Protocol Version 3.0 (англ.) (август 2011). Дата обращения: 24 мая 2013. Архивировано 24 мая 2013 года.
  2. ↑ Microsoft TechNet. SSL/TLS in Detail SSL/TLS in Detail (англ.). July 31, 2003. Дата обращения: 9 мая 2013.
  3. ↑ THE SSL PROTOCOL (англ.). Netscape Corporation. Дата обращения: 20 мая 2013. Архивировано 14 июня 1997 года.
  4. ↑ Dierks, T. and E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.1, RFC 4346 (англ.). Дата обращения: 9 мая 2013. Архивировано 9 февраля 2012 года.
  5. ↑ 1 2 3 SSSL/TLS Overview (англ.) (6 августа 2008). Дата обращения: 9 мая 2013. Ошибка в сносках?: Неверный тег <ref>: название «SSL/TLS Overview» определено несколько раз для различного содержимого
  6. ↑ Security in Firefox 2 (англ.) (6 августа 2008). Дата обращения: 9 мая 2013.
  7. ↑ Bug 733647 - Implement TLS 1.1 (RFC 4346) in Gecko (Firefox, Thunderbird), on by default (англ.) (6 марта 2012). Дата обращения: 9 мая 2013.
  8. ↑ Bug 480514 - Implement support for TLS 1.2 (RFC 5246) (англ.) (17 марта 2010). Дата обращения: 9 мая 2013.
  9. ↑ "Changelog for Opera 5.x for Windows" at Opera.com
  10. ↑ "Changelog for Opera [8] Beta 2 for Windows" at Opera.com
  11. ↑ Google. Dev Channel (англ.) (29 мая 2012). Дата обращения: 9 мая 2013. Архивировано 17 апреля 2013 года.
  12. ↑ Google. Stable Channel (англ.) (21 августа 2012). Дата обращения: 9 мая 2013. Архивировано 17 апреля 2013 года.
  13. ↑ Microsoft. Secure Channel (англ.) (5 сентября 2012). Дата обращения: 9 мая 2013. Архивировано 17 апреля 2013 года.
  14. ↑ Microsoft. MS-TLSP Appendix A (англ.) (27 февраля 2009). Дата обращения: 9 мая 2013. Архивировано 17 апреля 2013 года.
  15. ↑ Yngve Nysæter Pettersen. New in Opera Presto 2.2: TLS 1.2 Support (англ.) (25 февраля 2009). Дата обращения: 9 мая 2013. Архивировано 17 апреля 2013 года.
  16. ↑ "Changelog for Opera 9.0 for Windows" at Opera.com
  17. ↑ Adrian, Dimcev. Common browsers/libraries/servers and the associated cipher suites implemented (англ.). TLS Cipher Suites Project. Дата обращения: 9 мая 2013. Архивировано 17 апреля 2013 года.
  18. ↑ Apple. Features (англ.) (10 июня 2009). Дата обращения: 9 мая 2013. Архивировано 17 апреля 2013 года.
  19. ↑ Apple. Technical Note TN2287 - iOS 5 and TLS 1.2 Interoperability Issues (англ.) (14 октября 2011). Дата обращения: 9 мая 2013.
  20. ↑ Liebowitz, Matt. Apple issues huge software security patches (англ.). NBCNews.com (13 октября 2011). Дата обращения: 9 мая 2013. Архивировано 17 апреля 2013 года.
  21. ↑ MWR Info Security. Adventures with iOS UIWebviews (англ.) (16 апреля 2012). Дата обращения: 9 мая 2013. Архивировано 17 апреля 2013 года., section "HTTPS (SSL/TLS)"
  22. ↑ Joris Claessens, Valentin Dem, Danny De Cock, Bart Preneel, Joos Vandewalle. On the Security of Today's Online Electronic Banking Systems (англ.) 253–265 (2002). Дата обращения: 11 мая 2013.
  23. ↑ Lawrence Eric. IEBlog: Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2 (англ.). MSDN Blogs (25 ноября 2007). Дата обращения: 11 мая 2013. Архивировано 17 апреля 2013 года.
  24. ↑ Mozilla Corporation. Bugzilla@Mozilla — Bug 236933 - Disable SSL2 and other weak ciphers (англ.). Дата обращения: 11 мая 2013.
  25. ↑ "Opera 9.5 for Windows Changelog" at Opera.com: "Disabled SSL v2 and weak ciphers."
  26. ↑ National Institute of Standards and Technology. Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program (англ.) (декабрь 2010). Дата обращения: 11 мая 2013. Архивировано 17 апреля 2013 года.
  27. ↑ Dan Goodin. Hackers break SSL encryption used by millions of sites (англ.) (19 сентября 2011). Дата обращения: 11 мая 2013. Архивировано 17 апреля 2013 года.
  28. ↑ Y Combinator comments on the issue (англ.) (20 сентября 2011). Дата обращения: 11 мая 2013. Архивировано 17 апреля 2013 года.
  29. ↑ Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures (англ.) (20 мая 2004). Дата обращения: 11 мая 2013.
  30. ↑ Safest ciphers to use with the BEAST? (англ.). Дата обращения: 24 мая 2013. Архивировано 25 июля 2013 года.
  31. ↑ Pouyan Sepehrdad, Serge Vaudenay, Martin Vuagnoux (2011). "Discovery and Exploitation of New Biases in RC4". Lecture Notes in Computer Science (англ.). 6544: 74—91. Дата обращения: 11 мая 2013.{{cite journal}}: Википедия:Обслуживание CS1 (множественные имена: authors list) (ссылка)
  32. ↑ Green, Matthew. Attack of the week: RC4 is kind of broken in TLS (англ.). Cryptography Engineering (12 марта 2013). Дата обращения: 11 мая 2013. Архивировано 17 апреля 2013 года.
  33. ↑ Nadhem AlFardan, Dan Bernstein, Kenny Paterson, Bertram Poettering and Jacob Schuldt. On the Security of RC4 in TLS (англ.). Royal Holloway University of London (13 марта 2013). Дата обращения: 11 мая 2013. Архивировано 13 мая 2013 года.
  34. ↑ SSL: Intercepted today, decrypted tomorrow
  35. ↑ Eric Rescorla. Understanding the TLS Renegotiation Attack (англ.). Educated Guesswork (5 ноября 2009). Дата обращения: 11 мая 2013. Архивировано 28 апреля 2013 года.
  36. ↑ Simon Josefsson. GnuTLS 2.10.0 released (англ.). GnuTLS release notes (25 июня 2010). Дата обращения: 11 мая 2013. Архивировано 28 апреля 2013 года.[нет в источнике]
  37. ↑ Adrian Dimcev. SSL/TLS version rollbacks and browsers (англ.). Random SSL/TLS 101. Дата обращения: 11 мая 2013. Архивировано 9 марта 2011 года.
  38. ↑ SSL Interception Proxies and Transitive Trust // Jeff Jarmoc (Dell), BlackHat 2012: "Enterprise Response: • Intercept, Inspect, Filter: DLP, Web Content Filters, Anti-Malware Solutions, IDS / IPS, NG / DPI Firewalls, Endpoint Security Suites. • Broadly termed ‘SSL Interception Proxies’"
  39. ↑ SSL Interception on Proxy SG: "The CA certificate should be loaded onto any workstation that will be intercepted transparently. This is analogous to the workstation being in Active Directory, where part of joining the domain is that the Domain Root Certificate is installed on the workstation. "
  40. ↑ Kaspar Brand. Named-based SSL virtual hosts: how to tackle the problem (англ.) (18 апреля 2007). Дата обращения: 20 мая 2013.
  41. ↑ Christopher Allen, Tim Dierks. Протокол SSL – Перевод – версия 1.0. Certicom. Семенов Ю. А.. Дата обращения: 20 мая 2013. Архивировано 25 мая 2013 года.
  42. ↑ David Wagner. Analysis of the SSL 3.0 Protocol (англ.). University of California. Дата обращения: 24 мая 2013. Архивировано 24 мая 2013 года.

Ссылки

  • Mozilla.org — введение в SSL протокол

Литература

Книги
  • Pouyan Sepehrdad. Discovery and Exploitation of New Biases in RC4. — 1-st. — Springer Berlin Heidelberg, 2011. — Т. 1. — С. 24. — 91 с. — ISBN 978-3-642-19573-0.
  • Joris Claessens. COmputer Security and Industrial Cryptography. — 3-t. — Leuven—Heverlee, Belgium, 2002. — Т. 1. — С. 253–265. — 287 с. — ISBN 0167-4048.
  • John Viega. Network Security with OpenSSL. — 1-st. — O'Reilly Media, USA, June 15, 2002. — Т. 1. — 386 pages с. — ISBN 978-0596002701.
  • Eric Rescorla. SSL and TLS: Designing and Building Secure Systems. — 1-st. — Addison-Wesley Professional, October 27, 2000. — Т. 1. — 528 pages с. — ISBN 978-0201615982.
  • Stephen Thomas. SSL & TLS Essentials: Securing the Web. — 1-st. — Wiley, February 11, 2000. — Т. 1. — 224 pages с. — ISBN 978-0471383543.
Статьи
  • Описание протоколов SSL/TLS // 3. — ООО "КРИПТО-ПРО"., 2002. — P. 49.
  • Семенов Ю.А. Протокол SSL. Безопасный уровень соединителей. — 2000. — № 1.
  • E. Rescorla. The Transport Layer Security (TLS) Protocol Version 1.2 // 1-st. — RTFM, Inc., August 2008. — № 1. — P. 101.
  • P. Karlton. The Secure Sockets Layer (SSL) Protocol Version 3.0 // 1-st. — RTFM, Inc., August 2011. — № 1. — P. 67.
  • T. Dierks. The Secure Sockets Layer (SSL) // 1-st. — RTFM, Inc., August 2008. — № 1. — P. 207.
Источник — https://ru.wikipedia.org/ruwiki/w/index.php?title=SSL&oldid=62548416