Как работает ssl? принцип работы https соединения

Содержание

Какие типы сертификатов бывают и как выбрать нужный?

Domain Validation (DV)

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


Organization Validation (OV)

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

Важно: при таком способе сертификации для домена обязательно должны быть указаны данные о организации (отображаться в whois). Если же вы являетесь физлицом, то такой сертификат для вас получить попросту невозможно

Кому подойдут такие сертификаты — сказать сложно. Дело в том, что для конечного пользователя (посетителя сайта) разницы между OV и DV нет. Неплохо иметь такой тип сертификата в случае, если с сайта осуществляются платежи, а бюджета на EV нет. Но в подобной ситуации обычно используются интегрируемые решения (например, https://www.robokassa.ru), которые переводят посетителя на сайт сервиса (там обычно EV). Сертификаты OV, например, используются Яндексом и Google.

Extended Validation (EV)

Красиво, дорого, мощно! EV-сертификаты отличаются внешним видом для посетителя. В адресной строке такого сертификата будут отображаться данные о компании.

Если вы делаете что-то глобальное, вам нужен такой сертификат: например, если вы банк, если вы платежная система, если у вас собственный сервис приема платежей (данные карты вводятся на вашем сайте) и так далее. Такие сертификаты дороги. Даже у Сбербанка этот сертификат стоит только для https://online.sberbank.ru/, а для https://www.sberbank.ru/ используется простой OV.

Что такое SSL, TLS

SSL (англ. secure sockets layer — уровень защищённых cокетов) — криптографический протокол, который обеспечивает безопасную связь между сервером и клиентом. Этим протоколом шифруется интернет-трафик, который невозможно прослушать. В 2014 году был скомпрометирован (была обнаружена уязвимость), из-за чего на основании протокола SSL 3.0 был создан стандарт TLS, учитывающий ошибки предшественника, а SSL фактически прекратил своё развитие.

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

Данный протокол широко используется в приложениях, работающих с сетью Интернет, таких как веб-браузеры, работа с электронной почтой, обмен мгновенными сообщениями и IP-телефония (VoIP).

Сегодня, когда говорят об SSL, то, как правило, подразумевают его потомка TLS. Поэтому, когда говорят, что нужно установить SSL сертификат на сайт, то, как правило, подразумевают установку TLS сертификата.

Атака на SSL/TLS – THC-SSL-DOS

Достаточно предсказуемая атака, в основе которой лежит идея, что крайне малыми силами со стороны клиента (по сути, просто запросив) можно заставить сервер выполнить математически относительно сложную задачу по перегенерации ключевой информации. В своей практике я сталкивался с таким в 2004 году, в случае с ipsec; один талантливый админ поставил настройки смены ключей так, что они менялись через каждые 100 килобайт (он хотел мегабайты, просто ошибся). В результате сеть работала, но медленно – ipsec в основном занимался IKE/ISAKMP задачами, а не трафиком.

Атака серьёзна – при полутысяче запросов в секунду (выполнимо с домашней машины при наличии обычного широкополосного доступа на 4-8 мегабита) полностью “ложится” процессор уровня Intel Xeon E5645. 100%го способа защиты от атаки сейчас нет. Поэтому надо максимально уменьшить её вероятность.

Для борьбы можно использовать следующие методы:

  1. Разгрузку SSL-задач при помощи аппаратных ускорителей
  2. Отключение пересогласования TLS
  3. Ограничение количества TLS-сессий – как вообще в сумме, так и с одного source ip
  4. Упрощение схемы генерации ключей

Защита от THC-SSL-DOS путём покупки SSL-ускорителя

Метод не оптимален, но всё же в ряде случаев изменит ситуацию. Суть в том, чтобы SSL/TLS сессии терминировались не на целевом сервере, а на выделенном устройстве, которое ощутимо быстрее выполняет SSL/TLS – задачи. Проблема в том, что все такие ускорители обычно ускоряют саму работу SSL/TLS – то есть симметричное шифрование трафика и проверку его целостности, а операции вида “генерация и смена ключей”, в силу их относительно малого процента в доле нагрузки при нормальной сессии делаются на таких appliance программно. Специализированного appliance, которое умеет очень быстро именно генерить новые сеансовы ключи для TLS, а не шифровать трафик, видимо, не существует в природе. Увы.

Защита от THC-SSL-DOS путём отключения пересогласования TLS

Это то, что Вы реально можете сделать. Учтите, это может повлиять на совместимость с клиентским ПО, которое в обязательном порядке хочет время от времени менять ключи сессии. Я проверял и не нашёл такого ПО среди обычно используемого в сетях на базе продуктов Microsoft (тестировались Exchange 2010 SP1, Sharepoint 2010 SP1, трафик DC/GC поверх SSL, TMG 2010 SP1). Мной не было найдено аномалий поведения, разрывов TLS-сессий по причине rekeying и прочего. Поэтому Вы можете промотать эту статью чуть выше (до предыдущего пункта) и выставить в единицу параметр .

Примечание: В принципе, можно использовать любое значение не равное нулю, поэтому единица предлагается для примера

Как усилить безопасность SSL, TLS

Бывает так, что сертификат установлен, а тестирование ssllabs показывает не лучший грейд безопасности. Чтобы добиться заветного , нужно правильно настроить NGINX. Для этого, сначала запускаем следующую команду, которая сгенерирует нужные ключи для Forward Secrecy (прямая секретность означает, что если третья сторона узнает какой-либо сеансовый ключ, то она сможет получить доступ только к тем к данным, что защищены этим ключом, не более):

openssl dhparam -out /etc/letsencrypt/dhparam.pem 2048

Затем, необходимо присутствие следующих записей в конфигурации сервера:

server {
  server_name sheensay.ru www.sheensay.ru;

  ssl_session_cache   shared:SSL:10m; # Разделяемый между всеми процесами кеш сессий на 10 байт с названием SSL. 1 Мб вмещает около 4000 сессий
  ssl_session_timeout 10m; # 10 минут - максимальное время жизни сессии

  add_header Strict-Transport-Security "max-age=31536000;"; # Заголовок, принудительно включающий защищённое соединение, минуя небезопасный HTTP

  # Заголовок Content Security Policy - отвечает за то, что считать безопасным подгружаемым контентом на странице
  add_header Content-Security-Policy-Report-Only "default-src https:; script-src https: 'unsafe-eval' 'unsafe-inline' *.yandex.ru; style-src https: 'unsafe-inline' fonts.googleapis.com; img-src https: data:; font-src https: data: fonts.googleapis.com; child-src https: www.youtube.com; report-uri /csp-report";

  ssl_stapling on;
  ssl_stapling_verify on;
  ssl_trusted_certificate /etc/letsencrypt/live/sheensay.ru/chain.pem; # домен меняете на свой
  resolver 8.8.4.4 8.8.8.8 valid=300s;
  resolver_timeout 10s;

  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!EXP:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
  ssl_prefer_server_ciphers on;

  ### Чтобы у нас заработал Forward Secrecy, сгенерируем ключ командой ниже:
  ## openssl dhparam -out /etc/letsencrypt/dhparam.pem 2048
  ### После генерации расскомментируем строку ниже
  ssl_dhparam /etc/letsencrypt/dhparam.pem;
  
  ### Дальше другие настройки сервера
  ### ...

После всех манипуляций, не забудьте перезагрузить NGINX

service nginx reload

Улучшения рукопожатия TLS 1.3 по сравнению с TLS 1.2

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

У рукопожатия TLS 1.2 можно выделить две фазы. Иногда могут потребоваться дополнительные, но когда речь идёт о количестве, по умолчанию подразумевается оптимальный сценарий.

В отличие от 1.2, рукопожатие TLS 1.3 укладывается в одну фазу, хотя вернее будет сказать в полторы, но это всё равно значительно быстрее, чем TLS 1.2.

Сокращение шифронаборов

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

Это плохо по двум причинам:

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

IETF исключил в TLS 1.3 поддержку всех алгоритмов, кроме самых безопасных, убирая путаницу за счёт ограничения выбора. В частности, был убран выбор метода обмена ключами. Эфемерная схема Диффи-Хеллмана стала единственным способом, позволяющим клиенту отправить информацию о своём ключе вместе с «Client Hello» в первой части рукопожатия. Шифрование RSA было полностью удалено вместе со всеми другими схемами обмена статическими ключами.

При этом есть одна потенциальная ахиллесова пята в TLS 1.3.

Нулевое время возобновления приёма-передачи — 0-RTT

0-RTT — это то, к чему стремился весь технологический мир, и вот оно здесь с TLS 1.3

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

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

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

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


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

В рукопожатии TLS 1.2 этапы согласования не были защищены, вместо этого использовалась простая MAC-функция, чтобы никто не вмешался в передачу. В этап согласования входят сообщения «Client Hello» и «Server Hello».

MAC-функция действует как индикатор, но не даёт никаких гарантий безопасности. Возможно, вы слышали об атаке, которая вынуждает стороны использовать менее безопасные протоколы и функции (downgrade attack). Если и сервер, и клиент поддерживают устаревшие шифронаборы — информацию об этом легко получить, прослушивая соединение, — злоумышленник может изменить шифрование, выбранное сервером, на более слабое. Такие атаки не опасны сами по себе, но открывают дверь для использования других известных эксплойтов тех шифронаборов, на которые был изменён выбранный изначально.

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

Теперь посмотрим, как эти обновления для рукопожатия TLS 1.3 будут реализованы во всех трёх основных функциях самого рукопожатия SSL/TLS.

Проверяем работу TLS 1.1 и 1.2

Если Вы выяснили, что после отключения поддержки TLS 1.0 вы никуда не можете зайти, и подозреваете, что браузер сломался, есть отличный тестовый сайт:

Это специальный сайт, который зарегистрирован на одну из вымышленных и использующихся в курсах Microsoft организаций – Woodgrove Bank, а по сути – голый IIS с самоподписанным сертификатом, который поддерживает все виды SSL/TLS и нужен для диагностики. Зайдите на него, установите сертификат (их, кстати, несколько – специально для проверки поддержки различных криптоалгоритмов подписи) и проверите, что и как работает.

Есть второй вариант – https://www.mikestoolbox.net/. Тут возможностей поменьше, но зато быстрее и нагляднее видно – какой протокол поддерживается, что согласовалось.

Как установить SSL/TLS, если на сервере несколько сайтов

Обычно, проблемы возникают, когда на сервере уже есть 1 сайт на HTTPS, и на этот сервер нужно перенести другой сайт. Либо, ещё более патовая ситуация: нужно перенести сайт на HTTP и сделать его доступным по HTTPS. Проблема будет возникать из-за того, что на сервере на порту уже есть сайт с сертификатом SSL/TLS, и обращения будут идти на него, и certbot не сможет прописать сертификат сайту, а сайты по HTTP будут недоступны. Для решения этой проблемы можно сгенерировать временный самоподписанный сертификат:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

Эта команда создаст 2 файла в директории, из которой вызывается команда (обычно это ):

  • cert.pem — это сертификат SSL/TLS;
  • key.pem — это ключ к сертификату.

Ключи прописываете в конфигурации сервера (пример есть ниже). Далее:

  • Если сайт нужен по HTTP, просто делаете редирект с HTTPS на HTTP, по аналогии с редиректом на HTTPS, только наоборот (пример далее);
  • Если сайт нужен по HTTPS, делаете сайт доступным по HTTP, затем получаете сертификат с помощью certbot, а дальше всё как по инструкции выше — редирект на HTTPS, прописывание сертификатов, настройка URL, и так далее.

Пример, как сделать редирект с HTTPS на HTTP в NGINX

Допустим, самоподписанные сертификаты сгенерированы командой выше и располагаются в каталоге . Тогда, чтобы настроить редирект с HTTPS на HTTP для нового сайта , мы можем использовать следующую конфигурацию ( заменяем на свой домен, — на свой IP сервера):

server {
 server_name example.com   www.example.com;
 listen 1.2.3.4:443 ssl; ### Вместо 1.2.3.4 нужно подставить IP сервера

 ssl_certificate /root/cert.pem; # Путь к самоподписанному сгенерированному сертификату
 ssl_certificate_key /root/key.pem; # Путь к ключу самоподписанного сертификата

 rewrite ^(.*) http://$host$1 permanent; 
}

server {
    server_name example.com   www.example.com;
    listen 1.2.3.4:80 ; ### Вместо 1.2.3.4 нужно подставить IP сервера

    ### Остальные правила ###
}

Что изменилось в TLS 1.3 по сравнению с TLS 1.2?

Важно помнить, что при создании версии 1.3 главным было повышение безопасности и производительности. Для этого в TLS 1.3 был переработан алгоритм генерация ключей и исправлены известные уязвимости

В рукопожатии TLS 1.3 также стали лучше некоторые процессы, например аутентификация сообщений и цифровые подписи.

Наконец, в дополнение к постепенному отказу от старых алгоритмов генерации ключей или обмена ими, TLS 1.3 устраняет старые симметричные шифры. В TLS 1.3 полностью исключили блочные шифры. Единственный разрешённый в TLS 1.3 тип симметричных шифров называется шифрованием с проверкой подлинности с использованием дополнительных данных (AEAD). Он объединяет шифрование и проверку подлинности сообщений (MAC) в одну функцию.

Как происходит подтверждение сайта с помощью сертификатов

При соединении браузер проверяет, соответствуют ли данные в сертификате тому узлу, куда отправляются данные.


Если сайт соответствует информации, указанной в сертификате, то вы видите в окне браузера вот такой замочек для простого сертификата:

И замочек и информацию о компании для сертификата, где она указана:

Если же что-то пошло не так, то вы увидите такое предупреждение:

​​

При проверке:

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

Когда и почему SSL/TLS необходимы?

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

Цель SSL/TLS состоит в том, чтобы убедиться, что только один человек — лицо или организация, утверждённое пользователем, может получить доступ к передаваемым данным

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

Существует три основных варианта использования SSL/TLS для вашего веб-сайта:

  • Когда вам нужна аутентификация: любой сервер может претендовать на роль вашего сервера, захватив информацию, которую люди передают. SSL/TLS позволяет вам подтвердить личность вашего сервера, чтобы люди знали, что вы являетесь тем, кем вы говорите.
  • Чтобы внушить доверие: если вы используете сайт электронной коммерции или спрашиваете пользователей о том, какие данные важны для них, вы должны поддерживать чувство доверия. Использование сертификата SSL/TLS является видимым способом показать посетителям, что они могут вам доверять, и это намного эффективнее всего, что вы могли бы сказать о себе.
  • Когда вам нужно соблюдать отраслевые стандарты: в некоторых отраслях, таких как финансовая, вам необходимо будет поддерживать определённые базовые уровни безопасности. Существуют также правила в области платёжных карт (PCI), которых необходимо придерживаться, если вы хотите принять информацию о кредитной карте на своём веб-сайте. И одним из этих требований является использование сертификата SSL/TLS.

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

Закручиваем гайки: настройки криптоалгоритмов на хосте

Цель – отключить слабые алгоритмы шифрования. Чтобы они просто не участвовали в процессе согласования. Потому что на данный момент, допустим, наличие в списке поддерживаемых алгоритмов RC2 40bit – это очень плохо, и это необходимо убирать незамедлительно.

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

Как через групповую политику изменить список поддерживаемых SSL/TLS криптоалгоритмов

Откройте объект групповой политики, через который Вы решите это сделать. Если настраиваете локальный хост – . Выберите там раздел для компьютера, потом административные шаблоны, потом сеть, потом SSL Configuration Settings. Откройте данный параметр и сделайте следующее.

  1. Скопируйте в Блокнот все cipher suites, которые там есть.
  2. Удалите те, которые включают в себя согласование нестойких алгоритмов и методов (например, RC2, RC4, DES, MD5 и прочее. всякие ужасы вида TLS_RSA_WITH_NULL_MD5 Вам же не нужны, правда?).
  3. Превратите список в одну большую строку, которая состоит из cipher suites, разделённых запятыми, и не содержит больше ничего. Пробелов тоже.
  4. Вставьте эту строку в окно данной настройки групповой политики.

Учтите, что не всё, что поддерживается системой, присутствует в этом списке. И наоборот – данный список не прикажет системе начать поддерживать неизвестные ей криптоалгоритмы. Например, если у Вас есть системы на Windows XP / Windows Server 2003, убедитесь, что на них установлено обновление KB 948963, которое добавляет поддержку AES-128 и AES-256, необходимых для TLS.

А вот как можно изменить этот список через реестр.

Как через реестр изменить список поддерживаемых SSL/TLS криптоалгоритмов

Откройте редактор реестра. Ваша задача – ключи вида:

где идентификатор алгоритма – это, например, RC4, а размерность ключа – например, 128. Понятное дело, что данных комбинаций фиксированное число, поэтому для отключения всех из них в явном виде надо забежать в MSDN и найти эти комбинации. Например, для старых симметричных алгоритмов семейства RCx это будут:

  • RC4 128/128
  • RC2 128/128
  • RC4 64/128
  • RC4 56/128
  • RC2 56/128
  • RC4 40/128
  • RC2 40/128

Во всех этих ключах надо будет создать параметр (как обычно, DWORD32) и выставить его в нуль.

Интересным моментом является отключение возможности установить “пустой” SSL – без криптоалгоритма. Ну, типа как в PPP можно вообще без фазы авторизации, так и тут – есть такая тонкость. Чтобы эту тонкость тоже убрать, надо зайти в ключ:

и опять же создать там со значением 0x0.

Отключаем использование хэш-функции MD5 в SSL/TLS

И даже это можно. Через групповую политику нет (только вручную удалив из полного списка все suites с упоминанием MD5), а через реестр – пожалуйста.

Учтите только, что данная настройка – лидер по количеству приключений после её применения. Классика – умирающий SharePoint 2010; он использует MD5 для генерации внутренних идентификаторов безопасности, поэтому не найдя её очень страдает.

Заходим:

и отключаем аналогично – в 0x0. Заодно и MD4 можно, он в принципе может встретиться в IPSec, но если не используется в реальности – имеет смысл его отключить аналогичным способом.

Примечание: Если захотите что-нибудь из этого явно включить обратно, не стирая ключ, есть нюанс: Enabled надо будет ставить не в единицу, а в 0xFFFFFFFF.

Оглавление

  • Краткая история вопроса – SSL
  • Версии и преимущества TLS
    • Про TLS 1.0
    • Про TLS 1.1
    • Про TLS 1.2
    • Про TLS 1.2 и Windows XP SP3
    • Про TLS 1.2 и Windows 2003 SP2
  • BEAST: как работает атака на SSL 2.0/3.0 и TLS 1.0
  • Включаем TLS на Windows-системе
  • Отключаем SSL на Windows-системе
  • Закручиваем гайки: Включаем безопасное пересогласование TLS на Windows-системе
  • Атака на SSL/TLS – THC-SSL-DOS
  • Закручиваем гайки: настройки криптоалгоритмов на хосте
  • Управляем настройками согласования SSL/TLS в браузерах
  • Проверяем работу TLS 1.1 и 1.2
  • Что делать, если у меня нет возможности включить TLS новых версий

Приступим.

BEAST: как работает атака на SSL 2.0/3.0 и TLS 1.0

Эта достаточно нашумевшая атака (ну, благодаря прессе, у неё статус “Конец Интернета Почти Вот-Вот”), на самом деле, устроена достаточно просто. Суть в том, что во всех протоколах до TLS 1.1 вместо генерации нового случайного IV (для каждого нового TLS message), использовался последний блок предыдущего TLS message. BEAST пользуется этим, чтобы значительно упростить процесс атаки на ключ – в частности, получив доступ к сессии, он может значительно упростить себе процедуру перебора сессионного ключа, влияя на состав нового вектора инициализации. В TLS 1.1 халтурить перестали, поэтому данная атака там просто не работает.

Если попробовать рамочно описать алгоритм атаки, можно это сделать так.

  • Пользователь инициирует SSL-сессию к ресурсу (например, к веб-серверу). В этой сессии он постоянно передаёт какой-то элемент (например, жмёт на кнопку Like). Ну т.е. сессия одна, а он ходит по сайтам и делает что-то, что сопровождается хотя бы частично совпадающим обменом данными.
  • Например, предположим, что согласовался протокол AES-128 (заметьте – стойкость самого протокола не критична, я его выбрал просто для удобного примера). Его блок будет равняться 128 / 8 = 16 байт.
  • Атакующий участвует в обмене трафиком так, что может добавлять свои данные перед данными пользователя. Вариантов много – например, доп.заголовок в HTTP, или модификация исходных данных на уровне источника. Суть в том, чтобы атакующий мог добавить свои данные так, чтобы получился блок “Добавленные_данные_известные_атакующему + нормальные_данные_неизвестные_атакующему”. Т.е. исходное в атаке – это MITM. Если вы думаете, что условий дофига и это всё малореально, просто представьте себе обычного пользователя, который игнорирует антивирус, потому как, к примеру, верит рекламе “В нашей ОС нет вирусов, т.к. у неё красивые скруглённые уголочки да и цена намекает, что качество ну просто обязано быть”, который хочет в онлайне что-нибудь оплатить по карте и видит успокаивающую надпись “Protected by SSL 2.0/3.0 128bit cipher”.
  • Атакующий начинает работать. Он вкидывает такие блоки данных в поток, чтобы последним получился блок, у которого 15 байт – добавленные данные, а единственный оставшийся – секретные. После пробует тестово расшифровывать этот блок перебором – перебирать-то интересно, т.к. из 16 байт 15 известны. А подбор 2^8 – это уже очень перспективно, учитывая, что в случае выигрыша можно будет вскрыть всю сессию (ведь никто не мешает впрок отправлять куда-нибудь полный дамп сессии, а после, в случае успеха метода, расшифровать всё целиком).
  • Вскрыли 1 байт? Теперь будем подгадывать так, чтобы наших байт в блоке было 14, плюс один известный, плюс один пока что неизвестный

С этим читают