допустим, я создал сервис, который что-то шифрует на клиенте с помощью js. то есть, на сервер отправляется уже зашифрованная информация и сервер никак не может ее расшифровать. таких сервисов полно. zero knowledge system.
как вы можете быть уверены, что сервер иногда умышленно не отдает какому-нибудь счастливчику слегка модифицированную версию js, которая, например, отправляет пароль в чистом виде на сервер? вы ведь не будете каждый ответ от сервера изучать?
Здравствуйте, sin_cos, Вы писали:
s> как вы можете быть уверены, что сервер иногда умышленно не отдает какому-нибудь счастливчику слегка модифицированную версию js
А разве кто-то играет в эти игры с верю-неверю? Отправляться должны всегда только шифрованные данные без вариантов.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, sin_cos, Вы писали:
s>> как вы можете быть уверены, что сервер иногда умышленно не отдает какому-нибудь счастливчику слегка модифицированную версию js
AB>А разве кто-то играет в эти игры с верю-неверю? Отправляться должны всегда только шифрованные данные без вариантов.
ты понял, о чем вопрос? как сервер стянет у тебя пароль, когда он пошлет тебе модифицированный js файл -- это уже дело техники. может и в зашифрованном виде отправить себе же.
Здравствуйте, sin_cos, Вы писали:
_>как вы можете быть уверены, что сервер иногда умышленно не отдает какому-нибудь счастливчику слегка модифицированную версию js, которая, например, отправляет пароль в чистом виде на сервер? вы ведь не будете каждый ответ от сервера изучать?
Полной гарантии, разумеется, нет. А уверенность может базироваться на том, что
код и процесс разработки открыт, его можно изучить и найти изъяны
есть активное сообщество, то есть высока вероятность, что найдется кто-то умный и код изучит.
сервис дорожит своей репутацией; при серьезном проколе код можно форкнуть и забрать большинство пользователей на новый сервис.
Нужно также заметить, что эта проблема актуальна для любого кода. Например, скачивая дистрибутив Debian, как ты можешь быть уверен, что там нет какой-то гадости? (А попытки взломать их сервера и внести изменения в репы реально были.) То есть тут браузер/не браузер не играет никакой роли.
Ну и еще можно заметить, что уже скоро должны разродиться с WebAssembly, и сборки клиентского кода будет подписываться, почти как в Дебиане. Плюс одно очко к уверенности.
Здравствуйте, sin_cos, Вы писали:
s> ты понял, о чем вопрос? как сервер стянет у тебя пароль, когда он пошлет тебе модифицированный js файл -- это уже дело техники. может и в зашифрованном виде отправить себе же.
Не важно какой js пошлет файл, если ты отправляешь изначально только зашифрованные данные. Если пришлет обычный js, то будет второй раунд шифрования. Если пришлет "пасхальный", то данные будут зашифрованы только один раз (тобой).
Здравствуйте, Anton Batenev, Вы писали:
AB>Не важно какой js пошлет файл, если ты отправляешь изначально только зашифрованные данные. Если пришлет обычный js, то будет второй раунд шифрования. Если пришлет "пасхальный", то данные будут зашифрованы только один раз (тобой).
Кем "тобой"-то? Если "ты" шифруешь тем, что сервер присылает.
Здравствуйте, Anton Batenev, Вы писали:
AB>А разве кто-то играет в эти игры с верю-неверю? Отправляться должны всегда только шифрованные данные без вариантов.
Я бы не был столь категоричен. Для веб-почты, например, это не вариант.
Здравствуйте, sin_cos, Вы писали:
_>как вы можете быть уверены, что сервер иногда умышленно не отдает какому-нибудь счастливчику слегка модифицированную версию js, которая, например, отправляет пароль в чистом виде на сервер? вы ведь не будете каждый ответ от сервера изучать?
Так эта фишка полезна, чтобы общаться с доверенными серваками. Это всяко лучше, чем доверять шифрованию в браузере, скачанном в виде бинаря.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, sin_cos, Вы писали:
s>> ты понял, о чем вопрос? как сервер стянет у тебя пароль, когда он пошлет тебе модифицированный js файл -- это уже дело техники. может и в зашифрованном виде отправить себе же.
AB>Не важно какой js пошлет файл, если ты отправляешь изначально только зашифрованные данные.
я не понял, про что ты.
я сам не пишу js код, который эти данные шифрует. мне этот код приходит от сервера.
Здравствуйте, wildwind, Вы писали:
W>код и процесс разработки открыт, его можно изучить и найти изъяны
ну нашел, их исправили, дальше что? ты внимательно прочитал мой вопрос?
W>Нужно также заметить, что эта проблема актуальна для любого кода. Например, скачивая дистрибутив Debian, как ты можешь быть уверен, что там нет какой-то гадости?
никак. но, у меня и исходного кода, который я скачал в бинарнике, нет.
Здравствуйте, sin_cos, Вы писали:
_>допустим, я создал сервис, который что-то шифрует на клиенте с помощью js. то есть, на сервер отправляется уже зашифрованная информация и сервер никак не может ее расшифровать. таких сервисов полно. zero knowledge system.
_>как вы можете быть уверены, что сервер иногда умышленно не отдает какому-нибудь счастливчику слегка модифицированную версию js, которая, например, отправляет пароль в чистом виде на сервер? вы ведь не будете каждый ответ от сервера изучать?
1. Страница шифрования со всеми скриптами, стилями должна быть всегда идентична, никаких счётчиков. Изменяться может только при выпуске новой версии.
2. В браузере должен стоять аддон, считающий хеш-сумму страницы, всех её ресурсов.
3. Код на JavaScript не должен делать некоторые вещи, которые могут вызвать выполнение незагруженного ранее кода, например eval, добавление тегов <script> и тд. Тут надо хорошо подумать.
Конечно же всё должно быть доступно open-source с возможностью собрать идентичную версию.
Тогда ты можешь быть уверен, что выполняется именно тот код, который открыто опубликован.
"Из коробки" — никак. Только надеяться на честность владельца сервиса и то, что тобой не заинтересуются спецслужбы, которые могут надавить на него. А лучше пользоваться оффлайн-средствами вроде GPG.
vsb>2. В браузере должен стоять аддон, считающий хеш-сумму страницы, всех её ресурсов.
и нужно эту хэш сумму как-то запомнить? и потом показывать alert, если она другая? а если просто обновление дизайна было, плановое? или даже новая, улучшенная версия скрипта?
vsb>3. Код на JavaScript не должен делать некоторые вещи, которые могут вызвать выполнение незагруженного ранее кода, например eval, добавление тегов <script> и тд. Тут надо хорошо подумать.
это да. но. влюченое слово "иногда". допустим, владелец решил на каждый тысячный запрос присылать js с сюрпризом. то есть, это и не каждому, и довольно редко.
vsb>"Из коробки" — никак. Только надеяться на честность владельца сервиса и то, что тобой не заинтересуются спецслужбы, которые могут надавить на него. А лучше пользоваться оффлайн-средствами вроде GPG.
Здравствуйте, sin_cos, Вы писали:
vsb>>2. В браузере должен стоять аддон, считающий хеш-сумму страницы, всех её ресурсов.
_>и нужно эту хэш сумму как-то запомнить? и потом показывать alert, если она другая?
В простейшем случае да. В более сложном — проверять, например, через github или какой-нибудь другой каталог, что эта хеш-сумма соответствует публичному релизу.
_>а если просто обновление дизайна было, плановое? или даже новая, улучшенная версия скрипта?
Ну тут ты уже сам решаешь — доверять этому обновлению или подождать, пока "тысячи глаз" просмотрят код (ну или самому просмотреть коммиты). Конечно на официальном сайте в каком-то виде должны быть эти хеши и их соответствия релизам.
Здравствуйте, sin_cos, Вы писали:
s> AB>Не важно какой js пошлет файл, если ты отправляешь изначально только зашифрованные данные. s> я не понял, про что ты. s> я сам не пишу js код, который эти данные шифрует. мне этот код приходит от сервера.
Смотри. Ты задался вопросом — можно ли доверять инструменту шифрования (в изначальном сообщении это некий js код присылаемый из некоего недоверенного источника) и сам же дал вполне очевидный ответ — такому инструменту доверять нельзя.
Если инструменту нельзя доверять, то уже не имеет значения на сколько "честно" он шифрует. Т.е. твои данные должны шифроваться не этим кодом, а другим, которому ты доверяешь. А этому недоверенному js коду должны всегда скармливаться только зашифрованные данные (и становится не важно, будет ли он их честно шифровать или напрямую отправит злодею в открытом виде).
P.S. Все эти сервисы "шифровальщики" — чистый маркетинг. "Вот, мол, было изваяние, а теперь стала Марья Ивановна. Многие верят."
Здравствуйте, Anton Batenev, Вы писали:
AB>P.S. Все эти сервисы "шифровальщики" — чистый маркетинг.
Кроме тех, разумеется, которым доверяешь лично ты. Только не говори, что сам их пишешь.
Основная проблема в том, что делать простым юзерам. А если вспомнить принцип "don't roll your own crypto", то к этой категории можно отнести почти всех.
AB>А этому недоверенному js коду должны всегда скармливаться только зашифрованные данные (и становится не важно, будет ли он их честно шифровать или напрямую отправит злодею в открытом виде).
как ты себе это представляешь? допустим, он шифрует текст, который потом может расшифровать другой человек, зная пароль, мы оба его знаем. типа, безопасный чат.
ты предлагаешь вместо чистого текста зашифровать шифр?
Здравствуйте, sin_cos, Вы писали:
_>как вы можете быть уверены, что сервер иногда умышленно не отдает какому-нибудь счастливчику слегка модифицированную версию js, которая, например, отправляет пароль в чистом виде на сервер?
Никак. Нельзя одновременно доверять (принимая и выполняя от сервера js) и не доверять (шифруя передаваемые на сервер данные) одному и тому же субъекту. Также, как ты не можешь быть уверен в том, что с очередным обновлением системы, у тебя не пропадёт вообще всё шифрование, буду отключённым или намеренно ослабленным на уровне крипто-API самой ОС.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Нельзя одновременно доверять (принимая и выполняя от сервера js) и не доверять (шифруя передаваемые на сервер данные) одному и тому же субъекту.
Не совсем так. Этому субъекту мы можем и доверять, не доверяем мы больше другим субъектам, которые могут так или иначе получить данные у первого.
Здравствуйте, wildwind, Вы писали:
w> Не совсем так. Этому субъекту мы можем и доверять, не доверяем мы больше другим субъектам, которые могут так или иначе получить данные у первого.
Из сообщения ТС очевидно, что его интересует ситуация, когда мы не доверяем серверу свои данные.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, sin_cos, Вы писали:
s>> зачем тут сервис вообща тогда нужен
AB>Правильно заданный вопрос — половина ответа. Такой сервис не нужен, т.к. не может выполнять свои функции.
Здравствуйте, kochetkov.vladimir, Вы писали: KV>Здравствуйте, wildwind, Вы писали: w>> Не совсем так. Этому субъекту мы можем и доверять, не доверяем мы больше другим субъектам, которые могут так или иначе получить данные у первого. KV>Из сообщения ТС очевидно, что его интересует ситуация, когда мы не доверяем серверу свои данные.
Мне кажется единственная боле-менее безопасная связка в таком контексте это специальная надстрока к qubes в виде комплекта из:
1) шифрующего прокси сервера который шифрует весь контент внутри html тегов на своём ключе в отдельной виртуалке encrypting proxy vm.
2) этот прокси указан в качестве net vm
3) в этой net vm запрёщён любой трафик кроме http на сервер предоставляющий сервис, + dns resolv ограничиваемый следующим пунктом.
4) кастомный dns сервер в netvm в котором запрещен dns resolve всего кроме небольшого белого списка доменов сервера с которым идёт работа (+ запрещён resolve поддоменов) — снимаем ability to make dns cover channel, этот dns сервер размещается в отдельной виртуалке которая не имеет доступа к виртуалке прокси шифровальщика, которая имеет эту виртуалку в качестве netvm для encrypting proxy vm.
5) патч к qubes который из dom0 для данной виртуалки на лету шифрует тем же ключом любой клвиатурный ввод + ввод через буфер обмена для копировния текста между виртуалками.
это фактически копия алгоритма работы irc прокси для личной шифрованной переписки которую срелизил один мой знакомый с добавкой обрезания днс тунеля.
Тем не менее у этого решения несколько минусов:
не будет работать поиск,
сравнение строк сделанное для пользователя будет давать кривые результаты
В общем и работы для реализации много и сделать прозрачный шифровальщик как для irc не получитс — работу интерфейса готовой чужой программы испортишь.
