Я сломал локоть. Хирург 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.
Паша не является идолом правильного питания ни для кого из хабровчан - просто чел с деньгами. По сути, это как если бы я написал статью про свой режим питания - может и можно что-то нарыть, но ценность маленькая.
Ага, всё верно :) Просто народ в ступоре, когда подвисает логин скрин, но если ему написать, что подвисает он не просто так, то всё ок. Смущало ещё, что многие малые и средние бизнесы просили вырубить TLS по умолчанию (раньше можно было и без шифрования), но потом мы задолбались поддерживать две схемы работы и сделали с TLS только. Корпораты ничего не заметили, а средних и малых инженерам поддержки пришлось учить как работать с сертификатами, мда
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.
Паша не является идолом правильного питания ни для кого из хабровчан - просто чел с деньгами. По сути, это как если бы я написал статью про свой режим питания - может и можно что-то нарыть, но ценность маленькая.
Наконец начались статьи о силовых тренировках, когда везде затирают о "24 подхода по 12 раз по 2 кг".
Ага, всё верно :) Просто народ в ступоре, когда подвисает логин скрин, но если ему написать, что подвисает он не просто так, то всё ок. Смущало ещё, что многие малые и средние бизнесы просили вырубить TLS по умолчанию (раньше можно было и без шифрования), но потом мы задолбались поддерживать две схемы работы и сделали с TLS только. Корпораты ничего не заметили, а средних и малых инженерам поддержки пришлось учить как работать с сертификатами, мда