Аналогия data-in-use и data-in-motion

[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 в котором окажется что все поголовно и без исключения облачные провайдеры шпионят за своими покупателями, как в собственных интересах, так и в интересах трёхбуквенных агентств.

Comments

[scif_yar]

>>Это абсолютно неизбежно ведёт к скандалу уровня Сноуден 2.0 в котором окажется что все поголовно и без исключения облачные провайдеры шпионят за своими покупателями, как в собственных интересах, так и в интересах трёхбуквенных агентств.
-
Амазон уже взьебали за такое. Ну и как бы - данные обрабатываются в оперативке, в виртуалках - а виртуалки (варя) имеют функционал и фт и мемори дамп - то есть все открытые ключи в памяти могут быть выдернуты.

[contrg2]

из того что вашим открытым паролем никто так и не воспользовался - ещё не следует что он не утёк в первый же раз

из этого следует всего лишь, что он не представлял ни для кого интереса


а тотальная запись трафика пользователя в россии например - ежедневная реальность, и называется пакет яровой

mitm и фальшивые сертификаты - тоже ежедневная реальность(законодательно установленная прошу заметить, а не инициатива мамкиных хакерюг) практически в любом публичном вай-фае


в свете сказанного невозможно как-то всерьёз считать, что незащищённость внутриоблачных данных - это баг, а не фича(для хозяина облака и всяких терроричстических организаций из 3х букав)

[chaource]

А если сдѣлать такъ:

- Всѣ файлы въ облакѣ зашифрованы пользовательскимъ ключомъ (провайдеръ не можетъ расшифровать).

- Всѣ файлы въ облакѣ постоянно перешифруются новыми ключами.

- Всѣ программы работаютъ непосредственно съ зашифрованными данными. расшифровка происходитъ въ памяти сразу передъ обработкой и потомъ результаты опять шифруются.

- Ключи шифрованiя не хранятся въ памяти сколько-нибудь длительное время. Они постоянно сами шифруются съ какими-то случайными ключами, взятыми изъ one-time pad. Сразу передъ использованiемъ ключъ расшифровывается и потомъ опять обратно зашифровывается.

Какъ я понимаю, провайдеру будетъ очень сложно отловить именно ту миллисекунду, на протяженiи которой какой-либо ключъ находился въ незашифрованномъ видѣ гдѣ-то среди 16 ГБ памяти, или какой-либо существенный кусокъ данныхъ былъ бы не зашифрованъ въ памяти.

Это сильно замедлитъ работу, но большинство сегодняшнихъ индустрiальныхъ программъ не требуютъ быстрой работы. Это же не пейсбукъ и не твиторъ, которые должны успѣть сдетектировать и забанить крамольныя мысли среди миллiарда соообщенiй въ день.

[http://users.livejournal.com/sorcerer-/]

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

Нет. Весь смысл HTTPS всегда был чтобы:
1. Централизация и цензура. Отзовем твой HTTPS сертификат и тебе пизда.
2. Чморить ISP. Вся движуха вокруг "net neutrality" и прочего говна. ISP обязан оставаться коммодити, иначе Биг Тек теряет контроль над юзером.

> положения PCI DSS

Ну ты смешной. Это ж просто бумажка. Например сервисы AWS все с этой бумажкой уже.
Она очевидно нихуя не дает. Вообще в секьюрити мало кто в принципе понимает. И на данный момент строить секьюрный продукт - идиотия, тебя мгновенно обскачут конкуренты, что будут просто пиздеть, что они секьюрные.

[mkiv007]

Но ведь как то и Амазон и МС свои облака и гаверменту и пентагону впаривают? Неужели...????

[comment_daily]

А лет 10 назад читал статью про модификацию для FreeBSD, которая ключи держит в кэше процессора и они вообще не утекают в память, вроде там был даже небольшой пенальти на производительность, типа 3-5%. И пользовательский софт не надо переписывать.
Думал, что за 10 лет, подобная фишка вошла уже во все основные ОС, кэши же только выросли.

Аналогично защищаются игровые консоли, то есть память шифрована, но сразу на уровне процессора. Не значит, что их не взламывают.

Конечно, крупный облачный провайдер, наверно может поставить кастомные процессоры которые будут сливать ему дамп кэша, да, в принципе, есть и эксплойты на дамп кэша процессора.

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

А data-in-motion и должна серьезно защищаться, в противном случае легко представляю себе картинку, когда злоумышленний прослушивал бы WiFi предприятия, или перетыкал бы ethernet кабеля под столом в свой роутер с последующим дампом и анализом трафика.