Я сломал локоть. Хирург 1 после анализов сказал, что всё ок - зарастёт. Посоветовался с ИИ - гипотеза выдвинута, что хирург может не видеть осколков. Пошёл к Хирургу 2 - тот настоял на операции и вынул 6 осколков кости. Осколки могли перерезать нерв и прощай рука. Я теперь любого врача челленджу вместе с ИИ ради себя любимого.
Вы не читали внизу в Вики по какой лицензии распространяются эти самые "скомунизженные статьи"? CC BY-SA 4.0 . В Рувики где-то указывали авторство идентичных Википедии статей? Кстати, там ещё и Share-Alike принцип. Если требования лицензии нарушаются, то статьи именно что скомунизженные.
Кто сейчас не пишет с помощью нейросетей - меня это не коробит, я вон целые статьи на Википедии пишу с правильными цитированиями и проверкой фактов. Меня коробит, что я не могу найти подтверждения в приведённых источниках:
1. Перепроверил ещё раз (Berns et al., 2015) - пусто. 2. Не нашёл ничего в (Bradshaw, 2013) - только про школы там пишут. 3. Задолбался и дал ИИ с низкой температурой на откуп проверить (Amedi et al. 2017) - выдумка. 4. Хотя бы (Niven & Laughlin, 2008) и (Siegel, 2005) подтвердились, но они мало что внесли нового.
Короче, я ложноцитаты не люблю и ставлю минусы и статье, и автору.
О, наконец они решили обновить сами эти сертификаты. Напоминаю, что обновление этих сертификатов закрывает уязвимость, которую эксплуатирует до сих пор Black Lotus буткит . Если кратко, то закрытые ключи сертификата PCA 2011 утекли создателям Black Lotus несколько лет назад.
Знакомо. Я всё же рекомендую вам сделать публичную оферту и высылать её заказчикам, где всё прописано. В том числе всякие ЧП, смена фокуса работы и прочее. Я свою сделал с помощью ИИ, теперь осталось дать юристу на проверку, но всё равно заказчикам её показываю. Заказ услуг - это заключение договора. А корреспонденция между мной и заказчиком - приложение к договору. Т.е. если в сообщении в ТГ мы договорились о скоупе работ, то это является приложением к договору. Так же в оферте прописано как я буду исправлять свои ошибки, и как будет исправлять ошибки свои клиент.
Имел ввиду, что эти протоколы ТСПУ режут, если IP нет в белых списках, которые подали какие-нибудь компании. Т.е. простые человек с таким роутером всё равно не сможет использовать такие преднастроенные VPN'ы.
По личному опыту, линь для домохозяек - самое то. Установил на старый нетбук убунту, всё заработало и залетало, а им нужно было только ютубчик и фильмы смотреть. Ну и иногда подключать флешки и базово работать с документами, но для этого есть LibreOffice. Поставил dnsproxy и направил на халявный семейный инстанс control-d - это чтобы на всякие опасные сайты не ходили.
Поздравляю с первой статьёй. Как фидбек - попробуйте объяснения работы алгоритмов делать более понятными для не криптографов и киберсек. спецов.
Например, чтобы понять механизм работы, мне пришлось RFC скормить Gemini и попросить пошагово объяснить. Вот что вышло для SCRAM-SHA-256-PLUS (луддитам не читать спойлер - там богомерзкое объяснение от ЛЛМ):
Скрытый текст
Исходные данные: Состояние перед аутентификацией
Клиент: Знает username (имя пользователя) и password (пароль). Больше у него ничего нет.
Сервер:НЕ знает пароль пользователя. В его базе данных для каждого username хранится запись с четырьмя ключевыми, заранее вычисленными элементами:
Salt (Соль): Уникальная случайная строка, сгенерированная при создании учётной записи.
IterationCount (Число итераций): Число (например, 4096, но для защиты от офлайн-атак рекомендуется 600 000+). Это "фактор сложности".
ServerKey: Ключ, который сервер будет использовать для создания собственных подписей.
Ключи StoredKey и ServerKey вычисляются из SaltedPassword (пароль + соль) только один раз — при регистрации пользователя или смене пароля. Сервер хранит эти готовые ключи, чтобы избежать дорогостоящих вычислений при каждом входе в систему.
Криптографические функции, которые мы будем использовать:
H(): Хеш-функция SHA-256.
HMAC(key, data): Функция HMAC-SHA-256.
Hi(): Функция PBKDF2-HMAC-SHA-256, которая представляет собой HMAC, повторённый IterationCount раз. Это "медленная" часть.
XOR: Операция "побитовое исключающее ИЛИ".
Полный "танец" аутентификации: Шаг за шагом
Вот весь процесс, сообщение за сообщением.
Шаг 1: Первое сообщение клиента (Начало диалога)
Клиент инициирует диалог, не раскрывая никакой конфиденциальной информации.
Клиент -> Сервер:n,,n=user,r=rOprNGfwEbeRWgbNEkqO
Что происходит "под капотом":
Генерация Nonce клиента (c-nonce): Клиент создаёт криптографически случайную строку (r=...), уникальную для каждой попытки аутентификации.
Форматирование сообщения:
n=user: Имя пользователя.
n,,: Заголовок gs2-header. В примере из RFC n означает, что клиент не поддерживает привязку к каналу, но для -PLUS обмена здесь было бы y,,. Первая запятая означает, что клиент поддерживает привязку к каналу, вторая — что данные привязки будут отправлены позже.
r=...: Уникальное nonce-значение клиента.
Чего достигает этот шаг: Сигнализирует о начале аутентификации, идентифицирует пользователя и предоставляет уникальное значение для предотвращения атак повторного воспроизведения со стороны сервера.
Шаг 2: Первое сообщение сервера (Вызов)
Сервер отвечает, предоставляя публичные параметры, необходимые клиенту.
Поиск пользователя: Сервер находит запись для user. Если пользователь не найден, сервер может сгенерировать поддельные данные, чтобы не раскрывать факт существования или отсутствия пользователя.
Генерация и объединение Nonce: Сервер генерирует собственное nonce-значение (s-nonce) и добавляет его в конец nonce-значения клиента. Полученный r=... теперь содержит случайность от обеих сторон.
Извлечение публичных данных: Сервер извлекает из своей базы данных Salt (s=...) и IterationCount (i=...) для данного пользователя.
Сборка и отправка: Сервер отправляет объединённое nonce-значение, соль и число итераций.
Чего достигает этот шаг: Бросает клиенту вызов (challenge) доказать знание пароля, используя предоставленные параметры, и гарантирует уникальность сессии.
Шаг 3: Финальное сообщение клиента (Тяжёлая работа и доказательство)
Это самый сложный шаг, на котором клиент выполняет всю основную криптографическую работу.
Это тот самый шаг, который делает офлайн-атаки на украденную базу данных очень медленными и дорогими.
Вывод специализированных ключей (Криптографическая гигиена): Клиент использует SaltedPassword как мастер-ключ для создания двух разных ключей для разных целей. Для этого используются публичные, стандартные строки-константы, определённые в спецификации SCRAM.
ClientKey = HMAC(SaltedPassword, "Client Key")
ServerKey = HMAC(SaltedPassword, "Server Key")
Теперь у клиента есть два ключа: ClientKey для создания своего доказательства и ServerKey для последующей проверки сервера.
Получение данных привязки к каналу (часть -PLUS): Клиент запрашивает у своего TLS-уровня уникальный "отпечаток" соединения (channel-binding-data) и форматирует его в часть сообщения c=biws.
Формирование Auth-Message: Клиент создаёт единую строку, представляющую всю историю диалога:
Эта строка уникальна благодаря nonce и привязана к TLS-каналу благодаря данным привязки.
Создание ClientProof (Доказательство клиента):
StoredKey = H(ClientKey)(Клиент вычисляет это значение "на лету"; ему не нужно его хранить)
ClientSignature = HMAC(StoredKey, Auth-Message)
ClientProof = ClientKey XOR ClientSignature
Сборка и отправка: Клиент кодирует ClientProof в base64 и отправляет его как p=....
Чего достигает этот шаг: Клиент доказывает, что он вычислил правильный ClientKey (и, следовательно, знает пароль), не отправляя его. Доказательство криптографически привязано к данной сессии (через nonce) и к данному TLS-соединению (через привязку к каналу).
Шаг 4: Финальное сообщение сервера (Проверка и взаимное доказательство)
Сервер проверяет доказательство клиента и, если оно верно, доказывает собственную подлинность.
Разбор и проверка: Сервер проверяет nonce и получает данные привязки к каналу со своей стороны TLS-соединения. Это момент истины для -PLUS: если есть "человек посередине", отпечатки каналов не совпадут.
Воссоздание Auth-Message: Он реконструирует в точности ту же строку Auth-Message, что и клиент.
Восстановление ClientKey и проверка доказательства:
Сервер извлекает из базы данныхStoredKey для этого пользователя.
Он вычисляет, какой должна быть подпись клиента: ClientSignature = HMAC(StoredKey, Auth-Message).
Он восстанавливает ключ клиента из доказательства: ClientKey_from_client = ClientProof XOR ClientSignature.
Он проверяет ключ: H(ClientKey_from_client) ДОЛЖЕН быть равен сохранённому StoredKey. Если совпадает, клиент аутентифицирован.
Создание ServerSignature ("эффективная" часть):
Сервер извлекает из своей базы данных заранее вычисленный ServerKey для этого пользователя. (Никаких дорогостоящих вычислений здесь не требуется).
Он подписывает диалог: ServerSignature = HMAC(ServerKey, Auth-Message).
Сборка и отправка: Сервер кодирует ServerSignature в base64 и отправляет как верификатор v=....
Чего достигает этот шаг: Эффективно проверяет подлинность клиента и предоставляет доказательство собственной подлинности, завершая взаимную аутентификацию.
Шаг 5: Финальная проверка клиента
Клиент должен проверить сервер, чтобы защититься от самозванцев.
Что происходит "под капотом":
Вычисление ожидаемой ServerSignature: Клиент использует ServerKey, вычисленный на Шаге 3, чтобы рассчитать, какой должна быть подпись сервера: ExpectedServerSignature = HMAC(ServerKey, Auth-Message).
Сравнение: Он сравнивает свою вычисленную подпись со значением v=..., полученным от сервера.
Успех или провал: Если они совпадают, сервер подлинный. Если нет, клиент ОБЯЗАН немедленно разорвать соединение.
Чего достигает этот шаг: Защищает клиента от атаки "человек посередине" (Man-in-the-Middle), выполняя обещание взаимной аутентификации.
А тут объяснение (тоже от ЛЛМ) как защищает от MiTM -PLUS:
Скрытый текст
Сценарий атаки MITM (без -PLUS)
Представим классическую атаку MITM:
Клиент -> Злоумышленник: Клиент думает, что подключается к Серверу, но на самом деле устанавливает идеальное, зашифрованное TLS-соединение со Злоумышленником. Назовём это Канал А.
Злоумышленник -> Сервер: Злоумышленник, притворяясь Клиентом, устанавливает второе, такое же идеальное TLS-соединение с настоящим Сервером. Назовём это Канал Б.
Теперь Злоумышленник сидит "посередине" и просто пересылает сообщения SCRAM туда-сюда:
Клиент отправляет client-first-message по Каналу А.
Злоумышленник расшифровывает, видит его и пересылает по Каналу Б на Сервер.
Сервер отвечает server-first-message по Каналу Б.
Злоумышленник пересылает его по Каналу А Клиенту.
Клиент вычисляет ClientProof и отправляет его.
Злоумышленник пересылает его на Сервер.
Результат: Сервер успешно проверяет ClientProof. Он считает, что у него установлено защищённое соединение с Клиентом. Но на самом деле он общается со Злоумышленником. Атака удалась.
Как -PLUS (Привязка к каналу) ломает эту атаку
Вот где собака зарыта. Привязка к каналу заставляет аутентификацию SCRAM "знать" о том TLS-канале, внутри которого она происходит.
Давайте пройдём по тому же сценарию, но теперь с SCRAM-SHA-256-PLUS.
У нас та же ситуация: Клиент <-> Канал А <-> Злоумышленник <-> Канал Б <-> Сервер.
Шаг 3 (Клиент): Когда Клиент готовится создать своё доказательство (ClientProof), он делает дополнительное действие:
Он обращается к своему TLS-уровню и просит: "Дай мне уникальный криптографический отпечаток именно этого TLS-соединения". Этот отпечаток (channel-binding-data) вычисляется на основе секретов, которыми обменялись стороны во время TLS-рукопожатия.
Для Клиента это будет отпечаток Канала А.
Клиент включает этот отпечаток Канала А в строку Auth-Message, которую он подписывает.
Теперь ClientProof криптографически зависит не только от пароля и nonce, но и от уникальной идентичности Канала А. Клиент отправляет это доказательство.
Злоумышленник, как и раньше, перехватывает это сообщение и пересылает его по Каналу Б на Сервер.
Шаг 4 (Сервер): Момент истины.
Сервер получает ClientProof. Чтобы его проверить, он должен сам вычислить, каким это доказательство должно быть.
Он, так же как и клиент, обращается к своему TLS-уровню и просит: "Дай мне уникальный отпечаток этого TLS-соединения".
Но для Сервера это соединение — Канал Б!
Поскольку TLS-рукопожатия для Канала А (Клиент <-> Злоумышленник) и Канала Б (Злоумышленник <-> Сервер) были двумя совершенно разными, независимыми событиями, их криптографические отпечатки гарантированно будут разными.
Сервер вычисляет ожидаемое доказательство, используя отпечаток Канала Б.
Провал проверки:
Доказательство, полученное от Клиента, было подписано с использованием отпечатка Канала А.
Доказательство, которое ожидает увидеть Сервер, должно быть подписано с использованием отпечатка Канала Б.
Эти два значения не совпадают. Проверка проваливается. Сервер отклоняет попытку входа.
Результат: Атака полностью провалилась.
Аналогия
Представьте, что вы и ваш друг договорились о секретном рукопожатии (это SCRAM).
Без -PLUS: Вы делаете рукопожатие с мошенником. Мошенник в точности повторяет его с вашим другом. Друг отвечает, мошенник повторяет ответ вам. Всё выглядит нормально.
С -PLUS: Ваше новое рукопожатие включает дополнительный шаг: вы должны вместе указать на уникальную трещину на полу в той комнате, где вы находитесь (это отпечаток канала).
Вы находитесь в Комнате А с мошенником и указываете на трещину в ней.
Мошенник пытается передать это вашему другу, который находится в Комнате Б.
Ваш друг смотрит на пол в своей комнате и видит другую трещину (или её отсутствие). Он мгновенно понимает, что вы не в одной комнате, и что-то не так.
Итог: Механизм -PLUS не просто защищает данные внутри канала. Он криптографически "приваривает" саму аутентификацию к конечным точкам этого конкретного канала, делая невозможной атаку с "прозрачной" ретрансляцией. Он защищает именно от MITM-атаки, запущенной с самого начала.
Кстати, я не совсем понимаю, но почему производители используют проприетарные кодеки (за каждый девайс с ними надо чеканную монету отстёгивать) в TWS, которые ещё и непонятно насколько хорошо при низких битрейтах передают качество звучания, вместо того, что использовать открытый Opus, который уже при 128 кб/c для многих прозрачен? Он отлично подходит для Bluetooth благодаря своим фишкам по восстановлению потерянных пакетов типа Deep REDundancy (DRED) на базе ML.
Вполне едят, просто реально могут не успевать
Как и в прошлый раз - если заезжать в зону, то макс. скорость самокат сам ограничивает.
SELinux более мощная и жёсткая штука, но и более запарная по настройке. Лично я использую systemd-sandboxing с AppArmor.
Я сломал локоть. Хирург 1 после анализов сказал, что всё ок - зарастёт. Посоветовался с ИИ - гипотеза выдвинута, что хирург может не видеть осколков. Пошёл к Хирургу 2 - тот настоял на операции и вынул 6 осколков кости. Осколки могли перерезать нерв и прощай рука.
Я теперь любого врача челленджу вместе с ИИ ради себя любимого.
О, отлично что показали, спасибо! Тогда снимаю свои претенции к рувики - я туда не заходил даже.
Согласен. Жму вам руку, что изначально заметили проблемы с источниками!
Вы не читали внизу в Вики по какой лицензии распространяются эти самые "скомунизженные статьи"? CC BY-SA 4.0 . В Рувики где-то указывали авторство идентичных Википедии статей? Кстати, там ещё и Share-Alike принцип. Если требования лицензии нарушаются, то статьи именно что скомунизженные.
Кто сейчас не пишет с помощью нейросетей - меня это не коробит, я вон целые статьи на Википедии пишу с правильными цитированиями и проверкой фактов. Меня коробит, что я не могу найти подтверждения в приведённых источниках:
1. Перепроверил ещё раз (Berns et al., 2015) - пусто.
2. Не нашёл ничего в (Bradshaw, 2013) - только про школы там пишут.
3. Задолбался и дал ИИ с низкой температурой на откуп проверить (Amedi et al. 2017) - выдумка.
4. Хотя бы (Niven & Laughlin, 2008) и (Siegel, 2005) подтвердились, но они мало что внесли нового.
Короче, я ложноцитаты не люблю и ставлю минусы и статье, и автору.
Имхо, 90% скоммуниздили, 10% изменили по полит. причинам
О, наконец они решили обновить сами эти сертификаты. Напоминаю, что обновление этих сертификатов закрывает уязвимость, которую эксплуатирует до сих пор Black Lotus буткит . Если кратко, то закрытые ключи сертификата PCA 2011 утекли создателям Black Lotus несколько лет назад.
Знакомо. Я всё же рекомендую вам сделать публичную оферту и высылать её заказчикам, где всё прописано. В том числе всякие ЧП, смена фокуса работы и прочее. Я свою сделал с помощью ИИ, теперь осталось дать юристу на проверку, но всё равно заказчикам её показываю. Заказ услуг - это заключение договора. А корреспонденция между мной и заказчиком - приложение к договору. Т.е. если в сообщении в ТГ мы договорились о скоупе работ, то это является приложением к договору. Так же в оферте прописано как я буду исправлять свои ошибки, и как будет исправлять ошибки свои клиент.
Имел ввиду, что эти протоколы ТСПУ режут, если IP нет в белых списках, которые подали какие-нибудь компании. Т.е. простые человек с таким роутером всё равно не сможет использовать такие преднастроенные VPN'ы.
Вот у меня такое же лицо было! Поэтому вам плюс, а статье минус поставил.
Отличное исследование! Честно говоря, очень позабавили сети из роутеров с открытыми админками :D
Кстати, вроде же WG и OpenVPN давно режутся - получается, что и тут людей налюбили.
Не совсем. Я просто поставил dns и забыл :)
По личному опыту, линь для домохозяек - самое то. Установил на старый нетбук убунту, всё заработало и залетало, а им нужно было только ютубчик и фильмы смотреть. Ну и иногда подключать флешки и базово работать с документами, но для этого есть LibreOffice. Поставил dnsproxy и направил на халявный семейный инстанс control-d - это чтобы на всякие опасные сайты не ходили.
Мда, ещё один сговор :( Спасибо за коммент!
Поздравляю с первой статьёй. Как фидбек - попробуйте объяснения работы алгоритмов делать более понятными для не криптографов и киберсек. спецов.
Например, чтобы понять механизм работы, мне пришлось RFC скормить Gemini и попросить пошагово объяснить. Вот что вышло для SCRAM-SHA-256-PLUS (луддитам не читать спойлер - там богомерзкое объяснение от ЛЛМ):
Скрытый текст
Исходные данные: Состояние перед аутентификацией
Клиент: Знает
username(имя пользователя) иpassword(пароль). Больше у него ничего нет.Сервер: НЕ знает пароль пользователя. В его базе данных для каждого
usernameхранится запись с четырьмя ключевыми, заранее вычисленными элементами:Salt(Соль): Уникальная случайная строка, сгенерированная при создании учётной записи.IterationCount(Число итераций): Число (например, 4096, но для защиты от офлайн-атак рекомендуется 600 000+). Это "фактор сложности".StoredKey: Хеш ключа клиента. Конкретно,StoredKey = H(ClientKey).ServerKey: Ключ, который сервер будет использовать для создания собственных подписей.Ключи
StoredKeyиServerKeyвычисляются изSaltedPassword(пароль + соль) только один раз — при регистрации пользователя или смене пароля. Сервер хранит эти готовые ключи, чтобы избежать дорогостоящих вычислений при каждом входе в систему.Криптографические функции, которые мы будем использовать:
H(): Хеш-функция SHA-256.HMAC(key, data): Функция HMAC-SHA-256.Hi(): Функция PBKDF2-HMAC-SHA-256, которая представляет собой HMAC, повторённыйIterationCountраз. Это "медленная" часть.XOR: Операция "побитовое исключающее ИЛИ".Полный "танец" аутентификации: Шаг за шагом
Вот весь процесс, сообщение за сообщением.
Шаг 1: Первое сообщение клиента (Начало диалога)
Клиент инициирует диалог, не раскрывая никакой конфиденциальной информации.
Клиент -> Сервер:
n,,n=user,r=rOprNGfwEbeRWgbNEkqOЧто происходит "под капотом":
Генерация Nonce клиента (
c-nonce): Клиент создаёт криптографически случайную строку (r=...), уникальную для каждой попытки аутентификации.Форматирование сообщения:
n=user: Имя пользователя.n,,: Заголовокgs2-header. В примере из RFCnозначает, что клиент не поддерживает привязку к каналу, но для-PLUSобмена здесь было быy,,. Первая запятая означает, что клиент поддерживает привязку к каналу, вторая — что данные привязки будут отправлены позже.r=...: Уникальное nonce-значение клиента.Чего достигает этот шаг: Сигнализирует о начале аутентификации, идентифицирует пользователя и предоставляет уникальное значение для предотвращения атак повторного воспроизведения со стороны сервера.
Шаг 2: Первое сообщение сервера (Вызов)
Сервер отвечает, предоставляя публичные параметры, необходимые клиенту.
Сервер -> Клиент:
r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF$k0,s=W22ZaJ0SNY7soEsUEjb6gQ==,i=4096Что происходит "под капотом":
Поиск пользователя: Сервер находит запись для
user. Если пользователь не найден, сервер может сгенерировать поддельные данные, чтобы не раскрывать факт существования или отсутствия пользователя.Генерация и объединение Nonce: Сервер генерирует собственное nonce-значение (
s-nonce) и добавляет его в конец nonce-значения клиента. Полученныйr=...теперь содержит случайность от обеих сторон.Извлечение публичных данных: Сервер извлекает из своей базы данных
Salt(s=...) иIterationCount(i=...) для данного пользователя.Сборка и отправка: Сервер отправляет объединённое nonce-значение, соль и число итераций.
Чего достигает этот шаг: Бросает клиенту вызов (challenge) доказать знание пароля, используя предоставленные параметры, и гарантирует уникальность сессии.
Шаг 3: Финальное сообщение клиента (Тяжёлая работа и доказательство)
Это самый сложный шаг, на котором клиент выполняет всю основную криптографическую работу.
Клиент -> Сервер:
c=biws,r=rOprNGfwEbeRWgbNEkqO%hvYDpWUa2RaTCAfuxFIlj)hNlF$k0,p=dHzbZapWIk4jUhN+Ute9ytag9zjfMHgsqmmiz7AndVQ=Что происходит "под капотом" (по порядку):
Вычисление
SaltedPassword("медленная" часть): Клиент выполняет ресурсоёмкую функцию PBKDF2:SaltedPassword = Hi(password, salt, iterationCount)Это тот самый шаг, который делает офлайн-атаки на украденную базу данных очень медленными и дорогими.
Вывод специализированных ключей (Криптографическая гигиена): Клиент использует
SaltedPasswordкак мастер-ключ для создания двух разных ключей для разных целей. Для этого используются публичные, стандартные строки-константы, определённые в спецификации SCRAM.ClientKey = HMAC(SaltedPassword, "Client Key")ServerKey = HMAC(SaltedPassword, "Server Key")Теперь у клиента есть два ключа:
ClientKeyдля создания своего доказательства иServerKeyдля последующей проверки сервера.Получение данных привязки к каналу (часть
-PLUS): Клиент запрашивает у своего TLS-уровня уникальный "отпечаток" соединения (channel-binding-data) и форматирует его в часть сообщенияc=biws.Формирование
Auth-Message: Клиент создаёт единую строку, представляющую всю историю диалога:Auth-Message = client-first-message-bare + "," + server-first-message + "," + client-final-message-without-proofЭта строка уникальна благодаря nonce и привязана к TLS-каналу благодаря данным привязки.
Создание
ClientProof(Доказательство клиента):StoredKey = H(ClientKey)(Клиент вычисляет это значение "на лету"; ему не нужно его хранить)ClientSignature = HMAC(StoredKey, Auth-Message)ClientProof = ClientKey XOR ClientSignatureСборка и отправка: Клиент кодирует
ClientProofв base64 и отправляет его какp=....Чего достигает этот шаг: Клиент доказывает, что он вычислил правильный
ClientKey(и, следовательно, знает пароль), не отправляя его. Доказательство криптографически привязано к данной сессии (через nonce) и к данному TLS-соединению (через привязку к каналу).Шаг 4: Финальное сообщение сервера (Проверка и взаимное доказательство)
Сервер проверяет доказательство клиента и, если оно верно, доказывает собственную подлинность.
Сервер -> Клиент:
v=6rriTRBi23WpRR/wtup+mMhUZUn/dB5nLTJRsjl95G4=Что происходит "под капотом":
Разбор и проверка: Сервер проверяет nonce и получает данные привязки к каналу со своей стороны TLS-соединения. Это момент истины для
-PLUS: если есть "человек посередине", отпечатки каналов не совпадут.Воссоздание
Auth-Message: Он реконструирует в точности ту же строкуAuth-Message, что и клиент.Восстановление
ClientKeyи проверка доказательства:Сервер извлекает из базы данных
StoredKeyдля этого пользователя.Он вычисляет, какой должна быть подпись клиента:
ClientSignature = HMAC(StoredKey, Auth-Message).Он восстанавливает ключ клиента из доказательства:
ClientKey_from_client = ClientProof XOR ClientSignature.Он проверяет ключ:
H(ClientKey_from_client)ДОЛЖЕН быть равен сохранённомуStoredKey. Если совпадает, клиент аутентифицирован.Создание
ServerSignature("эффективная" часть):Сервер извлекает из своей базы данных заранее вычисленный
ServerKeyдля этого пользователя. (Никаких дорогостоящих вычислений здесь не требуется).Он подписывает диалог:
ServerSignature = HMAC(ServerKey, Auth-Message).Сборка и отправка: Сервер кодирует
ServerSignatureв base64 и отправляет как верификаторv=....Чего достигает этот шаг: Эффективно проверяет подлинность клиента и предоставляет доказательство собственной подлинности, завершая взаимную аутентификацию.
Шаг 5: Финальная проверка клиента
Клиент должен проверить сервер, чтобы защититься от самозванцев.
Что происходит "под капотом":
Вычисление ожидаемой
ServerSignature: Клиент используетServerKey, вычисленный на Шаге 3, чтобы рассчитать, какой должна быть подпись сервера:ExpectedServerSignature = HMAC(ServerKey, Auth-Message).Сравнение: Он сравнивает свою вычисленную подпись со значением
v=..., полученным от сервера.Успех или провал: Если они совпадают, сервер подлинный. Если нет, клиент ОБЯЗАН немедленно разорвать соединение.
Чего достигает этот шаг: Защищает клиента от атаки "человек посередине" (Man-in-the-Middle), выполняя обещание взаимной аутентификации.
А тут объяснение (тоже от ЛЛМ) как защищает от MiTM -PLUS:
Скрытый текст
Сценарий атаки MITM (без
-PLUS)Представим классическую атаку MITM:
Клиент -> Злоумышленник: Клиент думает, что подключается к Серверу, но на самом деле устанавливает идеальное, зашифрованное TLS-соединение со Злоумышленником. Назовём это Канал А.
Злоумышленник -> Сервер: Злоумышленник, притворяясь Клиентом, устанавливает второе, такое же идеальное TLS-соединение с настоящим Сервером. Назовём это Канал Б.
Теперь Злоумышленник сидит "посередине" и просто пересылает сообщения SCRAM туда-сюда:
Клиент отправляет
client-first-messageпо Каналу А.Злоумышленник расшифровывает, видит его и пересылает по Каналу Б на Сервер.
Сервер отвечает
server-first-messageпо Каналу Б.Злоумышленник пересылает его по Каналу А Клиенту.
Клиент вычисляет
ClientProofи отправляет его.Злоумышленник пересылает его на Сервер.
Результат: Сервер успешно проверяет
ClientProof. Он считает, что у него установлено защищённое соединение с Клиентом. Но на самом деле он общается со Злоумышленником. Атака удалась.Как
-PLUS(Привязка к каналу) ломает эту атакуВот где собака зарыта. Привязка к каналу заставляет аутентификацию SCRAM "знать" о том TLS-канале, внутри которого она происходит.
Давайте пройдём по тому же сценарию, но теперь с
SCRAM-SHA-256-PLUS.У нас та же ситуация: Клиент <-> Канал А <-> Злоумышленник <-> Канал Б <-> Сервер.
Шаг 3 (Клиент): Когда Клиент готовится создать своё доказательство (
ClientProof), он делает дополнительное действие:Он обращается к своему TLS-уровню и просит: "Дай мне уникальный криптографический отпечаток именно этого TLS-соединения". Этот отпечаток (
channel-binding-data) вычисляется на основе секретов, которыми обменялись стороны во время TLS-рукопожатия.Для Клиента это будет отпечаток Канала А.
Клиент включает этот отпечаток Канала А в строку
Auth-Message, которую он подписывает.Теперь
ClientProofкриптографически зависит не только от пароля и nonce, но и от уникальной идентичности Канала А. Клиент отправляет это доказательство.Злоумышленник, как и раньше, перехватывает это сообщение и пересылает его по Каналу Б на Сервер.
Шаг 4 (Сервер): Момент истины.
Сервер получает
ClientProof. Чтобы его проверить, он должен сам вычислить, каким это доказательство должно быть.Он, так же как и клиент, обращается к своему TLS-уровню и просит: "Дай мне уникальный отпечаток этого TLS-соединения".
Но для Сервера это соединение — Канал Б!
Поскольку TLS-рукопожатия для Канала А (Клиент <-> Злоумышленник) и Канала Б (Злоумышленник <-> Сервер) были двумя совершенно разными, независимыми событиями, их криптографические отпечатки гарантированно будут разными.
Сервер вычисляет ожидаемое доказательство, используя отпечаток Канала Б.
Провал проверки:
Доказательство, полученное от Клиента, было подписано с использованием отпечатка Канала А.
Доказательство, которое ожидает увидеть Сервер, должно быть подписано с использованием отпечатка Канала Б.
Эти два значения не совпадают. Проверка проваливается. Сервер отклоняет попытку входа.
Результат: Атака полностью провалилась.
Аналогия
Представьте, что вы и ваш друг договорились о секретном рукопожатии (это SCRAM).
Без
-PLUS: Вы делаете рукопожатие с мошенником. Мошенник в точности повторяет его с вашим другом. Друг отвечает, мошенник повторяет ответ вам. Всё выглядит нормально.С
-PLUS: Ваше новое рукопожатие включает дополнительный шаг: вы должны вместе указать на уникальную трещину на полу в той комнате, где вы находитесь (это отпечаток канала).Вы находитесь в Комнате А с мошенником и указываете на трещину в ней.
Мошенник пытается передать это вашему другу, который находится в Комнате Б.
Ваш друг смотрит на пол в своей комнате и видит другую трещину (или её отсутствие). Он мгновенно понимает, что вы не в одной комнате, и что-то не так.
Итог: Механизм
-PLUSне просто защищает данные внутри канала. Он криптографически "приваривает" саму аутентификацию к конечным точкам этого конкретного канала, делая невозможной атаку с "прозрачной" ретрансляцией. Он защищает именно от MITM-атаки, запущенной с самого начала.Кстати, я не совсем понимаю, но почему производители используют проприетарные кодеки (за каждый девайс с ними надо чеканную монету отстёгивать) в TWS, которые ещё и непонятно насколько хорошо при низких битрейтах передают качество звучания, вместо того, что использовать открытый Opus, который уже при 128 кб/c для многих прозрачен? Он отлично подходит для Bluetooth благодаря своим фишкам по восстановлению потерянных пакетов типа Deep REDundancy (DRED) на базе ML.
то же самое можно прочитать в меню установки дополнений в самом Burp suite - зачем для этого статья?