о сертификации ЖЖ-страниц
Dec. 19th, 2003 08:27 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
avvaВ связи с некоторыми недавними скандалами [предупреждение: всё, что следует далее, никакого отношения ни к какому конкретному скандалу не имеет, и никакой позиции ни в одном из них я для себя не заявляю. Просто эта тема подтолкнула меня на размышления, никак с ней не связанные. Прошу о "скандальных" поводах ничего мне не писать и в них меня не втягивать. Спасибо] подумал немного о возможности сертификации страниц ЖЖ. В принципе, я могу сейчас взять страницу ЖЖ, например, показывающую какую-то запись с комментами, сохранить её в файле, и как угодно отредактировать перед тем, как выставлю её в другом месте. Изменить текст, имена юзеров, что угодно. Могу, скажем, изменить текст записи на что-то предосудительное, и сказать, "что так и было", а сейчас в той же записи того же юзера (если она вообще открыта) другое, потому что он быстренько отредактировал, но я успех сохранить первоначальный вариант. И так далее — ясно, что возможностей куча. Кто-то в это поверит, кто-то не очень (зависит от многих факторов: от степени доверчивости зрителя, от его оценки моей репутации и моей готовности к манипуляциям, от моих технических способностях, если подделывать нужно не просто текст, а какой-нибудь HTML, итд. итп.).
Можно было бы в принципе убрать фактор неопределённости. Скажем, в каждой HTML-странице, которую он выдаёт, LJ включает в качестве HTML-комментария значение криптографического хэша (скажем, MD5) от содержимого страницы + секретный ключ, хранящийся внутри LiveJournal.com . Можно какие-то ещё данные в вычисление этого хэша включить (например, имя того юзера, который смотрит эту страницу, если он logged in; или ещё неплохая идея - текущее серверное время, которое тут же рядом со значением хэша добавляется в HTML-комментарий). Далее, добавляется сервис "проверьте аутентичность данной страницы": посылаем LJ обратно страницу (напр. в таком виде, в какоме её кто-то выложил в другом месте) и он вычисляет заново значение хэша и сравнивает. Если кто-то что-то менял, проверка это обнаружит. Конечно, злоумышленник может вычистить хэш из HTML-кода страницы, но это само по себе будет свидетельством того, что файл редактировали, и, следовательно, информации в нём нельзя доверять.
(почему MD5, а не подписывать с помощью PGP, скажем? Потому, что MD5 - легко, быстро и реально сделать для всех страниц просто в коде их отдачи. Ведь LJ — полностью динамический сайт, всё, кроме картинок, строится в Перле).
Вряд ли на это будет большой спрос, впрочем.
Это мне напомнило ещё одну мою старую идею: сертификацию ЖЖ-записей. Предположим, я хочу иметь возможность доказать, что в такое-то время в такой-то день в моём журнале была запись такого-то содержания. Сейчас это сделать невозможно. Не потому, что я могу написать позже запись нужного содержания и датировать её задним числом — эту проблему можно было бы обойти, используя записанное в базе данных ЖЖ время создания записи с точки зрения сервера (недоступное обычно юзеру, но мы рассматриваем гипотетическую ситуацию; главное, что эта информация есть и её в принципе можно вытащить). Так вот, не поэтому, а потому, что я могу эту запись впоследствии отредактировать и сказать, что так и было. Базы данных ЖЖ не сохраняют старые варианты. Правда, я сейчас вспомнил, что относительно недавно, где-то полгода назад, мы сделали так, что они теперь сохраняют количество редактирований каждой записи, так что даже без криптографических подписей можно будет доказать, что данную запись кто-то редактировал хотя бы один раз после отправки. Но это тоже не идеально, ведь нет доказательств того, что автор не отредактировал её несколько раз сразу после отправки, исправляя мелкие погрешности, и не занимаясь более поздним подделыванием. И всё же, если записано в базе данных, что не редактировалось ни разу, то мы точно знаем, что всё в порядке — уже неплохо. Но я отклонился от темы. Можно в принципе сделать такой же сервис сертификации определённой записи в определённый момент. В принципе, это можно получить как частный случай описанной выше сертификации любой страницы; а можно сделать чем-то отдельным, сертифицируя именно текст записи и более ничего, используя ещё более надёжные функции итп.
Конечно, надо не забыть упомянуть, что защищённость самого сайта livejournal.com и его баз данных остаётся слабым звеном во всех этих схемах. Это слабое звено в свою очередь можно укреплять — ротацией секретных ключей, использованием для их хранения другого уровня шифровки, или не находящиеся в Интернете компьютеры, итд. итп. — о таких вещах немало статей и диссертаций написано, куда более интересных и сложных, чем это примитивное перечисление, призванное всего лишь передать общую идею.
Можно было бы в принципе убрать фактор неопределённости. Скажем, в каждой HTML-странице, которую он выдаёт, LJ включает в качестве HTML-комментария значение криптографического хэша (скажем, MD5) от содержимого страницы + секретный ключ, хранящийся внутри LiveJournal.com . Можно какие-то ещё данные в вычисление этого хэша включить (например, имя того юзера, который смотрит эту страницу, если он logged in; или ещё неплохая идея - текущее серверное время, которое тут же рядом со значением хэша добавляется в HTML-комментарий). Далее, добавляется сервис "проверьте аутентичность данной страницы": посылаем LJ обратно страницу (напр. в таком виде, в какоме её кто-то выложил в другом месте) и он вычисляет заново значение хэша и сравнивает. Если кто-то что-то менял, проверка это обнаружит. Конечно, злоумышленник может вычистить хэш из HTML-кода страницы, но это само по себе будет свидетельством того, что файл редактировали, и, следовательно, информации в нём нельзя доверять.
(почему MD5, а не подписывать с помощью PGP, скажем? Потому, что MD5 - легко, быстро и реально сделать для всех страниц просто в коде их отдачи. Ведь LJ — полностью динамический сайт, всё, кроме картинок, строится в Перле).
Вряд ли на это будет большой спрос, впрочем.
Это мне напомнило ещё одну мою старую идею: сертификацию ЖЖ-записей. Предположим, я хочу иметь возможность доказать, что в такое-то время в такой-то день в моём журнале была запись такого-то содержания. Сейчас это сделать невозможно. Не потому, что я могу написать позже запись нужного содержания и датировать её задним числом — эту проблему можно было бы обойти, используя записанное в базе данных ЖЖ время создания записи с точки зрения сервера (недоступное обычно юзеру, но мы рассматриваем гипотетическую ситуацию; главное, что эта информация есть и её в принципе можно вытащить). Так вот, не поэтому, а потому, что я могу эту запись впоследствии отредактировать и сказать, что так и было. Базы данных ЖЖ не сохраняют старые варианты. Правда, я сейчас вспомнил, что относительно недавно, где-то полгода назад, мы сделали так, что они теперь сохраняют количество редактирований каждой записи, так что даже без криптографических подписей можно будет доказать, что данную запись кто-то редактировал хотя бы один раз после отправки. Но это тоже не идеально, ведь нет доказательств того, что автор не отредактировал её несколько раз сразу после отправки, исправляя мелкие погрешности, и не занимаясь более поздним подделыванием. И всё же, если записано в базе данных, что не редактировалось ни разу, то мы точно знаем, что всё в порядке — уже неплохо. Но я отклонился от темы. Можно в принципе сделать такой же сервис сертификации определённой записи в определённый момент. В принципе, это можно получить как частный случай описанной выше сертификации любой страницы; а можно сделать чем-то отдельным, сертифицируя именно текст записи и более ничего, используя ещё более надёжные функции итп.
Конечно, надо не забыть упомянуть, что защищённость самого сайта livejournal.com и его баз данных остаётся слабым звеном во всех этих схемах. Это слабое звено в свою очередь можно укреплять — ротацией секретных ключей, использованием для их хранения другого уровня шифровки, или не находящиеся в Интернете компьютеры, итд. итп. — о таких вещах немало статей и диссертаций написано, куда более интересных и сложных, чем это примитивное перечисление, призванное всего лишь передать общую идею.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2003-12-18 10:50 pm (UTC)вроде бродила вокруг
Date: 2003-12-18 11:05 pm (UTC)что-то даже строилось вроде. Гугль нам поможет, наверно.
это не вполне заменяет твое предложение, поскольку часто уж поезд ушел к тому моменту как выясняется что надо было визировать контент; но параллельно ему.
Re: вроде бродила вокруг
Date: 2003-12-19 05:54 am (UTC)Вопрос по теме
Date: 2003-12-18 11:19 pm (UTC)LJ вроде как американский бизнес?
Или записи пользователей в каждой редакции не относятся к тому, что предписывает архивировать SOA?
Re: Вопрос по теме
Date: 2003-12-19 05:53 am (UTC)no subject
Date: 2003-12-18 11:29 pm (UTC)В такой распределенной системе хранение и ротация ключей будет делом каждого конкретного пользователя и будет определяться в соответсвии с его нуждами (ведь понятно, что далеко не всем это вообще нужно). Тогда можно было бы создавать и шифрованные записи, которые нельзя прочитать вообще никому, кроме владельца (хотя, возможно, это и не нужно).
no subject
Date: 2003-12-18 11:34 pm (UTC)1. Является ли страница подлинной в том смысле, что подписана автором.
2. Вносил ли автор изменения в текст после определенного момента.
Для ответа на первый вопрос не требуется никакого централизованного authority - достаточно PGP-подписи.
Выяснение же ответа на второй вопрос, как мне кажется, этически неочевидно - я бы, по крайней мере, возражал против того, чтобы мои записи могли бы быть подвергнуты такому анализу - я не в суде под присягой.
no subject
Date: 2003-12-19 05:49 am (UTC)Я согласен в том, что совершенно неочевидным является право других требовать узнать, редактировали ли ВЫ вашыи записи или нет. Интересный для меня вопрос заключается в том, сможете ли Вы доказать, в случае надобности, что этого не делали.
no subject
Date: 2003-12-19 06:18 am (UTC)Что же до второй задачи, то, похоже, без третейского судьи не обойтись, но нужно построить систему с нулевым разглашением, дабы третейский судья мог удостоверить истинность авторского утверждения "запись такая-то сделана тогда-то", но не мог бы этого сделать в случае, если утверждение сделано не автором.
no subject
Date: 2003-12-18 11:35 pm (UTC)no subject
Date: 2003-12-19 12:12 am (UTC)no subject
Date: 2003-12-19 12:50 am (UTC)no subject
Date: 2003-12-19 12:52 am (UTC)no subject
Date: 2003-12-19 01:23 am (UTC)Вторая проблема - внешние ссылки, в первую очередь картинки. Проще всего показать мужской половой орган, а потом подставить на место той картинки невинную фотографию цветочков.
no subject
Date: 2003-12-19 01:30 am (UTC)2) Ну так в этом случае никакая сертификация не сработает, кроме разве что авто-снятия скриншота :) Да и то при этом куча оговорок...
no subject
Date: 2003-12-19 06:45 am (UTC)no subject
Date: 2003-12-19 05:46 am (UTC)no subject
Date: 2003-12-19 07:08 am (UTC)no subject
Date: 2003-12-19 12:56 am (UTC)Подумалось вот, что от ddos-атаки никакой серевер не защищен, но почему же не "роняют" беспрестанно всё подряд, все сколько-нибудь известные, значимые, популярные сайты? Только лишь оттого, что это не представляет особого интереса?
no subject
Date: 2003-12-19 05:45 am (UTC)На практике dos и ddos-атаки против больших популярных сайтов случаются значительно чаще, чем о них становится известно публике; администраторы стремяется в первую очередь отразить их или защититься от них, не признавая вообще их существование (т.к. атакующие стремятся именно к известности, публичности, "славе", и если этого им не давать, им надоедает намного быстрее).
no subject
Date: 2003-12-19 05:57 am (UTC)Надеюсь, этого не случится. Ибо будет хуже.
Date: 2003-12-19 01:23 am (UTC)Re: Надеюсь, этого не случится. Ибо будет хуже.
Date: 2003-12-19 05:40 am (UTC)Это можно было бы решить так: у A в настройках есть галочка, если её поставить, то B не сможет сертифицировать записи A.
Не забывайте ещё и тот факт, что сертификация не всегда нужна B для того, чтобы поймать А за руку. Иногда она нужна самому A, чтобы доказать кому-нибудь, что какой-то текст он действительно написал в прошлом, а не отредактировал совсем недавно. Можно представить себе немало случаев, в которых A такая сертификация будет полезна или даже необходима.
Наконец, добавлю на всякий случай: никаких планов вводить такую сертификацию в ЖЖ в обозримом будущем нет. Возможно, такие планы появятся впоследствии, возможно, нет. Я просто рассуждаю вслух на интересную для меня тему.
Re: Надеюсь, этого не случится. Ибо будет хуже.
Date: 2003-12-20 02:34 am (UTC)инструкция:
товарищ А отсылает самому себе по нормальной почтовой службе рф, или где там проживает, заказное письмо с подробным описанием изобретения, сценария или чего ему вздумается
информационный накопитель не важен,- главное запечатать
на письме по закону устанавливается дата отправления и в реестр почтовой службы заносится соответствующая запись
стоит оно копейки, так что таких писем товарищ А себе может прислать хоть 20 штук из разных отделений
письмо лежит себе до надобности, и на разбирательстве любого уровня, вскрыв, суд примет его как неопровержимое доказательство, чему товарищ А будет безмерно рад )))
не думаю, что вообще имеет смысл распространять подобного рода информацию в сети или конкретно в lj - здесь даже фотографии приходится подписывать )
сохранение страниц
Date: 2003-12-19 02:08 am (UTC)Re: сохранение страниц
Date: 2003-12-19 05:34 am (UTC)no subject
Date: 2003-12-19 02:27 am (UTC)Я, например, редактирую большую часть своих уже отправленных постов. Текущее серверное время тогда вообще не много даст, так?
no subject
Date: 2003-12-19 05:32 am (UTC)no subject
Date: 2003-12-19 05:46 am (UTC)Если мне уже тогда придёт в голову, что её стоит сертифицировать, я просто скопирую запись и помещу комментом к посту.
Я-то думал, весь цимес в возможном подтверждении постфактум...
no subject
Date: 2003-12-19 02:38 am (UTC)no subject
Date: 2003-12-19 04:25 am (UTC)При регистрации человека на сайте ему выдается клиентский SSL сертификат, и, ходя по (потенциальной :) https-версии livejournal, человек фактически подписывает все свои действия. Каждый его комментарий можно хранить в базе, подписанный этим самым клиентским сертификатом. Таким образом, если кто-то захочет затем их подделать, выложив изменную страницу в другом месте, можно всегда доказать подделку, сравнив с подписанным содержимым базы.
С записями немножно труднее -- их тоже можно хранить подписанными, конечно, но кто знает, что там было раньше.. Как вариант -- можно хранить первую запись, плюс набор подписанных diff'ов к ней вместе с их timestamps.
С таким подходом TLS можно встраивать и в клиенты, кстати.
no subject
Date: 2003-12-19 05:33 am (UTC)no subject
Date: 2003-12-22 06:18 am (UTC)Аутентичность контента ЖЖ обеспечивает серверный сертификат. Устранить возможность делать фэйковые страницы, как это делают для воровства номеров кредиток, в принципе не возможно. Впрочем, так же невозможно устранить человеческую глупость и халатность.
no subject
Date: 2003-12-22 07:26 am (UTC)no subject
Date: 2003-12-22 07:59 am (UTC)no subject
Date: 2003-12-19 05:59 am (UTC)ЖЖ - это не тот жанр, который подразумевает интриги, поэтому и не надо наводить на противоположную мысль, вводя какие-то ограничения. Интриги - вообще дело недостойное.
no subject
Date: 2003-12-19 07:29 pm (UTC)Увы, интриг здесь предостаточно.
no subject
Date: 2003-12-19 08:45 am (UTC)no subject
Date: 2003-12-19 06:57 pm (UTC)Но тогда нет вот чего. Я, хозяин дневника, хочу отредактировать запись, чтобы показывала что-то другое, но сертифицировать её старую версию, чтобы в будущем иметь возможность доказать, что в такое-то время она выглядела так-то.
Хотя это не так уж и часто нужно, наверное.
no subject
Date: 2003-12-19 07:32 pm (UTC)А именно. Допустим, некто делает запись и хочет её завизировать. Для этой цели у нас существует специальный юзер - ну, скажем,
Ключ от почтового ящина checkist'а находится у Очень Уважаемого Человека (или у Абузы, или у какой-нибудь Комиссии по Скандалам).
Далее, после публикации записи от имени checkist'а делается один коммент (например, с надписью "заверено"). Это может сделать как сам автор постинга, так и кто угодно (пароль checkist'а доступен всем). Коммент уходит checkist'у в почту - вместе с текстом исходного сообщения. Всё, приехали: копия ушла туда, откуда её может извлечь только Очень Уважаемый Человек (или Комиссия по Скандалам).
Наконец, последнее. В Семаджике делается особая опция: "запостить вместе с проверочным комментом checkist'а". Технически, насколько я понимаю, семажик вполне может делать и комменты (просто это до сих пор никому не требовалось). Тогда коммент будет делаться сразу после записи. (Содержание его тоже можно стандартизировать, например: "Заверено. Сообщение отправлено по адресу такому-то. Если есть вопросы, обращайтесь в Комиссию По Скандалам, она вышлет вам исходный вариант.")
Заметим, что комментов можно оставлять несколько и в разное время.
Разумеется, лишние комментарии несколько перегружают работу системы. Однако, вряд ли все будут заверять каждое своё сообщение. Обычно такая необходимость возникает только в случае "неоднозначных высказываний", которых не так уж и много.
no subject
Date: 2003-12-19 08:32 pm (UTC)no subject
Date: 2003-12-23 09:19 am (UTC)Это удобно с т.з. LJ -- реализуется с полпинка и не требует глобальных изменений вроде хранения всей истории редактирования.
Это удобно с т.з. автора -- если он считает, что написал что-то важное, то после постинга жмёт на кнопочку и получает заверенную копию сообщения.
Это удобно для собеседников -- схема "у меня все ходы записаны!" реализуется элементарно, нужно только не забывать в процессе дискуссии на кнопочку жать:) Впрочем, ничто не мешает (опционально) подписывать таким образом все LJ-нотификации, приходящие по почте.
Что касается privacy, то тут можно, например, дать юзерам возможность запрещать ставить штампы на своих сообщениях, или разрешать делать это только френдам и т.д. Тут много чего придумать можно.