У нас очень много провайдеров (461 по мнению гугла), но даже за ними следят. Например недавний инцидент с "Сибирским медведем", что они на своих серверах ставили прокси Squid, который давал пользователям доступ в ТГ и Ютуб просто по подключению к Wi-Fi. К слову о медведе, месяц назад своими глазами видел, как работают "замедленные" сервисы по их Wi-Fi.
Сайт может физически стоять в РФ, но половина ресурсов тянется снаружи - шрифты, картинки, аналитика и т.д. И для оператора это уже «зарубежный» трафик, хотя пользователь просто открыл страницу. Как раз это я и имел ввиду, говоря, что граница очень условная.
Я просто привёл примеры с «домашним» сценарием, потому что поведение трафика везде одинаковое: CDN, маршрутизация, зарубежные backend’ы никуда не деваются. Смысл в том, что есть вероятность, что это только тесты, как с цензурой неподходящего контента в 2012, с посылом, для защиты детей, создав при этом первый блэк лист неугодных сайтов.
Оператор считает трафик только со своей стороны - то есть ваш. Для него вы просто подключились к серверу в РФ, значит трафик выглядит как «внутренний».
Кто там на этот сервер заливал файлы и откуда - он уже не видит и не учитывает.
Поэтому в такой схеме «зарубежный» трафик как бы есть, но для оператора он превращается в обычный локальный (именно при нашем соединении). А сколько там трафика гонит этот сервер из-за рубежа, нас точно волновать не должно, по крайней мере с нас денег за это не возьмут.
Да, часть GGC действительно осталась, я с этим не спорю. Но ключевой момент в том, что наличие серверов не равняется тому, что весь трафик идёт через них. Маршрутизация у того же Google динамическая: сегодня запрос может попасть в локальный кэш, завтра — уйти за границу. Я думаю, что все прекрасно понимают, что сами по себе «устаревшие сервера» — это скорее формальная причина, чем реальное объяснение деградации.
В статье так много информации о VPN, хотя формально речь идёт про "зарубежный" трафик, потому что во первых, я хотел объяснить сам принцип работы простым языком для большого круга людей, а во вторых, потому что вся история изначально крутится вокруг VPN-сервисов. Сам по себе "зарубежный" трафик столько лет никого особо не волновал, потому что он всегда был, но ИМЕННО сейчас решили начать обсуждать всю эту тему в связке с обходом блокировок. И логика примитивная - если зарубежный трафик приходит пользователю, значит он использует VPN.
Да, вы правы в том, что провайдер прекрасно знает какой абонент сколько трафика потребил. Учет по SIM-карте или договору - это базовая вещь, которая уже давно. Но проблема не в том, сколько трафика, а в том, какой именно трафик считать "зарубежным" и как его классифицировать.
И вот тут как раз основной момент: определить абонента - не проблема, проблема в том, что сам трафик сейчас слишком «плавающий». Один и тот же сервис может в один момент обслуживаться локально, а в другой - идти через зарубежные узлы, при этом для пользователя ничего не меняется. Плюс из-за шифрования провайдер видит только метаданные (IP, порт, объём), но не контекст, поэтому отличить «обычный» зарубежный трафик от того же VPN без ошибок становится задачей с кучей серых зон, а не чёткой технической процедурой, как это было раньше.
Вы говорите о шенноновской энтропии, где при равномерном распределении, достаточной длине строки и алфавита - энтропия будет высокой. А также его термин рассматривает строку без какого-либо контекста, и с теоретической точки зрения это верно, я даже не пытаюсь спорить, а тем более вводить термины и величины.
Я лишь говорю о криптостойкости на практике, ведь если мы введем контекст того, что есть утечка части выходов PRNG, то в таком случае распределение для атакующего уже не является равномерным, из-за чего неопределенность резко снижается.
Да, “реальная энтропия” - неудачная формулировка, правильнее было бы сказать "условная энтропия", с учётом информации, доступной атакующему.
Я не ставил цель в статье показать восстановление внутреннего состояния Mersenne Twister — это уже хорошо известная атака, и при желании её несложно воспроизвести. Мне было важнее объяснить, почему сам выбор генератора здесь принципиален. Возможно, чуть позже, я воспроизведу подобную атаку и расскажу о ней.
Что касается вопроса, для чего фокусироваться именно на свойстве генерации: Проблема не в том, откуда берётся seed. Даже если он получен из urandom, дальше мы имеем дело с детерминированнымPRNG. А значит, при утечке достаточного количества сгенерированных значений появляется возможность восстановить внутреннее состояние и предсказывать остальные.
Например, если в компании N, DevOps для генерации “динамических секретов” использует random, и происходит утечка нескольких тысяч паролей, то при отсутствии reseed’а это уже потенциально позволяет восстановить состояние генератора и предсказывать новые значения.
Аналогично, если есть сервис, который долго генерирует пароли на одном экземпляре MT19937 без reseed’а, то восстановление состояния даёт возможность узнать как будущие, так и прошлые пароли.
Да, в этих примерах должно совпасть довольно много условий, но это не отменяет принципиальной возможности такой атаки.
Поэтому акцент на процессе генерации важен: энтропия начального seed’а сама по себе не делает генератор криптографически стойким. Именно по этой причине для таких задач и существует secrets, а не random.
У нас очень много провайдеров (461 по мнению гугла), но даже за ними следят.
Например недавний инцидент с "Сибирским медведем", что они на своих серверах ставили прокси Squid, который давал пользователям доступ в ТГ и Ютуб просто по подключению к Wi-Fi.
К слову о медведе, месяц назад своими глазами видел, как работают "замедленные" сервисы по их Wi-Fi.
Сайт может физически стоять в РФ, но половина ресурсов тянется снаружи - шрифты, картинки, аналитика и т.д.
И для оператора это уже «зарубежный» трафик, хотя пользователь просто открыл страницу. Как раз это я и имел ввиду, говоря, что граница очень условная.
Я просто привёл примеры с «домашним» сценарием, потому что поведение трафика везде одинаковое: CDN, маршрутизация, зарубежные backend’ы никуда не деваются. Смысл в том, что есть вероятность, что это только тесты, как с цензурой неподходящего контента в 2012, с посылом, для защиты детей, создав при этом первый блэк лист неугодных сайтов.
Оператор считает трафик только со своей стороны - то есть ваш. Для него вы просто подключились к серверу в РФ, значит трафик выглядит как «внутренний».
Кто там на этот сервер заливал файлы и откуда - он уже не видит и не учитывает.
Поэтому в такой схеме «зарубежный» трафик как бы есть, но для оператора он превращается в обычный локальный (именно при нашем соединении). А сколько там трафика гонит этот сервер из-за рубежа, нас точно волновать не должно, по крайней мере с нас денег за это не возьмут.
Хорошо сказано, но я пожалуй буду принимать наиболее нейтральную позицию))
Да, часть GGC действительно осталась, я с этим не спорю. Но ключевой момент в том, что наличие серверов не равняется тому, что весь трафик идёт через них. Маршрутизация у того же Google динамическая: сегодня запрос может попасть в локальный кэш, завтра — уйти за границу.
Я думаю, что все прекрасно понимают, что сами по себе «устаревшие сервера» — это скорее формальная причина, чем реальное объяснение деградации.
В статье так много информации о VPN, хотя формально речь идёт про "зарубежный" трафик, потому что во первых, я хотел объяснить сам принцип работы простым языком для большого круга людей, а во вторых, потому что вся история изначально крутится вокруг VPN-сервисов. Сам по себе "зарубежный" трафик столько лет никого особо не волновал, потому что он всегда был, но ИМЕННО сейчас решили начать обсуждать всю эту тему в связке с обходом блокировок. И логика примитивная - если зарубежный трафик приходит пользователю, значит он использует VPN.
Да, вы правы в том, что провайдер прекрасно знает какой абонент сколько трафика потребил. Учет по SIM-карте или договору - это базовая вещь, которая уже давно.
Но проблема не в том, сколько трафика, а в том, какой именно трафик считать "зарубежным" и как его классифицировать.
И вот тут как раз основной момент: определить абонента - не проблема, проблема в том, что сам трафик сейчас слишком «плавающий». Один и тот же сервис может в один момент обслуживаться локально, а в другой - идти через зарубежные узлы, при этом для пользователя ничего не меняется. Плюс из-за шифрования провайдер видит только метаданные (IP, порт, объём), но не контекст, поэтому отличить «обычный» зарубежный трафик от того же VPN без ошибок становится задачей с кучей серых зон, а не чёткой технической процедурой, как это было раньше.
Вы говорите о шенноновской энтропии, где при равномерном распределении, достаточной длине строки и алфавита - энтропия будет высокой. А также его термин рассматривает строку без какого-либо контекста, и с теоретической точки зрения это верно, я даже не пытаюсь спорить, а тем более вводить термины и величины.
Я лишь говорю о криптостойкости на практике, ведь если мы введем контекст того, что есть утечка части выходов PRNG, то в таком случае распределение для атакующего уже не является равномерным, из-за чего неопределенность резко снижается.
Да, “реальная энтропия” - неудачная формулировка, правильнее было бы сказать "условная энтропия", с учётом информации, доступной атакующему.
Я не ставил цель в статье показать восстановление внутреннего состояния Mersenne Twister — это уже хорошо известная атака, и при желании её несложно воспроизвести. Мне было важнее объяснить, почему сам выбор генератора здесь принципиален. Возможно, чуть позже, я воспроизведу подобную атаку и расскажу о ней.
Что касается вопроса, для чего фокусироваться именно на свойстве генерации: Проблема не в том, откуда берётся
seed. Даже если он получен изurandom, дальше мы имеем дело с детерминированным PRNG. А значит, при утечке достаточного количества сгенерированных значений появляется возможность восстановить внутреннее состояние и предсказывать остальные.Например, если в компании N, DevOps для генерации “динамических секретов” использует random, и происходит утечка нескольких тысяч паролей, то при отсутствии
reseed’а это уже потенциально позволяет восстановить состояние генератора и предсказывать новые значения.Аналогично, если есть сервис, который долго генерирует пароли на одном экземпляре
MT19937безreseed’а, то восстановление состояния даёт возможность узнать как будущие, так и прошлые пароли.Да, в этих примерах должно совпасть довольно много условий, но это не отменяет принципиальной возможности такой атаки.
Поэтому акцент на процессе генерации важен: энтропия начального
seed’а сама по себе не делает генератор криптографически стойким. Именно по этой причине для таких задач и существуетsecrets, а неrandom.