Аналогия data-in-use и data-in-motion
Nov. 22nd, 2021 08:46 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
leo_sosnineСуществуют различные состояния информации в которых она может быть атакована различными способами. Например, два состояния на которые я хотел бы обратить внимание это data-in-use и data-in-motion.
К нынешнему дню data-in-motion хорошо защищена, большинство протоколов перепроложили поверх TLS или они поддерживают нативную аутентификацию и шифрование. И всё это делается ради уменьшения простого риска -- якобы сервис провайдер будет нюхать наши пакеты и копировать себе, чем создаст утечку, а то и подменит важную информацию на лету и изменит смысл пересылаемого сообщения. Классика "Man in the middle".
Ничего подобного в практическом инфобезе не происходит: MITM атаки крайне редки. Случаи практической эксплуатации, допустим, BEAST атаки на TLS равны нулю. Причина номер один этого в том, что хозяева роутеров, лежащих между источником и назначением, в этом особого интереса не видят. И по сей день можно годами, допустим, аутентифицироваться по чистому HTTP через, допустим, формы или базовую, при которых пароль передаётся открытым текстом, и буквально всем будет на это похуй и наш пароль никому не будет нужен. Я проводил такой эксперимент (ну, например, на сервере можно отслеживать факты аутентификации) годами с нулевым результатом.
Таким образом, МИТМ атаки это удел маргинальных сценариев типа "открытая или PSK вай-фай сеть" или комбинации со спуфом сервера.
Тем не менее, кажного тупого инфобезничка в америчке обымет трясунец, если вдруг ему предложить одобрить дизайн приложения, которое обменивается сообщениями в открытом тексте, даже если это всё происходит внутри одного датацентра. "Усё должно быть зашифровано во время передачи", ггг.
При этом абсолютно аналогичные и я бы даже сказал большие по размеру риски для data-in-use в облаках полностью игнорируются и вся проблема спускается на тормозах. Как я уже много раз писал в этом бложеке, если информация обрабатывается в облаках, облачный провайдер не может избавиться от доступа к ней, причём доступа неконтролируемого. Попробуйте на митингах с агитаторами переезда в облака задать простой вопрос -- имеют ли ваши собственные сотрудники и сотрудники Амазона, где вы хостите своё говноподелие, доступ к нашим данным и послушать их бессмысленные заверения в полной зашифрованности и даже доступности технологий Bring Your Own Key. Это всё -- полнейшая туфта, доступ они имеют, доступ неконтролируемый и избавиться от него они не могут. И проверяется это простым вопросом: "...but, for you, in order to process our information, it has to be decrypted first, right? RIGHT, MOTHERFUCKER? ANSWER ME!"
Каким образом это существенно отличается от рисков для состояния data-in-motion в отношении которых все знают, что незашифрованные соединения абсолютно недопустимы в наше время и любой трафик должен быть зашифрован и через TLS? Ну, например, любой икоммерс прямо запрещён, если трафик не зашифрован, через соотв. положения PCI DSS, которые энфорсятся на любого процессора данных кредитных карт. И при этом он же в облаках (причём нередко с многослойным пирогом различных провайдеров от инфраструктуры через платформу до софта) разрешён.
Все эти хуесосы являются сертифицированными специалистами, читают соответствующие книжки и торчат на соответствующих конференциях. Проблема в том, что все эти источники "знаний" оплачиваются теми самыми облачными провайдерами которым не хотелось бы, чтобы эта информация была широко известна.
Это абсолютно неизбежно ведёт к скандалу уровня Сноуден 2.0 в котором окажется что все поголовно и без исключения облачные провайдеры шпионят за своими покупателями, как в собственных интересах, так и в интересах трёхбуквенных агентств.
К нынешнему дню data-in-motion хорошо защищена, большинство протоколов перепроложили поверх TLS или они поддерживают нативную аутентификацию и шифрование. И всё это делается ради уменьшения простого риска -- якобы сервис провайдер будет нюхать наши пакеты и копировать себе, чем создаст утечку, а то и подменит важную информацию на лету и изменит смысл пересылаемого сообщения. Классика "Man in the middle".
Ничего подобного в практическом инфобезе не происходит: MITM атаки крайне редки. Случаи практической эксплуатации, допустим, BEAST атаки на TLS равны нулю. Причина номер один этого в том, что хозяева роутеров, лежащих между источником и назначением, в этом особого интереса не видят. И по сей день можно годами, допустим, аутентифицироваться по чистому HTTP через, допустим, формы или базовую, при которых пароль передаётся открытым текстом, и буквально всем будет на это похуй и наш пароль никому не будет нужен. Я проводил такой эксперимент (ну, например, на сервере можно отслеживать факты аутентификации) годами с нулевым результатом.
Таким образом, МИТМ атаки это удел маргинальных сценариев типа "открытая или PSK вай-фай сеть" или комбинации со спуфом сервера.
Тем не менее, кажного тупого инфобезничка в америчке обымет трясунец, если вдруг ему предложить одобрить дизайн приложения, которое обменивается сообщениями в открытом тексте, даже если это всё происходит внутри одного датацентра. "Усё должно быть зашифровано во время передачи", ггг.
При этом абсолютно аналогичные и я бы даже сказал большие по размеру риски для data-in-use в облаках полностью игнорируются и вся проблема спускается на тормозах. Как я уже много раз писал в этом бложеке, если информация обрабатывается в облаках, облачный провайдер не может избавиться от доступа к ней, причём доступа неконтролируемого. Попробуйте на митингах с агитаторами переезда в облака задать простой вопрос -- имеют ли ваши собственные сотрудники и сотрудники Амазона, где вы хостите своё говноподелие, доступ к нашим данным и послушать их бессмысленные заверения в полной зашифрованности и даже доступности технологий Bring Your Own Key. Это всё -- полнейшая туфта, доступ они имеют, доступ неконтролируемый и избавиться от него они не могут. И проверяется это простым вопросом: "...but, for you, in order to process our information, it has to be decrypted first, right? RIGHT, MOTHERFUCKER? ANSWER ME!"
Каким образом это существенно отличается от рисков для состояния data-in-motion в отношении которых все знают, что незашифрованные соединения абсолютно недопустимы в наше время и любой трафик должен быть зашифрован и через TLS? Ну, например, любой икоммерс прямо запрещён, если трафик не зашифрован, через соотв. положения PCI DSS, которые энфорсятся на любого процессора данных кредитных карт. И при этом он же в облаках (причём нередко с многослойным пирогом различных провайдеров от инфраструктуры через платформу до софта) разрешён.
Все эти хуесосы являются сертифицированными специалистами, читают соответствующие книжки и торчат на соответствующих конференциях. Проблема в том, что все эти источники "знаний" оплачиваются теми самыми облачными провайдерами которым не хотелось бы, чтобы эта информация была широко известна.
Это абсолютно неизбежно ведёт к скандалу уровня Сноуден 2.0 в котором окажется что все поголовно и без исключения облачные провайдеры шпионят за своими покупателями, как в собственных интересах, так и в интересах трёхбуквенных агентств.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2021-11-23 05:21 am (UTC)-
Амазон уже взьебали за такое. Ну и как бы - данные обрабатываются в оперативке, в виртуалках - а виртуалки (варя) имеют функционал и фт и мемори дамп - то есть все открытые ключи в памяти могут быть выдернуты.
no subject
Date: 2021-11-23 07:27 am (UTC)из этого следует всего лишь, что он не представлял ни для кого интереса
а тотальная запись трафика пользователя в россии например - ежедневная реальность, и называется пакет яровой
mitm и фальшивые сертификаты - тоже ежедневная реальность(законодательно установленная прошу заметить, а не инициатива мамкиных хакерюг) практически в любом публичном вай-фае
в свете сказанного невозможно как-то всерьёз считать, что незащищённость внутриоблачных данных - это баг, а не фича(для хозяина облака и всяких терроричстических организаций из 3х букав)
no subject
Date: 2021-11-23 04:47 pm (UTC)В западном мире идея тотальной слежки, разумеется, существует и у неё много адептов, особенно среди спецслужб. Однако же, в правовом поле эта идея до сих пор не побеждает, т.к. до сих пор существует консенсус, что информация о каждом человеке или организации принадлежит им и они вправе ей распоряжаться как они хотят, а другие (включая организации и правительства) прав на неё не имеют никаких. Примеров этой борьбы, причём где идея слежки проигрывает, полно, например
https://en.wikipedia.org/wiki/Clipper_chip
Современная криптография и соответствующие технологии вокруг разрабатываются таким образом, чтобы сделать перехват информации невозможным. И они, в целом, работают.
no subject
Date: 2021-11-23 05:32 pm (UTC)no subject
Date: 2021-11-24 04:59 am (UTC)no subject
Date: 2021-11-28 05:39 pm (UTC)тута вон человек плакался, шо на западе иной раз подтягивают даже за скачивание пирацкого дегенеративного кинца без впн
видимо потому что все росказни про анб, гигантские снифферы практически у всех без исключения провайдеров и вот это всё - исключительно выдумки параноиков
ну так бабушкам у подъездов по тельавизору рассказывают ))
no subject
Date: 2021-11-23 07:43 am (UTC)- Всѣ файлы въ облакѣ зашифрованы пользовательскимъ ключомъ (провайдеръ не можетъ расшифровать).
- Всѣ файлы въ облакѣ постоянно перешифруются новыми ключами.
- Всѣ программы работаютъ непосредственно съ зашифрованными данными. расшифровка происходитъ въ памяти сразу передъ обработкой и потомъ результаты опять шифруются.
- Ключи шифрованiя не хранятся въ памяти сколько-нибудь длительное время. Они постоянно сами шифруются съ какими-то случайными ключами, взятыми изъ one-time pad. Сразу передъ использованiемъ ключъ расшифровывается и потомъ опять обратно зашифровывается.
Какъ я понимаю, провайдеру будетъ очень сложно отловить именно ту миллисекунду, на протяженiи которой какой-либо ключъ находился въ незашифрованномъ видѣ гдѣ-то среди 16 ГБ памяти, или какой-либо существенный кусокъ данныхъ былъ бы не зашифрованъ въ памяти.
Это сильно замедлитъ работу, но большинство сегодняшнихъ индустрiальныхъ программъ не требуютъ быстрой работы. Это же не пейсбукъ и не твиторъ, которые должны успѣть сдетектировать и забанить крамольныя мысли среди миллiарда соообщенiй въ день.
no subject
Date: 2021-11-23 07:57 am (UTC)no subject
Date: 2021-11-23 04:50 pm (UTC)-
Современные системы шифруют не файлы, ибо шифровать файл на пару теребайт немного .. накладно
---
>>- Всѣ файлы въ облакѣ постоянно перешифруются новыми ключами.
-
За чей счет банкет ? Это мощности и нехилые
---
>>Какъ я понимаю, провайдеру будетъ очень сложно отловить именно ту миллисекунду, на протяженiи которой какой-либо ключъ находился въ незашифрованномъ видѣ гдѣ-то среди 16 ГБ памяти,
-
Ключ должен существовать все время операций каскадирования, и это не миллисекунды.
Вы бы посчитали чтоли во сколько обойдется хотя бы 3des для БД в хотя бы 1 Тб под нагрузкой в 1000 запросов/сек по 200 кб , без учета хранимок
no subject
Date: 2021-11-23 04:53 pm (UTC)А для клиента изобретать велосипед и не полагаться на чужой софт ох как дорого встанет.
no subject
Date: 2021-11-24 03:51 am (UTC)no subject
Date: 2021-11-23 08:00 am (UTC)Нет. Весь смысл HTTPS всегда был чтобы:
1. Централизация и цензура. Отзовем твой HTTPS сертификат и тебе пизда.
2. Чморить ISP. Вся движуха вокруг "net neutrality" и прочего говна. ISP обязан оставаться коммодити, иначе Биг Тек теряет контроль над юзером.
> положения PCI DSS
Ну ты смешной. Это ж просто бумажка. Например сервисы AWS все с этой бумажкой уже.
Она очевидно нихуя не дает. Вообще в секьюрити мало кто в принципе понимает. И на данный момент строить секьюрный продукт - идиотия, тебя мгновенно обскачут конкуренты, что будут просто пиздеть, что они секьюрные.
no subject
Date: 2021-11-23 08:46 am (UTC)Это проблема в меньшей степени сервиса, а в большей - потребителя.
no subject
Date: 2021-11-23 01:16 pm (UTC)no subject
Date: 2021-11-23 04:46 pm (UTC)no subject
Date: 2021-11-23 05:53 pm (UTC)no subject
Date: 2021-11-23 07:12 pm (UTC)Сертификаты надо подкладывать хорошие.
no subject
Date: 2021-11-23 07:24 pm (UTC)no subject
Date: 2021-11-23 11:11 pm (UTC)no subject
Date: 2021-11-24 01:36 am (UTC)no subject
Date: 2021-11-24 09:44 pm (UTC)Только неясно каким образом мусор в VPN
no subject
Date: 2021-11-24 10:06 pm (UTC)no subject
Date: 2021-11-24 10:08 pm (UTC)Это же легко понять, если есть DPI.
no subject
Date: 2021-11-24 10:11 pm (UTC)впн сконфигурирован так, что сначала запрашивается днс провайдера, а потом, при NOTFOUND/SERVFAIL днс работодателя/сетки впн.
no subject
Date: 2021-11-24 10:10 pm (UTC)Этого нет в стандарте.
no subject
Date: 2021-11-24 10:22 pm (UTC)И я не знаю, что бы пытаетесь доказать. Что я не понял того, что происходило, и чему был свидетелем? Что вы лучше меня все знаете и понимаете? Хули вы, так сказать, доебываетесь? Не в первый раз, кстати.
no subject
Date: 2021-11-24 10:36 pm (UTC)no subject
Date: 2021-11-28 05:27 pm (UTC)путо-хабадские мегавно с йоптой, в этом вопросе разумеется были первопроходцами
no subject
Date: 2021-11-23 06:40 pm (UTC)no subject
Date: 2021-11-23 11:55 pm (UTC)no subject
Date: 2021-11-24 03:50 am (UTC)-
У анб и прочих гаверментов свои цод.
no subject
Date: 2021-11-25 08:25 am (UTC)Думал, что за 10 лет, подобная фишка вошла уже во все основные ОС, кэши же только выросли.
Аналогично защищаются игровые консоли, то есть память шифрована, но сразу на уровне процессора. Не значит, что их не взламывают.
Конечно, крупный облачный провайдер, наверно может поставить кастомные процессоры которые будут сливать ему дамп кэша, да, в принципе, есть и эксплойты на дамп кэша процессора.
По итогу, оперативная память для процессора по скорости не принципиально отличается от жесткого диска, особенно, твердотельного, а жесткие диски все шифруют в облаке, соответственно можно шифровать и оперативную память. Процессор же непосредственно работает только со своим кэшем.
А data-in-motion и должна серьезно защищаться, в противном случае легко представляю себе картинку, когда злоумышленний прослушивал бы WiFi предприятия, или перетыкал бы ethernet кабеля под столом в свой роутер с последующим дампом и анализом трафика.
no subject
Date: 2021-11-25 04:45 pm (UTC)no subject
Date: 2021-11-25 08:33 pm (UTC)Но, я другом. Что все таки облачный провайдер может "в теории" избавиться от доступа к пользовательской информации.
Вот такая аналогия. Немного перевернем ситуацию. Производители компьютерных игр отдают свои данные в виде игр конечным пользователям, которые заинтереснованы играть в них бесплатно, тиражировать бесплатно, модифицировать бесплатно и так далее. Причем у пользователей полный доступ к железу игровых приставок. Конечно, не на таком легком уровне как у облачных провайдеров с гипервизором и не с такими финансовыми и техническими возможностями как у ЦРУ. Но все-таки можно снять дамп с чипов памяти. Вот он путь к пиратству? На одной приставке сняли дамп, на другой запустили. Нет, так не сработает, память зашифрована, плюс все процессоры на плате в разном состоянии.
Как это организовано с технической точки зрения? AMD произвела процессор, продала Microsoft, Microsoft в контролируемом окружении прожгла на процессоре перемычки ( электронные ), туда записался секретный ключ. В процессе работы игровой приставки этот ключ, не светится ни на диске, ни в памяти. Конечно остается вариант разобрать процессор ( весьма трудоемкий ), чтобы получить значения перемычек, сделать так сказать dump процессора, но он будет стоить миллионы долларов, поэтому, обычно идут путем софтового эксплойта ( иногда совмещают с аппаратным гличем ), эксплуатируют все выше и выше.
Можно аналогичным путем идти и для облачной инфраструктуры. Покупаются процессоры ( возможно в составе платы ), далее они инициализируются на предприятии, потом передаются облачному провайдеру, который их использует в собственном окружении, со своей памятью, дисками, материнскими платами.
Конечно, остается вариант сговора Intel/AMD, c Microsoft/Amazon, но если производителей процессоров пара штук, то облачных провайдеров гораздо больше. И возможно, что китайское или российское облако, не будут идти на поводу ЦРУ, и в то же время не смогут получить пользовательские данные в своих целях.
no subject
Date: 2021-11-25 09:13 pm (UTC)Хотя "в теории" это возможно, но уж точно не через шифрование памяти и хранение ключей в кэше, а через homomorphic encryption.
no subject
Date: 2021-11-25 09:50 pm (UTC)Я хочу сказать, что проблема давно была осознана производителями всякого железа.
Типа вложишься в разработку, а конкуренты снимут прошивку с готового устройства и будут продавать дешевле. Как раз уход в онлайн частично снял эту проблему, но наработки лет 30 назад были уже. Другое дело, что и процессоры ( для embedded ) тогда снимались послойно кислотой и микроскопом. А сейчас просто ситуация сделала круг, и уход в облачный онлайн уже угроза.
no subject
Date: 2021-11-27 03:25 am (UTC)Не понятно, однако, как это могло бы работать надёжно в принципе, т.к. это, судя по всему, не более чем прокси, в котором слой из которого информацию нужно пиздить (на диске зашифровано и на данный момент атакуется память) сдвигается на 1-2 уровня вглубь.
Но, допустим, ключ шифрования и сама операция шифрования происходят в процессоре и/или кэше, всё это железо тем не менее находится в руках заинтересованного игрока, а значит это вопрос ресурсов расколупать как это работает, вытащить ключи, воссоздать код программно и расшифровать дампы памяти вытащенными ключами. Хотя, не спорю, это существенно сложнее чем как щас просто тупо делать дамп из гипервизора, и, возможно, остановит некоторый процент абьюза.
no subject
Date: 2021-11-27 08:55 am (UTC)Но многое зависит от количества денег вложенных в защиту и количества устройств. Apple же вкладывается в технологии защиты от ремонта, то есть разбирания устройства. В сервачок, можно хоть детектор рентгеновских лучей вставить, если просвечивают, окирпичиваемся, а облачная платформа будет должна денег.
Конечно, это будет уже не совсем облачная платформа, которая подразумевает шаринг аппаратных ресурсов и за счет этого их экономию. Но электричество, охлаждение, гигабиты будут по прежнему разделяться, да и дисковое пространство с памятью можно шарить, не исключаю, что и сервачок с защитой от рентгена будет стандартизован, чтобы каждому конечному пользователю не изобретать велосипед.